La chaîne, expliquée
CVE-2026-55040 est un contournement de la validation des jetons JWT qui permet à un attaquant distant et non authentifié d'usurper un utilisateur ou un administrateur SharePoint. CVE-2026-63520 est une faille distincte dans les Business Connectivity Services de SharePoint, une instanciation de type .NET non sécurisée qui permet à un attaquant de construire une chaîne d'objets sur mesure pour exécuter des commandes système arbitraires avec les privilèges du compte de service SharePoint. Aucune des deux failles n'est catastrophique à elle seule, mais le chercheur de Rapid7 Stephen Fewer les a révélées toutes deux à Microsoft comme une seule chaîne dès mai, et ensemble elles équivalent à une exécution de code à distance non authentifiée contre SharePoint Server Subscription Edition, SharePoint Server 2019 et SharePoint Enterprise Server 2016.
Microsoft a corrigé les deux moitiés selon des calendriers différents : CVE-2026-55040 est arrivée avec le Patch Tuesday de juillet 2026, et CVE-2026-63520 a suivi un mois plus tard, le 11 août 2026, avec les mises à jour de la base de connaissances KB5002893, KB5002894, KB5002896, KB5002905 et KB5002906 pour les différentes éditions concernées. Selon Rapid7, il n'y a pas encore d'exploitation confirmée de la chaîne RCE complète dans la nature, la divulgation ayant été coordonnée. Pour la première moitié, l'histoire est différente.
Pourquoi diviser le correctif sur deux mois compte
Rapid7 a publié une analyse technique détaillée accompagnée d'une preuve de concept pour CVE-2026-55040, et la société de threat intelligence Defused affirme que ses honeypots SharePoint ont déjà enregistré de vrais attaquants utilisant cette preuve de concept publique pour contourner l'authentification, quelques jours seulement après sa publication. Microsoft elle-même n'a pas encore confirmé d'exploitation dans la nature, mais qu'un réseau de détection indépendant intercepte des tentatives réelles est un signal fort que le balayage opportuniste a déjà commencé.
La partie gênante concerne le calendrier. Comme les deux moitiés de la chaîne ont été corrigées à un mois d'intervalle, une organisation ayant scrupuleusement appliqué le correctif de juillet a passé plusieurs semaines à croire le problème de contournement d'authentification résolu, alors que la seconde moitié, celle qui complète la RCE, est restée sans correctif jusqu'au 11 août. Quiconque n'a pas encore appliqué ensemble les deux mises à jour KB d'août et le correctif de juillet fait actuellement tourner un chemin documenté et démontré publiquement vers une exécution de code non authentifiée sur son propre serveur SharePoint -- pas un chemin théorique.
Ce qu'il faut vérifier sur votre propre parc SharePoint
C'est clairement un problème on-premises : SharePoint Online n'est pas concerné, mais les installations de SharePoint Server 2016, 2019 et Subscription Edition restent courantes dans les organismes publics, universités et entreprises de taille moyenne européennes et britanniques qui n'ont jamais entièrement migré vers le cloud. La liste de contrôle pratique consiste à confirmer que les deux mises à jour KB de juillet et d'août sont installées ensemble, pas seulement l'une des deux, car un correctif partiel laisse la chaîne intacte.
La recommandation permanente de la CISA mérite d'être suivie quel que soit l'état des correctifs : ne pas exposer un serveur SharePoint on-premises directement à internet, et là où il doit être accessible, le placer derrière un reverse proxy de couche 7 ou un contrôle équivalent au niveau applicatif capable de filtrer le type de requêtes forgées dont dépend cette chaîne. Puisqu'une preuve de concept publique et fonctionnelle existe déjà pour la moitié de la chaîne, traitez ce sujet cette semaine comme un incident actif à traiter, pas comme une ligne de routine dans le cycle de correctifs.
À lire ensuite: Le correctif SharePoint que vous avez ignoré en mai est maintenant urgent | Le rançongiciel Gunra exploite des failles Fortinet corrigées en 2025
