Le PoC de Rapid7 déclenche l’exploitation active de la faille d’authentification SharePoint (CVE-2026-55040)

14 juillet 2026. Microsoft corrige CVE-2026-55040, un contournement d’authentification dans SharePoint Server, signalé par Rapid7. 11 août 2026. Le chercheur Stephen Fewer (Rapid7) publie l’analyse technique complète et un proof of concept. 13 août 2026. La société de renseignement Defused constate que des attaquants utilisent déjà ce PoC contre ses honeypots SharePoint. En onze jours, une faille « corrigée » est redevenue un vecteur actif.

L’histoire a une leçon qui dépasse SharePoint : un correctif est une étape, pas une conclusion. Et la faille elle-même est un cas d’école sur la façon dont une chaîne de validation JWT peut échouer quatre fois de suite sans jamais lever d’erreur.

Une chaîne de quatre faiblesses, pas une faille unique

Fewer a décompilé le module Microsoft.SharePoint.IdentityModel d’une instance SharePoint Server Subscription Edition entièrement patchée (version 16.0.19725.20210). Le contournement ne repose pas sur une erreur spectaculaire, mais sur quatre faiblesses qui, combinées, permettent à un attaquant distant non authentifié de forger un JWT valide et de se faire passer pour n’importe quel utilisateur du site.

L’authentification S2S (service à service) de SharePoint utilise un JWT imbriqué : un jeton externe portant l’identité de l’utilisateur, et un actor token interne censé être signé par un certificat de confiance. C’est là que tout se joue.

• Faiblesse 1 — la signature est désactivée. Dans SPJsonWebSecurityTokenHandlerV2.ValidateToken(), la ligne val.RequireSignedTokens = false; désactive la vérification cryptographique du jeton externe. La bibliothèque accepte alors un en-tête alg: none : aucun contrôle de signature sur le jeton principal.
• Faiblesse 2 — la clé est résolue sans vérification. Le actor token pointe sa clé de signature via l’en-tête x5t (empreinte de certificat), une valeur contrôlée par l’attaquant. Le résolveur cherche une correspondance parmi les certificats de confiance — dont le certificat STS local de SharePoint, récupérable sans authentification via l’endpoint /_layouts/15/metadata/json/1.
• Faiblesse 3 — l’émetteur est accepté par défaut. ValidateIssuer() accepte inconditionnellement un émetteur dont le certificat n’est pas dans la collection TrustedSecurityTokenServices. Référencer le certificat STS local via x5t fait donc passer la validation d’émetteur sans rien vérifier.
• Faiblesse 4 — la signature n’est jamais contrôlée. GetTokenSignature() exige seulement une signature non vide. Un actor token signé AAAA suffit : la valeur n’est jamais confrontée à une vérification RSA réelle.

La ligne qui résume tout est celle-ci, extraite du code décompilé :

// SPJsonWebSecurityTokenHandlerV2.cs — ValidateToken()
val.RequireSignedTokens = false;

Une fois la validation passée, la revendication nameid du jeton externe — un SID Windows ou un UPN contrôlé par l’attaquant, voire l’identité du service local — est résolue en identité d’utilisateur. Le PoC de Rapid7 démontre les trois mécanismes.

La leçon technique la plus profonde est ailleurs : la validation reposait sur quatre hypothèses indépendantes, et aucune ne vérifiait l’autre. Une implémentation correcte aurait dû faire échouer le jeton dès la première faiblesse ; ici, chaque maillon a cédé à son tour. C’est exactement le genre de chaîne que les revues de code et les audits des bibliothèques d’authentification sont censés attraper — et qu’un correctif mensuel ne peut pas réparer à lui seul.

Un PoC public, une exploitation en quelques heures

La chronologie est la partie inquiétante. Fewer publie son analyse le 11 août sur le blog Rapid7, accompagnée du script sur GitHub (sfewer-r7/CVE-2026-55040). Moins de deux jours plus tard, le 13 août, Defused signale que des acteurs utilisent ce PoC contre ses honeypots SharePoint.

Le fait que l’exploitation démarre aussi vite après publication n’a rien d’étonnant : le PoC ne nécessite aucun accès préalable, et la surface — les SharePoint Server exposés — est vaste et hétérogène. Microsoft, de son côté, décrit l’impact avec une retenue significative : le contournement permet d’usurper l’identité, de divulguer des fichiers et de modifier des données, mais « l’attaquant ne peut pas affecter la disponibilité du système ». Microsoft n’a pas confirmé d’exploitation dans la nature, même s’il signale la faille comme une cible probable.

L’amplificateur : le chaînage vers une RCE

Seul, CVE-2026-55040 est déjà grave. Mais il ne s’arrête pas là. Combiné à CVE-2026-63520, une RCE SharePoint également découverte par Rapid7, le contournement d’authentification « pourrait conduire à une exécution de code à distance non authentifiée contre un serveur vulnérable », selon NHS England Digital. Le duo figure d’ailleurs dans notre analyse du Patch Tuesday d’août.

C’est le schéma classique du chaînage : l’auth bypass donne l’identité, la RCE donne les commandes. La CISA a de son côté appelé les administrateurs à durcir leurs déploiements SharePoint, citant l’exploitation active de plusieurs autres vulnérabilités de la plateforme. Le message implicite est limpide : SharePoint Server exposé à Internet est une cible prioritaire, et le catalogue de failles exploitables s’allonge chaque semaine.

Une précision utile pour cadrer la gravité : le contournement confère l’identité d’un utilisateur ou d’un administrateur de site SharePoint, dans le périmètre de la collection de sites visée par le jeton. Ce n’est pas, en soi, une exécution de code au niveau de la ferme — d’où l’importance du chaînage avec CVE-2026-63520. Seule, la faille est un risque de divulgation et d’altération de données ; chaînée, elle devient un point d’entrée vers le serveur.

Ce qu’il faut faire, concrètement

Le correctif de juillet 2026 existe et doit être appliqué — mais il ne suffit pas, puisque des instances non patchées ou mal exposées sont précisément celles que les attaquants ciblent. La réponse se joue à trois niveaux.

• Corriger et vérifier. Appliquer la mise à jour de juillet 2026 sur toutes les fermes SharePoint Server, puis confirmer l’application — une ferme qui « a reçu » le correctif sans redémarrage complet des services reste vulnérable.
• Réduire l’exposition. La consigne de la CISA est sans détour : éviter d’exposer SharePoint Server directement à Internet ; si c’est indispensable, ne le placer que derrière un reverse proxy de couche 7 qui exige l’authentification et sait inspecter et filtrer les requêtes.
• Surveiller les chaînages. Suivre les alertes sur CVE-2026-63520 et traiter le duo comme un seul scénario d’attaque — l’auth bypass n’est qu’un marchepied vers la RCE.
• Détecter. Un accès S2S légitime présente une signature vérifiée ; surveiller les journaux ULS et les tentatives d’authentification anormales sur les fermes aide à repérer les jetons forgés — même si, sans le correctif, un jeton bien construit ne laisse aucune trace d’erreur.

Le détail qui compte : le contournement fonctionne sans aucune interaction et sans identifiants. Les protections périmétriques classiques (MFA, complexité des mots de passe) n’y changent rien. La seule barrière efficace, avant le correctif, est de retirer le serveur de l’exposition directe.

Verdict

CVE-2026-55040 n’est pas le zero-day le plus sophistiqué de l’année — il est pire à sa manière. C’est une faille corrigée depuis juillet, dont le PoC public a suffi à relancer l’exploitation en deux jours, parce que le correctif n’avait pas encore été appliqué partout et que la surface exposée reste énorme. Sa gravité tient moins au code qu’à l’écart entre « corrigé chez l’éditeur » et « corrigé chez vous ».

La recommandation est conditionnelle et nette. Si vous exploitez un SharePoint Server exposé à Internet, traitez l’application du correctif de juillet comme une urgence du jour, et mettez-le derrière un reverse proxy authentifiant dès maintenant — le PoC circule et les honeypots le voient déjà arriver. Si vos SharePoint sont internes, appliquez le correctif à la prochaine fenêtre, mais ne baissez pas la garde : la chaîne avec CVE-2026-63520 transforme une faille d’identité en exécution de code, et c’est dans les réseaux « de confiance » que ce chaînage fait le plus de dégâts.

Références

• Attackers exploit critical SharePoint flaw after PoC goes public (CVE-2026-55040) — Help Net Security, 13 août 2026
• Rapid7 Analysis: Microsoft SharePoint JWT Token Authentication Bypass (CVE-2026-55040) — Rapid7, 11 août 2026
• CVE-2026-55040 — Microsoft Security Response Center
• CISA urges SharePoint hardening after new exploitations — CISA