Des hackers enchaînent deux failles SharePoint pour prendre le contrôle total du serveur

Une chaîne d’exploitation de type « proof-of-concept » visant Microsoft SharePoint Server sur site est désormais utilisée lors de véritables attaques, et il n’a fallu qu’un jour entre la publication d’une technique par un chercheur et sa mise en œuvre par un attaquant. C’est le délai rapporté par le chercheur Defused pour la CVE-2026-55040, la faille d’authentification contournée au cœur de la dernière vague d’exploitation de SharePoint, selon la couverture de BleepingComputer.

Cette chaîne combine deux failles distinctes. La CVE-2026-55040 est un contournement de l’authentification par jeton JWT qui permet à un attaquant non authentifié d’agir comme un utilisateur du site SharePoint, voire comme administrateur, sans jamais fournir d’identifiants valides. La CVE-2026-63520 est une faille distincte dans les Business Connectivity Services (BCS) de SharePoint qui, une fois l’authentification contournée, peut être enchaînée pour obtenir une exécution de code à distance sur un serveur non corrigé. Stephen Fewer de Rapid7 a publié un code proof-of-concept pour la CVE-2026-55040 le 11 août. Jonathan Peterson de VulnCheck a suivi avec un code proof-of-concept pour la CVE-2026-63520 le 24 août. En environ deux semaines après la première divulgation, le secteur disposait d’un chemin documenté et fonctionnel, allant d’aucun accès à l’exécution de code sur un serveur SharePoint.

Pour toute organisation exploitant encore SharePoint Server sur site pour échanger, stocker ou collaborer sur des données sensibles, il ne s’agit pas d’un simple avis à classer. C’est la confirmation que la plateforme reste une cible active pour des attaquants qui maîtrisent mieux ses couches d’authentification et d’intégration que la plupart des organisations qui l’utilisent. La CVE-2026-55040 a été corrigée le 14 juillet 2026, dans le cadre d’une vague de correctifs SharePoint Server qui a également généré cinq entrées dans le catalogue des vulnérabilités exploitées connues de la CISA. L’existence d’un correctif depuis juillet n’a pas empêché l’exploitation proof-of-concept ce mois-ci, car des instances non corrigées restent accessibles, et la nouvelle faille BCS récemment révélée offre aux attaquants un moyen inédit de transformer ce vieux contournement en compromission totale.

Cet article détaille le fonctionnement des deux CVE, explique pourquoi le délai d’armement d’une journée est plus significatif que le score CVSS, et ce que ce schéma implique sur le plan architectural pour les RSSI et responsables conformité, qui doivent prouver — et non simplement affirmer — que les données sensibles transitant par des plateformes comme l’échange sécurisé de données Kiteworks restent maîtrisées, quelle que soit la situation de l’infrastructure adjacente.

Résumé des points clés

1. Une chaîne d’exploitation fonctionnelle existe désormais pour SharePoint Server sur site.

La CVE-2026-55040 (contournement de l’authentification JWT) et la CVE-2026-63520 (faille dans les Business Connectivity Services) peuvent être combinées pour passer d’aucun accès à une exécution de code à distance sur des serveurs non corrigés.

2. L’armement s’est produit en un jour environ.

Le chercheur Defused a documenté que le code proof-of-concept de la CVE-2026-55040 était déjà utilisé lors d’attaques réelles un jour après sa publication par Rapid7. Aujourd’hui, publication et exploitation sont presque simultanées.

3. Corriger la CVE ne suffit pas à corriger l’architecture.

La CVE-2026-55040 a été corrigée le 14 juillet 2026, mais le schéma sous-jacent — contournement de l’authentification enchaîné à une désérialisation ou à une exécution de code à distance via la couche d’intégration — se répète sur SharePoint Server sur site, car la surface d’attaque de la plateforme est structurelle.

4. Il s’agit de SharePoint Server sur site, pas de SharePoint Online.

Confondre les deux est une erreur factuelle qui conduit les organisations à tirer de mauvaises conclusions sur leur exposition réelle ; SharePoint Online n’était pas concerné par cette chaîne d’exploitation.

5. La question de la conformité est aussi importante que la question technique.

Pour les RSSI et responsables conformité, le véritable enjeu ne se limite pas à la prise de contrôle du serveur ; il s’agit de l’incapacité à fournir, à la demande, la preuve que le contenu sensible ayant transité par une plateforme affectée est resté autorisé, chiffré et tracé pendant la période d’exposition.

Ce que font réellement CVE-2026-55040 et CVE-2026-63520

La CVE-2026-55040 concerne la validation de l’authentification JWT (JSON Web Token) dans SharePoint Server sur site. Un pipeline de validation de jeton correctement implémenté doit rendre impossible, d’un point de vue calculatoire, la création d’une session valide par un tiers. Cette vulnérabilité remet en cause cette hypothèse. Un attaquant sans privilèges, sans identifiants valides et sans accès préalable peut formuler une requête que SharePoint Server considère comme provenant d’un utilisateur légitime, voire d’un administrateur. Il s’agit d’un contournement total de l’authentification, et non d’une élévation de privilèges à partir d’un compte à droits limités.

La CVE-2026-63520, notée CVSS 8.1 (élevée) selon l’analyse technique de VulnCheck, se situe dans une autre partie de la plateforme : les Business Connectivity Services, la couche d’intégration utilisée par SharePoint pour se connecter à des sources de données externes (bases de données, ERP, applications personnalisées). La cause principale est une instanciation non sécurisée de type .NET, qui permet à un attaquant d’exploiter une chaîne de gadgets de désérialisation basée sur la classe System.Web.UI.LosFormatter pour exécuter du code arbitraire sur le serveur. Les BCS sont puissants par conception : ils existent pour permettre à SharePoint de lire et d’écrire des données dans des systèmes externes au nom de l’utilisateur. Cette même conception les rend dangereux dès lors qu’un attaquant a déjà contourné l’authentification. Un composant conçu pour servir d’intermédiaire avec des systèmes externes, combiné à une entrée contrôlée par un attaquant, devient une porte d’entrée vers l’exécution de code à distance sur le serveur lui-même.

Pris isolément, aucune des deux failles n’est inhabituelle. Les contournements d’authentification et les failles de désérialisation ou d’injection au niveau de la couche d’intégration apparaissent régulièrement dans les plateformes collaboratives d’entreprise. Ce qui rend cette combinaison significative est simple : la CVE-2026-55040 permet à un attaquant d’entrer sans identifiants, et la CVE-2026-63520 lui offre la possibilité d’exécuter du code une fois à l’intérieur. Chacune est grave prise séparément. Ensemble, elles constituent un chemin complet et non authentifié vers la compromission du serveur — exactement le type de faille qui apparaît d’abord sous forme de proof-of-concept, puis, souvent en quelques jours, dans une campagne d’exploitation active.

Du proof-of-concept à l’exploitation réelle en quelques jours

Le calendrier est l’aspect de cette histoire qui mérite plus d’attention que les numéros de CVE eux-mêmes. Stephen Fewer de Rapid7 a publié un code proof-of-concept pour la CVE-2026-55040 le 11 août. Selon le chercheur Defused, ce code était déjà utilisé lors d’attaques réelles dès le lendemain. Jonathan Peterson de VulnCheck a publié un code proof-of-concept pour la CVE-2026-63520 le 24 août, offrant aux attaquants la seconde moitié de la chaîne environ deux semaines plus tard.

Cette accélération n’est pas nouvelle en 2026, mais elle s’intensifie, et SharePoint Server sur site est devenu un terrain d’expérimentation récurrent. Un correctif publié dans le calendrier de Microsoft ne sert à rien si l’organisation ne l’a pas appliqué, et la cadence Patch Tuesday n’a jamais été conçue pour rivaliser avec une fenêtre d’exploitation le jour même. Les équipes sécurité qui considèrent la publication d’un proof-of-concept comme un signal pour commencer à planifier un cycle de correctifs réagissent en réalité à un signal déjà dépassé lorsqu’elles lisent l’avis.

Unit42 de Palo Alto Networks, dans son analyse de la campagne d’exploitation « ToolShell » SharePoint 2025, une précédente chaîne contournement d’authentification vers RCE sur la même plateforme sur site, a tiré la conclusion suivante : « Corriger ne suffit pas à éliminer totalement la menace. » Cette conclusion s’appuyait sur des attaquants qui, une fois entrés via un contournement d’authentification, se déplaçaient latéralement et, dans certains cas, volaient les clés machine IIS, des identifiants qui survivent à un correctif et à la suppression d’un web shell car ils n’ont jamais été renouvelés. C’est la même leçon que rappelle la chaîne de ce mois-ci. Un serveur peut être entièrement corrigé aujourd’hui et rester compromis si les identifiants touchés lors d’une intrusion antérieure n’ont jamais été invalidés. Corriger répond à la question « cette vulnérabilité spécifique est-elle encore exploitable ? » mais pas à « ce serveur, et tout ce qui y est connecté, est-il encore digne de confiance ? »

Il s’agit d’un schéma récurrent, pas d’un incident isolé

En prenant du recul sur ces deux CVE, on observe un schéma qui se répète dans l’histoire récente de SharePoint Server sur site : failles d’authentification et de couche d’intégration, enchaînées, produisant une exécution de code à distance sans authentification, suivies d’une armement proof-of-concept rapide. La vague de juillet 2026 qui a corrigé la CVE-2026-55040 a également donné lieu à l’alerte de durcissement SharePoint du 14 juillet 2026 de la CISA et à plusieurs entrées dans le catalogue des vulnérabilités exploitées connues de la CISA, chacune assortie d’une date limite de remédiation en jours, non en mois. L’analyse de Resecurity sur cette chaîne d’attaque a documenté une progression allant de l’accès initial non authentifié à l’exécution de code, au déploiement d’un web shell, au vol d’identifiants, puis au mouvement latéral vers la compromission du domaine.

La CVE-2026-63520 prolonge ce même schéma structurel sur une nouvelle surface d’intégration. Il s’agit d’un chemin de code différent des failles de désérialisation documentées en juillet, mais le résultat est identique via un mécanisme similaire : une couche d’authentification contournable, alimentant un second composant conçu pour faire confiance aux requêtes authentifiées et donc jamais durci contre des entrées contrôlées par un attaquant arrivant par une porte d’entrée compromise. La FAQ de Tenable sur les CVE SharePoint Server associés va dans le même sens : il ne s’agit pas tant d’erreurs de codage isolées que de symptômes récurrents d’une plateforme où authentification, désérialisation et intégration constituent chacune une surface d’attaque indépendante, et où une faille dans l’une peut être combinée à une faille dans l’autre pour aboutir à une compromission totale.

Pour un RSSI, la vraie question n’est pas « avons-nous corrigé CVE-2026-55040 et CVE-2026-63520 », mais « combien d’autres composants de cette plateforme présentent le même type de risque, et comment le saurions-nous avant que le prochain proof-of-concept ne nous l’apprenne ? » C’est une question d’architecture, pas de gestion de correctifs, et elle n’a pas de réponse dans la gestion de correctifs.

Pourquoi corriger ne comble pas le fossé

Trois vérités coexistent, et les organisations qui ne retiennent que la première restent exposées des mois plus tard. Premièrement, Microsoft a bien publié un correctif pour la CVE-2026-55040 le 14 juillet 2026, et les organisations qui l’ont appliqué ne sont plus vulnérables à ce contournement précis. Deuxièmement, la fenêtre d’armement d’un jour signifie que toute organisation n’ayant pas déjà appliqué le correctif avant la publication du code proof-of-concept a été exposée à une exploitation réelle presque immédiatement, sans période d’alerte entre « c’est exploitable en théorie » et « c’est exploité ». Troisièmement, et c’est le moins discuté, corriger une vulnérabilité n’invalide pas rétroactivement ce qu’un attaquant a pu consulter, copier ou persister lors d’une précédente fenêtre de compromission.

C’est pourquoi le lecteur conformité et audit se pose une question différente, et sans doute plus urgente, que le lecteur ingénierie sécurité. La question sécurité est « le serveur est-il corrigé ? ». La question conformité est « pouvons-nous prouver que chaque contenu sensible traité par ce serveur pendant la période d’exposition n’a été consulté que par des identités autorisées, et si ce n’est pas le cas, disposons-nous d’une trace probante et exploitable de ce qui a été exposé ? » HIPAA, CMMC et ITAR ne font pas la différence entre « nous avons été compromis car nous n’avons pas corrigé » et « nous avons été compromis un jour après qu’un correctif soit devenu disponible en théorie ». Les régulateurs, auditeurs et parties adverses en cas de litige demanderont quelles données étaient sur la plateforme, qui pouvait y accéder, et ce que montre le journal d’audit. Un environnement SharePoint Server sur site nécessitant une instrumentation personnalisée pour répondre à cette question part avec un handicap dès qu’un incident survient.

La question d’architecture que devraient se poser les responsables conformité et sécurité

Kiteworks n’était pas littéralement dans la chaîne de données de cet incident. SharePoint Server sur site est une plateforme native Microsoft que Kiteworks ne précède pas, et rien ici ne doit être interprété comme une affirmation que Kiteworks aurait empêché cette chaîne d’attaque précise. L’alignement est architectural, non contrefactuel.

L’échange sécurisé de données Kiteworks n’expose pas de pipeline de validation de jeton JWT du type exploité dans la CVE-2026-55040, et ne repose pas sur une couche d’intégration à la BCS pour l’accès aux données. Chaque requête de contenu, humaine ou machine, passe par le Control Plane Kiteworks, qui applique les règles à chaque requête, selon une approche zero trust, au lieu d’accorder une confiance durable basée sur la session à quiconque présente un jeton. Cette distinction est essentielle, car les failles de falsification de jeton et de confiance de session sont précisément ce qui a rendu possible la chaîne d’exploitation de ce mois-ci.

La couche conformité sous-jacente à cette architecture est tout aussi importante que l’architecture elle-même. Kiteworks détient la désignation FedRAMP High In-Process et maintient l’autorisation FedRAMP Moderate de manière continue depuis 2017, soit neuf années consécutives de validation de contrôle par un tiers, ce qu’un logiciel géré sur site par le client ne peut garantir seul ; l’autorisation FedRAMP s’applique à un service managé, non à un logiciel déployé et sécurisé indépendamment par une organisation. Kiteworks répond également à 90 % des exigences CMMC Niveau 2 en standard, utilise un chiffrement validé FIPS 140-3, et détient les certifications SOC 2 Type II et ISO 27001 en plus du support ITAR, HIPAA BAA, RGPD et CCPA. Cela ne signifie pas que Kiteworks est immunisé contre toute catégorie de vulnérabilité ; aucune plateforme ne peut l’affirmer honnêtement. Il s’agit d’une déclaration sur les catégories de surface d’attaque — contournement JWT non authentifié et RCE via la couche d’intégration d’une plateforme collaborative généraliste — qui ne concernent pas l’architecture de Kiteworks.

Pour les organisations qui s’interrogent sur la gestion de workflows sensibles encore hébergés sur SharePoint Server sur site, la question n’est pas de tout abandonner. Il s’agit d’identifier quels workflows traitent des contenus réglementés ou sensibles qui bénéficieraient d’une plateforme où les contrôles d’accès, le RBAC et la traçabilité probante sont natifs à l’architecture, plutôt que rajoutés après coup via une instrumentation personnalisée.

Que doivent faire les organisations réglementées dès maintenant ?

Vérifiez immédiatement le statut des correctifs pour la CVE-2026-55040 et la CVE-2026-63520 si vous exploitez SharePoint Server sur site 2016, 2019 ou Subscription Edition ; cela n’affecte pas SharePoint Online. Ne vous limitez pas à vérifier que le correctif est appliqué. Renouvelez les clés machine IIS et tout identifiant auquel le serveur avait accès, car la conclusion de Palo Alto Unit42 selon laquelle « corriger ne suffit pas à éliminer totalement la menace » visait précisément la persistance des clés et identifiants après correctif. Analysez les journaux d’authentification et des Business Connectivity Services pour la période d’exposition comprise entre la divulgation initiale et l’application du correctif, et considérez toute lacune dans ces journaux comme un constat à part entière, et non comme une simple gêne technique. Enfin, recensez les workflows sensibles ou réglementés qui transitent encore par SharePoint Server sur site, et évaluez si chacun nécessite la gestion d’incident et la charge de preuve que cette plateforme implique désormais, ou s’il doit migrer vers une infrastructure conçue dès l’origine pour l’échange de données gouverné et réglementé.

Pour en savoir plus sur la médiation de chaque requête de données via un Control Plane zero trust plutôt qu’un pipeline d’authentification basé sur la session, réservez votre démo personnalisée dès maintenant.

Ressources complémentaires

• Article de blog Zero Trust Architecture : Ne jamais faire confiance, toujours vérifier
• Vidéo Microsoft GCC High : Les inconvénients qui poussent les sous-traitants de la défense à chercher de meilleures alternatives
• Article de blog Comment sécuriser les données classifiées une fois signalées par le DSPM
• Article de blog Instaurer la confiance dans l’IA générative grâce à l’approche Zero Trust
• Vidéo Guide ultime pour le stockage sécurisé des données sensibles à destination des responsables IT