SharePoint CVE-2026-50522 et CVE-2026-55040 : patcher

Microsoft SharePoint Server, utilisé pour la gestion documentaire et l'intranet de nombreuses organisations, a subi en 2026 une série de failles critiques exploitées en conditions réelles, dont la faille CVE-2026-55040. Deux d'entre elles ont chacune donné lieu à un outil de démonstration public.

Avertissement : ForenShield n'est pas responsable de l'usage que vous faites de ces informations. Tester ou attaquer un serveur qui ne vous appartient pas, sans autorisation écrite, est une infraction pénale dans la plupart des pays.

Une vague de failles, pas une seule

Depuis juillet 2026, Microsoft a publié des correctifs pour un ensemble de vulnérabilités SharePoint aux effets très différents :

À retenir : les failles « non authentifiées à exécution de code » sont, de loin, les plus urgentes à corriger. Les failles d'usurpation nécessitent qu'un utilisateur ouvre un document piégé : le risque existe, mais la fenêtre d'action pour l'attaquant est plus étroite.

CVE-2026-55040 et CVE-2026-50522 : les deux failles avec un outil public

CVE-2026-50522 : désérialisation non authentifiée

Selon l'alerte du CERT-FR, cette faille de désérialisation de données non fiables permet à un attaquant distant non authentifié de faire exécuter des commandes par le serveur, simplement en lui envoyant des données forgées sur le réseau. Une preuve de concept publique a circulé dès le 20 juillet 2026, et l'exploitation active a été confirmée par watchTowr le lendemain. Le CERT-FR a publié son alerte le 22 juillet 2026.

CVE-2026-55040 : contournement d'authentification par jeton JWT

Selon l'analyse technique de Rapid7, le défaut réside dans la validation des jetons JWT de SharePoint : un attaquant peut forger un jeton non signé et se faire passer pour n'importe quel utilisateur du site, y compris un administrateur, sans mot de passe. La faille, découverte lors d'un concours de sécurité, a été corrigée par Microsoft le 14 juillet 2026, mais l'exploitation active n'a commencé que quelques heures après la publication d'une preuve de concept publique, le 11 août 2026.

Ces deux cas illustrent un schéma récurrent : la publication d'un outil de démonstration accélère fortement l'exploitation à grande échelle, même quand le correctif existe déjà depuis plusieurs semaines.

Produits concernés

• Microsoft SharePoint Enterprise Server 2016
• Microsoft SharePoint Server 2019
• Microsoft SharePoint Server Subscription Edition

D'après le tableau de versions du CERT-FR, les versions corrigées pour la vague de juillet 2026 sont notamment 16.0.5561.1001 et suivantes (Enterprise Server 2016), 16.0.10417.20175 et suivantes (Server 2019), et 16.0.19725.20434 et suivantes (Subscription Edition). Pour la CVE-2026-55040 spécifiquement, les correctifs sont diffusés via les mises à jour KB5002882 (Subscription Edition), KB5002883 (Server 2019) et KB5002891 (Enterprise Server 2016), selon les identifiants rapportés par Rapid7. Vérifiez systématiquement le numéro de build installé plutôt que la seule date d'application des mises à jour, car plusieurs vagues de correctifs se sont succédé sur ces produits en quelques semaines.

Comment corriger et se protéger

1. Appliquer sans délai les mises à jour de sécurité correspondant à votre édition, et vérifier le numéro de build après installation.
2. Réduire l'exposition réseau. La CISA recommande d'éviter d'exposer un serveur SharePoint directement sur Internet ; si l'exposition est nécessaire, placer un relais applicatif de couche 7 avec authentification et filtrage des requêtes devant le serveur.
3. Bloquer l'accès externe à l'administration centrale de SharePoint et restreindre les communications entre la ferme de serveurs et la base de données aux seuls systèmes nécessaires.
4. Activer l'intégration AMSI (Antimalware Scan Interface) pour les applications web SharePoint, en mode d'analyse complet du corps des requêtes lorsque c'est possible.
5. Renouveler les secrets exposés. Le CERT-EU recommande de faire tourner les identifiants de tout système ayant pu être vulnérable et exposé à Internet, ainsi que les clés machine ASP.NET (machineKey) après avoir recherché d'éventuelles traces de leur vol, car un attaquant qui les a collectées avant la mise à jour peut s'en servir même après le correctif.
6. Mener une recherche de compromission avant de considérer l'incident clos : la mise à jour empêche une nouvelle exploitation, mais ne supprime pas un accès déjà établi.

À retenir : corriger sans faire tourner les clés machine, quand le serveur a été exposé pendant la période active, laisse une porte ouverte : la clé volée reste valide même après la mise à jour.

Détecter une tentative ou une compromission

• Recherchez, dans Microsoft Defender, les alertes Backdoor:MSIL/LeakFang.A!dha, qui signalent une activité post-exploitation connue sur ces failles.
• Si AMSI est activé, surveillez les détections Exploit:Script/SuspSignoutReqBody.A, Exploit:Script/ToolPaneAuthBypass.A et Exploit:Script/ToolPaneAuthBypass.C.
• Passez en revue les journaux d'authentification à la recherche de connexions ou d'accès administrateur inhabituels, en particulier depuis des adresses inconnues.
• Cherchez des processus de travail (worker process) suspects ou des fichiers de type web shell déposés sur le serveur.

Pour l'analyse des journaux Windows du serveur, un outil comme l'analyseur de journaux d'événements Windows de ForenShield peut accélérer le tri des événements d'authentification et de processus suspects.

Quand est-il légitime de tester la vulnérabilité ?

Deux outils publics existent : le programme d'exploitation de sfewer-r7 pour la CVE-2026-55040, publié le 11 août 2026, et le gist de testanull pour la CVE-2026-50522, publié le 20 juillet 2026. Tester est acceptable uniquement dans l'un de ces cas :

• Votre propre serveur SharePoint, dans un environnement isolé, sans données réelles et sans exposition à Internet.
• Un test d'intrusion contractualisé, avec un périmètre écrit, des dates précises et l'accord signé du propriétaire du serveur.
• Un exercice de formation (CTF, plateforme de laboratoire) conçu pour cela.

Dans tous les autres cas, n'essayez pas. Se faire passer pour un utilisateur ou exécuter du code sur le serveur d'un tiers, même « pour vérifier », constitue un accès frauduleux à un système d'information. Si vous constatez qu'une instance tierce est vulnérable, prévenez son propriétaire ou le CERT compétent, sans tenter d'y accéder.

Ce que cette vague rappelle

• Un correctif appliqué à temps ne suffit pas toujours : sans rotation des clés et sans recherche de compromission, un accès déjà obtenu peut survivre à la mise à jour.
• Les serveurs SharePoint exposés directement sur Internet restent la cible prioritaire : la CISA et le CERT-EU convergent sur ce point depuis plusieurs vagues successives.
• La publication d'une preuve de concept change la donne : un correctif publié depuis des semaines peut se retrouver massivement exploité dans les heures qui suivent la mise en ligne d'un outil de démonstration.

Pour suivre le détail d'une vulnérabilité par identifiant, la base CVE de ForenShield est disponible, et le calculateur CVSS aide à qualifier la criticité selon votre contexte.

Sources

• CERT-FR : multiples vulnérabilités dans Microsoft SharePoint (CERTFR-2026-ALE-008)
• CISA : recommandations de durcissement SharePoint après de nouvelles exploitations
• CERT-EU : vulnérabilités critiques dans Microsoft SharePoint
• Rapid7 : analyse technique du contournement JWT CVE-2026-55040
• Programme de démonstration sfewer-r7 pour CVE-2026-55040 (usage autorisé uniquement)
• Gist de démonstration testanull pour CVE-2026-50522 (usage autorisé uniquement)