एक SharePoint administrator मासिक security list देखता है और spoofing के रूप में दर्ज एक vulnerability पाता है। Update जरूरी है, लेकिन outages, application releases और दूसरे critical patches के बीच वह पीछे रह सकता है। कुछ सप्ताह बाद उसी vulnerability को remote code execution बताया जाता है और सक्रिय हमलों में उसके उपयोग की पुष्टि हो जाती है।[1]
CVE-2026-65660 के पीछे यही operational समस्या है।[4]
Microsoft ने 11 August 2026 को fixes जारी किए थे। बाद में इसे code injection vulnerability के रूप में वर्गीकृत किया गया, जिससे authenticated attacker network पर code execute कर सकता है। 25 September तक Microsoft के पास हमलों के विश्वसनीय प्रमाण थे। CISA ने इसे Known Exploited Vulnerabilities catalog में जोड़ा और 28 September की remediation deadline तय की।[3]
वह समय सीमा बीत चुकी है। जिन teams ने अपने farms की स्थिति प्रमाणित नहीं की है, उन्हें इसे अगली routine patch cycle का काम नहीं, बल्कि incident-response task मानना चाहिए।
Vulnerability गंभीर है, लेकिन प्रवेश का रास्ता समझना जरूरी है
CVE-2026-65660 SharePoint Server 2016, SharePoint Server 2019 और SharePoint Server Subscription Edition को प्रभावित करती है। इसका CVSS score 8.8 है।[1]
सामान्य attack के लिए authenticated account चाहिए। इससे urgency कम नहीं होती। SharePoint को employees, contractors, service accounts और external collaborators इस्तेमाल कर सकते हैं। Attacker authentication को सीधे तोड़े बिना चुराए गए credentials या low-privilege account के जरिए पहुँच सकता है।
Canadian Centre for Cyber Security ने यह भी बताया है कि anonymous access वाले servers पर इसे अन्य SharePoint vulnerabilities के साथ chain करके pre-authentication remote code execution तक पहुँचा जा सकता है।[2] इसलिए software version के साथ हर web application की exposure भी जाँचनी होगी।
पहले प्रमाणित करें कि हर server fixed है
केवल patch-management dashboard में successful job दिखना पर्याप्त नहीं है। हर SharePoint farm के प्रत्येक server की inventory बनाकर installed build को fixed version से मिलाएँ।
| SharePoint edition | Fixed version |
|---|---|
| SharePoint Enterprise Server 2016 | 16.0.5565.1001 |
| SharePoint Server 2019 | 16.0.10417.20198 |
| SharePoint Server Subscription Edition | 16.0.19725.20522 |
हर server के लिए evidence दर्ज करें। एक server current होने से पूरा farm fixed नहीं हो जाता। छूटा हुआ application server, search server या disaster-recovery node vulnerable path को खुला रख सकता है।
Update के बाद Microsoft की आवश्यक SharePoint update procedure पूरी करें। जाँचें कि सभी servers अपेक्षित build दिखा रहे हैं, farm स्वस्थ है और configuration प्रक्रिया बीच में नहीं रुकी।
इसके बाद पूरा access path देखें
सिर्फ यह पूछना पर्याप्त नहीं है कि SharePoint URL public है या नहीं। पूरे access path की समीक्षा करें।
- कौन से web applications Internet या partner networks से उपलब्ध हैं?
- क्या कहीं anonymous access enabled है?
- Farm के सामने कौन से reverse proxies, load balancers या web application firewalls हैं?
- क्या low-privilege users ऐसे publishing, collaboration या legacy sites तक पहुँच सकते हैं जो inventory में नहीं आए?
- कौन से service accounts और automation tools SharePoint से जुड़ते हैं?
Patching पूरी होने तक public access सीमित करना, गैर-जरूरी anonymous access बंद करना और entry points को trusted networks तक सीमित करना उपयोगी है। ये कदम risk घटाते हैं, लेकिन update की जगह नहीं लेते।
Patch होने का अर्थ यह नहीं कि exploitation नहीं हुई
CISA deadline से पहले exploitation देखी गई थी। इसलिए अब patched server को भी investigation की जरूरत हो सकती है।
उस अवधि की SharePoint और IIS activity देखें जब server vulnerable था। इसे Windows security events, endpoint detection alerts, identity sign-ins, process execution और outbound network connections से correlate करें। खासकर उन accounts की असामान्य activity देखें जो सामान्य रूप से सीमित SharePoint काम करते हैं।
Generic checklist को मनगढ़ंत indicators of compromise में न बदलें। Microsoft और CISA guidance के साथ अपने security tools के evidence का उपयोग करें। Suspicious execution मिलने पर files हटाने या server rebuild करने से पहले evidence सुरक्षित रखें। Incident-response team को शामिल करें और review को credentials, connected systems और दूसरे farm servers तक बढ़ाएँ।
SharePoint का blast radius बड़ा क्यों हो सकता है
SharePoint को collaboration platform कहा जाता है। व्यवहार में इसमें contracts, operational documents, employee records, workflow data और दूसरे business systems के links हो सकते हैं। यह ऐसे identities के तहत भी चल सकता है जो databases, file shares, mail systems या automation services तक पहुँचते हैं।
इसलिए एक server compromise दो risks पैदा करता है। पहला SharePoint content तक पहुँच है। दूसरा उस server का credential theft, persistence या connected systems में आगे बढ़ने के लिए शुरुआती बिंदु बनना है।
Response team को चार boundaries map करनी चाहिए: content, identity, automation और network access। केवल SharePoint patch review करने से वे connected systems छूट सकते हैं जो compromise को अधिक खतरनाक बनाते हैं।
Figure 1 के लिए सुगम विवरण
बीच में SharePoint Server farm, उससे जुड़े identity accounts, business documents, workflows, databases और file shares, तथा बाहर Internet और partner access boundary दिखाने वाला चित्र।
Hybrid environment के लिए सबक
Collaboration को Microsoft 365 में ले जाने से on-premises risk अपने आप समाप्त नहीं होता। Workflows, archives, custom applications या कठिन integrations के कारण पुराने farms चल सकते हैं।
ऐसे farms कम दिखाई देते हैं, लेकिन महत्वपूर्ण systems से जुड़े रह सकते हैं। हर farm का owner तय करें। दर्ज करें कि वह क्यों मौजूद है, कौन उसे access कर सकता है, कौन से systems उस पर भरोसा करते हैं और अगली review कब होगी।
CVE-2026-65660 emergency patch issue है। यह यह भी याद दिलाता है कि internal collaboration server के पास production-level authority हो सकती है। उसकी सुरक्षा browser में दिखने वाले साधारण label से नहीं, बल्कि उसके access और trust relationships से तय होनी चाहिए।