SharePoint Server : corriger ne suffit pas, il faut aussi changer les clés

Le CERT-FR publie une quinzaine d'alertes par an. Le reste du temps, ce sont des avis, plus routiniers. Le 22 juillet, SharePoint Server est passé en alerte : CERTFR-2026-ALE-008, deux vulnérabilités critiques, CVE-2026-50522 et CVE-2026-58644.

Les deux permettent à un attaquant non authentifié d'exécuter du code sur le serveur. Pas de compte, pas de clic, pas d'utilisateur à piéger. Une requête suffit. CVE-2026-50522 est notée 9.8 sur 10 au CVSS, ce qui est à peu près le plafond.

La chronologie explique l'urgence. Microsoft a corrigé les deux failles au Patch Tuesday du 14 juillet. Une preuve de concept publique est apparue le 20. D'après watchTowr, ses pots de miel enregistraient des tentatives d'exploitation dans les heures qui ont suivi. C'est la quatrième vulnérabilité SharePoint exploitée en un mois, après CVE-2026-56164 et CVE-2026-58644, toutes deux attaquées avant même l'existence d'un correctif.

Êtes-vous concerné

Une réponse rapide d'abord : si votre entreprise travaille sur SharePoint Online, dans Microsoft 365, ce sujet ne vous concerne pas. Microsoft corrige son propre service, vous n'avez rien à faire.

Le problème vise les fermes SharePoint hébergées sur vos serveurs. Dans une PME, ça arrive plus souvent qu'on ne le croit : un intranet monté il y a huit ans, une GED métier posée dessus, un serveur que personne ne redémarre parce que « tout le monde s'en sert ».

Les versions corrigées, telles que les liste le CERT-FR :

Pour relever votre build, une ligne de PowerShell sur le serveur suffit :

(Get-SPFarm).BuildVersion

En dessous du seuil de votre édition, vous êtes exposé et vous l'êtes depuis le 20 juillet au moins.

Le piège du correctif seul

C'est la partie que je trouve intéressante, et celle qui va coûter cher à ceux qui la sautent.

L'exploitation de CVE-2026-50522 permet de récupérer les clés machine ASP.NET de la ferme en une seule requête. Ces clés servent à signer et chiffrer les jetons d'authentification. Un attaquant qui les possède peut fabriquer des jetons valides quand il veut, depuis n'importe où, y compris après l'installation du correctif.

Autrement dit : le correctif ferme la fenêtre, mais si quelqu'un est passé avant, il a déjà les clés de la maison. C'est exactement le scénario qui a transformé la vague ToolShell de l'an dernier en compromissions longue durée chez des organisations qui pensaient être à jour.

Le CERT-FR le dit explicitement dans son alerte : appliquer les correctifs, et procéder au changement des secrets, dont la rotation des clés machine ASP.NET, en cas de suspicion de compromission.

Le critère pratique, pour une structure qui n'a pas d'équipe SOC : si votre serveur était joignable depuis Internet entre le 20 juillet et le jour où vous avez patché, ne cherchez pas à établir la preuve d'une compromission avant d'agir. Faites la rotation. Elle coûte une fenêtre de maintenance ; ne pas la faire coûte potentiellement le domaine.

L'ordre des opérations

1. Relevez le build de la ferme et comparez-le au tableau ci-dessus.
2. Vérifiez si le serveur est exposé sur Internet. S'il l'est et qu'il n'est pas à jour, coupez la publication le temps de corriger, c'est plus rapide que d'expliquer un rançongiciel.
3. Appliquez la mise à jour de sécurité de juillet, puis redémarrez.
4. Faites tourner les clés machine et redémarrez IIS sur chaque serveur web frontal. Les sessions en cours seront coupées ; prévenez les utilisateurs.
5. Regardez les journaux IIS des jours précédents. Des requêtes POST anormales vers les pages de _layouts sont le signal à chercher.

Reste la question de fond, celle qu'on repousse toujours : est-ce que ce serveur SharePoint a encore une raison d'exister sur site ? Beaucoup de fermes maintenues dans des PME hébergent des documents que SharePoint Online prendrait sans discuter, pour un stockage déjà payé dans l'abonnement Microsoft 365. La migration n'est pas gratuite. Quatre alertes critiques en un mois sur un produit exposé à Internet, non plus.