CVE-2026-65660 transforme le spoofing SharePoint de Microsoft en exécution de code à distance

11 août 2026. Microsoft corrige CVE-2026-65660 dans ses mises à jour de sécurité mensuelles, en la décrivant comme une vulnérabilité de spoofing notée CVSS 6,5, sans impact sur l’intégrité ni la disponibilité. 22 septembre 2026. Le chercheur Dinh Ho Anh Khoa, de Viettel Cyber Security, publie les détails techniques complets : la faille permet en réalité une exécution de code à distance authentifiée. 25 septembre 2026. La CISA ajoute CVE-2026-65660 à son catalogue KEV, et Microsoft reconnaît disposer de « preuves fiables d’attaques observées ». Pourquoi c’est important : des équipes ont trié cette faille pendant plus d’un mois comme un problème cosmétique, alors qu’elle ouvre un chemin d’exécution de code sur des serveurs SharePoint.

Un décalage de classification qui fausse le tri

Le tri des vulnérabilités repose sur la confiance dans la description du fournisseur. CVE-2026-65660 montre à quel point cette confiance peut être trompeuse. L’avis Microsoft décrivait un spoofing « autorisé » à CVSS 6,5, n’attribuant aucun impact à l’intégrité ou à la disponibilité. Le bulletin CVE publié séparément par Microsoft, mis à jour le 11 septembre 2026, intitule pourtant la même faille « remote code execution » et indique qu’elle permet à un attaquant autorisé d’exécuter du code. Les deux enregistrements partagent la même faiblesse CWE-94, l’injection de code.

Les défenseurs qui ont trié CVE-2026-65660 sur la base de l’avis initial ont vu une faille de spoofing modérée, et non une vulnérabilité d’exécution de code au score CVSS 8,8 — celui retenu par le NVD. La leçon est simple : pour les produits Microsoft, l’avis du bulletin et l’enregistrement CVE doivent être lus ensemble, car ils peuvent diverger pendant des semaines.

Le mécanisme : des guillemets qui laissent passer des directives

La faille réside dans la façon dont SharePoint vérifie si les contrôles côté serveur figurent sur la liste SafeControls — un filtre qui empêche le chargement de classes dangereuses. Lorsque le composant ToolPane traite le balisage d’un web part, il reconstruit des directives Register en écrivant les valeurs d’attribut entre guillemets, sans échapper les guillemets présents à l’intérieur de ces valeurs.

Un attaquant peut donc injecter des directives supplémentaires à travers les guillemets non échappés. Le contrôle de type s’exécute d’abord, puis les classes arbitraires sont enregistrées avant le chargement du contrôle. Une fois le chargement de classe arbitraire obtenu, l’attaquant utilise XamlServices.Parse() pour déclencher l’exécution de code par désérialisation — une technique classique de gadget de désérialisation .NET, mais appliquée ici au cœur même du rendu des web parts.

Le write-up inclut une charge utile de webshell en mémoire, qui contourne les échecs de permission du registre rencontrés par d’autres méthodes de désérialisation. Khoa indique avoir utilisé l’exploit lors de tests d’intrusion réels. Le correctif du 11 août corrige la faille et désactive par défaut la fonction vulnérable.

Un chercheur qui connaît ce terrain

Dinh Ho Anh Khoa n’est pas un inconnu : c’est lui qui a démontré la chaîne ToolShell contre SharePoint lors du Pwn2Own Berlin en mai 2025. Cette chaîne avait ensuite été exploitée par des groupes soutenus par des États, déclenchant des correctifs d’urgence chez Microsoft. Il a depuis divulgué plusieurs autres failles SharePoint, dont CVE-2026-55040, un contournement d’authentification exploité peu après la publication de ses détails en août 2026.

Ce pedigree change la lecture du risque. Une faille SharePoint détaillée par ce chercheur a historiquement été suivie d’une exploitation rapide dans la nature — ce que l’ajout au KEV du 25 septembre vient confirmer.

Le chaînage pré-authentification

Khoa a également démontré que CVE-2026-65660 peut être chaînée avec un contournement d’authentification distinct, déjà corrigé, pour atteindre une exécution de code à distance pré-authentification sur les serveurs configurés pour autoriser l’accès anonyme aux pages. Le contournement a été corrigé par le patch du 9 juin, et les serveurs qui l’ont appliqué ne sont pas exposés au chemin pré-authentification.

Cela signifie que la gravité réelle dépend de l’état de correction de chaque serveur : un serveur patché en juin reste exposé à la RCE authentifiée, tandis qu’un serveur non patché depuis juin et autorisant l’accès anonyme devient une cible de RCE non authentifiée. Pour vérifier le niveau de correctif d’une ferme, la commande suivante renvoie la version de build :

(Get-SPFarm).BuildVersion

La faille touche SharePoint Server 2016, 2019 et Subscription Edition. Khoa précise qu’elle affecte aussi SharePoint 2013, bien que l’avis Microsoft ne liste que les trois éditions supportées — SharePoint 2013 étant hors support depuis avril 2023 et ne recevant plus de correctifs.

Une exploitation désormais officiellement reconnue

Le basculement de statut est intervenu en quelques jours. Le 22 septembre, les détails techniques complets sont publics, mais aucune exploitation n’est signalée et la faille n’est pas au KEV. Le 25 septembre, Microsoft note : « Au 25/09/2026, Microsoft disposait de preuves fiables d’attaques observées contre l’exploitation de cette vulnérabilité. » Microsoft n’a pas précisé qui se cache derrière les attaques, quand elles ont commencé, combien d’organisations ont été visées ni ce que les attaquants ont fait une fois à l’intérieur.

La CISA a réagi le même jour en inscrivant CVE-2026-65660 au KEV, avec une échéance de correction au 28 septembre 2026 pour les agences fédérales américaines — un signal fort, car l’inscription au KEV exige une exploitation active confirmée. Pour les équipes qui traitent encore CVE-2026-65660 comme un spoofing à corriger « quand on aura le temps », la fenêtre s’est refermée.

Détecter une exploitation déjà passée

La charge utile publiée par Khoa est un webshell en mémoire, sans fichier déposé sur le disque. Les antivirus et les contrôles d’intégrité de fichiers — qui comparent des empreintes sur disque — passent donc à côté. La détection doit se faire ailleurs : dans les journaux ULS de SharePoint, dans les événements de chargement de contrôle et dans l’historique des web parts récemment ajoutés.

Une exploitation de CVE-2026-65660 passe par l’enregistrement de classes .NET arbitraires via des directives Register injectées. Concrètement, auditez les entrées SafeControls pour repérer les contrôles inhabituels, vérifiez les web parts déployés depuis le 11 août et corrélez avec les journaux d’accès des serveurs autorisant l’accès anonyme. Un serveur patché mais déjà exploité reste compromis : le correctif ne retire pas une classe déjà chargée en mémoire.

Verdict

Si vous exploitez SharePoint Server 2016, 2019 ou Subscription Edition, appliquez sans délai le correctif du 11 août si ce n’est pas déjà fait, et vérifiez le niveau de build avec (Get-SPFarm).BuildVersion — la gravité réelle (RCE authentifiée, potentiellement pré-authentification) dépasse largement le CVSS 6,5 initial. Si vos serveurs autorisent l’accès anonyme aux pages, considérez-vous en situation critique et traitez le patch du 9 juin comme un prérequis au même titre que celui d’août. Si vous triez vos failles sur la seule foi du bulletin fournisseur, ajoutez une règle de contrôle systématique : recroiser l’avis avec l’enregistrement CVE mis à jour et avec le KEV, car Microsoft a montré qu’un spoofing affiché peut être une RCE réelle. CVE-2026-65660 est moins une histoire de code qu’une histoire de confiance — et la confiance dans les métadonnées de sécurité vient de coûter un mois de tri à de nombreuses équipes.

Références

• The Hacker News — SharePoint Flaw Initially Listed as Spoofing by Microsoft Enables Authenticated RCE (22 septembre 2026)
• The Hacker News — SharePoint RCE and MikroTik RouterOS Flaws Actively Exploited in the Wild (26 septembre 2026)
• NVD — CVE-2026-65660
• CISA — Known Exploited Vulnerabilities Catalog