Ce qui s'est passé
Le 14 juillet 2026, lors de son rendez-vous mensuel de correctifs (le fameux « Patch Tuesday »), Microsoft a corrigé 622 vulnérabilités en une seule fois. C'est un record absolu : plus de trois fois le précédent sommet. Deux de ces failles étaient déjà exploitées par des attaquants le jour même de leur publication — l'une dans le service de fédération d'identités Active Directory, l'autre dans SharePoint Server.
Les jours suivants, la situation s'est aggravée sur SharePoint. Une faille critique (référencée CVE-2026-58644, notée 9,8 sur 10) permet d'exécuter du code à distance sur un serveur SharePoint vulnérable. Elle a été exploitée activement avant même la mise à disposition du correctif, ce qui a conduit l'agence américaine de cybersécurité (CISA) à l'inscrire à son catalogue des failles activement exploitées — le signal que ce n'est plus une menace théorique mais une campagne en cours.
Détail qui a son importance : les assaillants ne se contentent pas d'entrer. Ils volent au passage les clés de chiffrement internes du serveur, celles qui lui servent à signer les sessions. Nous verrons plus loin pourquoi ce détail change tout.
La première question : est-ce que ça me concerne ?
Avant de s'inquiéter, il faut trancher un point que beaucoup d'articles alarmistes passent sous silence. Ces failles SharePoint ne touchent qu'une seule version du produit : SharePoint Server, celui qu'une entreprise installe et administre sur ses propres serveurs.
Si vous utilisez SharePoint à travers un abonnement Microsoft 365 / SharePoint Online — le cas de l'immense majorité des PME —, vous n'êtes pas exposé à cette faille : c'est Microsoft qui héberge et corrige ces serveurs, la mise à jour a été appliquée pour vous sans que vous ayez à lever le petit doigt. C'est, au passage, l'un des arguments concrets du cloud : la corvée des correctifs devient le problème de quelqu'un d'autre.
Autrement dit, la bonne réaction n'est pas de paniquer, mais de savoir ce que vous hébergez vous-même. Un vieux serveur SharePoint installé en interne il y a des années et à moitié oublié ? C'est exactement le genre de machine qui doit être identifiée, corrigée en priorité — et surveillée.
Pourquoi 622 correctifs, et pourquoi ça vous concerne quand même
Même sans serveur SharePoint sous le coude, ce Patch Tuesday hors norme envoie un message qui vaut pour toutes les PME. Six cent vingt-deux correctifs, c'est un volume impossible à trier à la main. Aucune petite entreprise n'a le temps de lire les bulletins de sécurité un par un pour décider lesquels appliquer.
La conséquence est claire : la gestion des mises à jour ne peut plus reposer sur la bonne volonté et le « on verra le mois prochain ». Il faut une mécanique :
- Les mises à jour automatiques activées partout où c'est possible — postes, serveurs, applications métier, équipements réseau.
- Un inventaire de ce qui tourne, pour ne pas découvrir trop tard qu'une machine exposée était restée en marge des mises à jour.
- Une priorité donnée à ce qui est activement exploité. On ne corrige pas 622 choses le même jour ; on commence par la poignée que des attaquants utilisent déjà. Le catalogue public de la CISA existe précisément pour ça, et c'est un repère qu'un prestataire suit à votre place.
C'est la même logique de fond que pour le système d'exploitation : rester sur une version encore suivie et corrigée par l'éditeur, un sujet que nous avions détaillé à propos de la migration vers Windows 11 Pro. Un logiciel qui ne reçoit plus de correctifs est une porte qu'on laisse ouverte.
Le piège : patcher ne suffit pas toujours
Revenons aux clés volées. C'est le point le plus contre-intuitif de cette affaire, et le plus instructif. Sur SharePoint, les attaquants récupèrent les clés de signature du serveur. Une fois ces clés entre leurs mains, appliquer le correctif ne les met pas dehors : ils peuvent continuer à se fabriquer des accès valides comme s'ils étaient le serveur lui-même.
C'est pour cela que les experts insistent : sur les serveurs touchés, il faut corriger, mais aussi renouveler ces clés, chercher les traces d'intrusion et, au besoin, reconstruire la machine. La mise à jour ferme la fenêtre ; elle n'expulse pas celui qui est déjà entré.
Cette leçon dépasse largement SharePoint. Elle rejoint ce que nous écrivions à propos de l'incident Hugging Face : on ne peut plus miser uniquement sur la prévention. Il faut aussi être capable de voir — des journaux conservés, une alerte qui part vraiment, quelqu'un qui la lit — et de restaurer. Une sauvegarde testée et une intrusion détectée en heures plutôt qu'en mois, c'est ce qui sépare l'incident du désastre.
Ce qu'une PME peut faire cette semaine
Rien de tout cela ne demande un budget de grand groupe :
- Faire l'inventaire de ce que vous hébergez vous-même. Serveurs, applications installées en interne, services exposés sur Internet. On ne protège que ce qu'on a recensé.
- Activer les mises à jour automatiques partout où c'est possible, et raccourcir le délai sur les composants exposés — c'est la mesure au meilleur rapport effort/résultat.
- Rester sur des versions encore suivies. Un logiciel en fin de vie ne reçoit plus les correctifs comme ceux de ce mois-ci.
- Préférer le managé quand le correctif est le vrai problème. Pour beaucoup d'usages, laisser l'éditeur héberger et mettre à jour est plus sûr que d'entretenir un serveur soi-même.
- Savoir qu'on saurait voir, et restaurer. Journaux, alertes, et surtout des sauvegardes qu'on a réellement testées en restauration.
Notre lecture
Un record de 622 correctifs n'est pas un accident : c'est la nouvelle normalité. La surface d'attaque s'élargit, et le délai entre la découverte d'une faille et son exploitation se réduit — parfois à quelques jours, comme ici. Dans ce contexte, la sécurité d'une PME ne se joue pas sur un pare-feu héroïque, mais sur des gestes modestes et réguliers : savoir ce qu'on expose, le tenir à jour sans y penser, et garder la capacité de voir et de restaurer le jour où quelque chose passe.
Sources : les bulletins de sécurité de Microsoft (Patch Tuesday du 14 juillet 2026) et le catalogue des vulnérabilités activement exploitées de la CISA, complétés par les analyses de SecurityWeek, The Hacker News, Help Net Security et Malwarebytes. Les correctifs et descriptions de failles proviennent de Microsoft, éditeur du produit concerné.