La vulnérabilité sous attaque active
Ce n'est pas un avis théorique ; la faille est exploitée en ce moment même. Le 17 juillet 2026, l'agence américaine de cybersécurité CISA a ajouté CVE-2026-58644, une vulnérabilité critique de Microsoft SharePoint Server, à son catalogue des vulnérabilités exploitées connues et a ordonné aux agences civiles fédérales de la corriger avant le 19 juillet. Le défaut est une désérialisation de données non fiables d'une gravité de 9,8 sur 10, qui permet à un attaquant sans identifiants d'exécuter du code arbitraire sur le serveur.
Il n'est pas isolé. Un groupe de failles de SharePoint Server est enchaîné dans la nature pour contourner l'authentification, obtenir l'exécution de code à distance et mener une activité de suite. SharePoint auto-hébergé a ici une longue histoire : depuis fin 2021, les régulateurs ont signalé près d'une douzaine de ses vulnérabilités comme exploitées dans des attaques, et la plupart ont ensuite servi à des rançongiciels.
Pourquoi un correctif seul ne vous sauvera pas
Le danger est ce que les attaquants emportent en entrant. Pendant l'exploitation, ils volent les clés machine cryptographiques du serveur, les secrets que SharePoint utilise pour signer et valider les jetons qui accordent l'accès. Une fois qu'un attaquant détient ces clés, il peut forger des identifiants valides à volonté, et il peut le faire contre un serveur que vous avez déjà mis à jour.
C'est le piège de cet incident. Appliquer le correctif de Microsoft ferme le trou par lequel l'intrus est entré, mais ne fait rien pour les clés qu'il a déjà copiées. Un SharePoint Server corrigé et entièrement à jour peut encore être réinvesti avec des clés volées, c'est pourquoi la remédiation ne s'arrête pas au correctif. Si vous ne renouvelez pas les clés machine, vous pouvez vous croire en sécurité alors que la porte reste discrètement ouverte.
Qui est réellement exposé
C'est un problème sur site, pas dans le cloud. La vulnérabilité touche SharePoint Server auto-hébergé, la version qu'une organisation exécute sur sa propre infrastructure. SharePoint Online de Microsoft 365, le service hébergé, n'est pas la cible de ces exploits précis. Le risque se concentre donc justement dans les installations que beaucoup de PME, d'organismes publics, de cabinets d'avocats et d'établissements financiers européens gardent en interne.
Souvent ils les gardent en interne pour de bonnes raisons : résidence des données, règles sectorielles ou décision de conserver des documents sensibles sur une infrastructure qu'ils maîtrisent. Ce choix est légitime, mais il signifie aussi que le correctif, le renouvellement des clés et la surveillance relèvent entièrement de votre responsabilité. La commodité qu'un fournisseur cloud aurait gérée en silence est, sur site, une tâche à votre nom avec un compte à rebours.
Ce que cela signifie selon les règles de l'UE
L'échéance américaine ne vous lie pas, l'urgence si. Le 19 juillet vaut pour les agences fédérales américaines ; un opérateur européen n'y a aucune obligation légale. Traitez-la plutôt comme un signal public de la vitesse à laquelle cela avance, car les mêmes serveurs et le même code d'exploitation ne s'arrêtent à aucune frontière. Des autorités nationales comme le BSI allemand et le NCSC britannique émettent leurs propres avis sur exactement ce type de faille activement exploitée.
Sous la NIS2 et, pour les entités financières, la DORA, une intrusion réussie ici est un incident à notifier avec des délais serrés et une responsabilité au niveau du conseil. Un entrepôt de documents plein de contrats, de données personnelles et de dossiers internes est justement le bien que ces règles existent pour protéger. Être lent à corriger une vulnérabilité connue et exploitée est le genre de manquement qu'un régulateur lit comme une négligence, pas comme de la malchance.
Que faire maintenant
Agissez dans l'ordre et supposez le pire là où vous ne pouvez prouver le contraire. Appliquez immédiatement les mises à jour de SharePoint Server de Microsoft, puis renouvelez les clés machine IIS afin que les clés volées deviennent inutiles. Cherchez des signes de compromission : web shells inattendus, fichiers inconnus dans les répertoires du serveur, clés nouvelles ou modifiées et événements d'authentification qui ne correspondent pas à vos utilisateurs. Réduisez la surface d'attaque en retirant du réseau ouvert tout SharePoint exposé à internet là où vous le pouvez.
Si votre serveur a été accessible et non corrigé à un moment quelconque depuis la divulgation, traitez-le comme compromis et enquêtez sur cette base plutôt que d'espérer qu'il soit passé inaperçu. Le coût de supposer une compromission que vous n'aviez pas est quelques heures d'examen ; le coût de supposer une sécurité que vous n'aviez pas est l'incident lui-même.
À lire ensuite: Onze chargeurs signés contournent Secure Boot | 570 correctifs Windows en un jour, deux déjà exploités
