Le 14 juillet 2026, à l'occasion de sa mise à jour mensuelle, Microsoft a publié des correctifs pour deux vulnérabilités critiques affectant SharePoint Server. Le 22 juillet, le CERT-FR émettait une alerte. Pour les équipes qui ont vécu juillet 2025 et l'alerte CERTFR-2025-ALE-010, le sentiment de déjà-vu est justifié — et instructif.
Ce qui est affecté
Les vulnérabilités CVE-2026-50522 et CVE-2026-58644 permettent toutes deux à un attaquant non authentifié d'exécuter du code arbitraire à distance. Sont concernés SharePoint Enterprise Server 2016, SharePoint Server 2019 et SharePoint Server Subscription Edition, dans des versions antérieures aux builds correctifs listés par l'éditeur. Il s'agit des déploiements sur site — les instances SharePoint Online ne sont pas dans ce périmètre.
Microsoft a indiqué dès son avis du 14 juillet que CVE-2026-58644 était activement exploitée. Le 21 juillet, l'entreprise de sécurité watchTowr déclarait avoir connaissance d'une preuve de concept publique ainsi que d'exploitations actives de CVE-2026-50522. En une semaine, on est donc passé d'une vulnérabilité exploitée à deux, dont une avec un code d'exploitation en circulation libre.
Le piège : le correctif ne révoque pas les secrets volés
En cas de soupçons de compromission, le CERT-FR recommande également le changement des secrets, incluant la rotation des clés de machine ASP.NET du SharePoint Server. Le vol de ces secrets peut permettre à l'attaquant de revenir après l'application de la mise à jour. — CERT-FR, CERTFR-2026-ALE-008
C'est le point qui distingue une remédiation réussie d'une remédiation apparente. Les clés de machine ASP.NET signent et chiffrent les données d'état de l'application, notamment le ViewState. Un attaquant qui les a exfiltrées peut fabriquer un ViewState valide et obtenir une exécution de code — sur un serveur parfaitement à jour, par un mécanisme applicatif légitime, sans exploiter la moindre vulnérabilité. Aucune signature ne se déclenchera.
La séquence correcte est donc : appliquer le correctif, puis faire tourner les clés de machine, puis redémarrer IIS. Dans cet ordre. Tourner les clés avant d'avoir corrigé revient à laisser l'attaquant en voler de nouvelles.
Chercher rétroactivement, pas seulement corriger
Sur une vulnérabilité exploitée avant publication du correctif, la question n'est jamais « suis-je vulnérable » mais « ai-je déjà été visité ». Les points de collecte que nous examinons en priorité :
- Les fichiers déposés dans les répertoires servis par IIS, en particulier les extensions .aspx apparues en dehors d'une fenêtre de déploiement connue.
- Les processus enfants du pool d'applications IIS : un w3wp.exe qui lance un interpréteur de commandes ou PowerShell est un signal à traiter comme un incident, pas comme une anomalie.
- Les journaux IIS sur la période précédant le correctif, à la recherche de requêtes POST vers les points d'entrée concernés depuis des adresses sans historique.
- Les connexions sortantes du serveur SharePoint. Un serveur de collaboration interne n'a, en régime normal, aucune raison d'initier du trafic vers Internet.
La question qu'il faut finir par poser
SharePoint on-premise a fait l'objet d'alertes CERT-FR critiques deux étés de suite. Pour la plupart des organisations que nous accompagnons, ce serveur héberge une bibliothèque documentaire dont l'usage réel a fondu au profit d'autres outils, mais que personne n'ose décommissionner faute d'inventaire de ce qu'elle contient.
Le coût de maintien d'un SharePoint on-premise correctement sécurisé — veille, correctifs en urgence, rotation de secrets, surveillance dédiée — est désormais supérieur au coût d'un audit de contenu suivi d'une migration ou d'un décommissionnement. Si l'exercice de juillet vous a coûté un week-end, il vaut la peine de chiffrer la sortie plutôt que le prochain week-end.
L'équipe SOC