Les alertes autour de Microsoft SharePoint en juillet 2026 rappellent une leçon souvent oubliée en cybersécurité : un correctif ferme la porte, mais il ne supprime pas forcément ce qui a déjà été volé. Pour les instances SharePoint exposées sur Internet, la priorité ne se limite donc pas à installer la mise à jour. Il faut aussi se demander si l'attaquant a pu récupérer des secrets lui permettant de revenir.

Le CERT-FR et le CERT-EU alertent sur plusieurs vulnérabilités critiques affectant SharePoint Server, dont CVE-2026-50522 et CVE-2026-58644. Ces failles permettent une exécution de code arbitraire à distance sur des versions on-premise vulnérables. Le point le plus préoccupant est opérationnel : des exploitations actives ont été observées, avec un risque de vol de clés de machine ASP.NET.

Pourquoi les clés de machine changent tout

Dans beaucoup d'incidents, les équipes ont un réflexe simple : identifier le serveur vulnérable, appliquer le patch, redémarrer, vérifier que le scanner de vulnérabilités passe au vert. C'est nécessaire, mais insuffisant quand des secrets d'application ont pu sortir du serveur.

Les clés de machine ASP.NET servent notamment à protéger et valider certains états, tickets et mécanismes cryptographiques liés aux applications .NET. Si un attaquant les récupère, il peut parfois conserver une capacité d'action même après l'installation d'un correctif. C'est précisément pour cela que le CERT-FR recommande, en cas de soupçon de compromission, de changer les secrets, y compris ces clés.

Le raisonnement est le même que pour un mot de passe administrateur ou une clé API. Corriger la vulnérabilité qui a permis le vol ne rend pas automatiquement le secret volé inutilisable. Il faut le remplacer.

Le périmètre à traiter

La première étape consiste à lister les serveurs SharePoint concernés : version, exposition Internet, rôle dans la ferme, date du dernier patch, comptes utilisés, connecteurs associés, accès à des partages, bases SQL, annuaires et systèmes documentaires sensibles.

Une instance SharePoint n'est pas un simple serveur web. Elle est souvent au centre de flux documentaires, de workflows internes et d'authentifications anciennes. Une compromission peut donc toucher bien plus que le site lui-même : documents confidentiels, identités de service, tokens, scripts de maintenance, exports et historiques.

Les serveurs directement accessibles depuis Internet doivent être prioritaires. Si l'exposition est encore nécessaire, elle doit être réévaluée. Dans beaucoup d'organisations, SharePoint on-premise reste exposé parce qu'il l'a toujours été, pas parce qu'une analyse récente l'a justifié.

Que faire après le patch

Après l'installation des mises à jour Microsoft, il faut vérifier la version réelle des binaires, pas seulement l'état de Windows Update. Il faut aussi contrôler que tous les noeuds de la ferme ont bien été traités. Une ferme partiellement corrigée reste fragile.

Ensuite vient la rotation des secrets. Les clés de machine ASP.NET doivent être remplacées selon les procédures Microsoft adaptées à l'environnement. Les comptes de service, secrets applicatifs et identifiants exposés doivent aussi être revus. Cette étape est pénible, mais elle évite de croire qu'un serveur nettoyé reste contrôlé alors qu'un secret compromis circule encore.

La recherche d'indicateurs de compromission doit couvrir les journaux IIS, les journaux SharePoint, les processus anormaux, les web shells, les tâches planifiées, les nouveaux comptes, les modifications de configuration et les connexions sortantes inhabituelles. Il faut conserver les preuves avant de nettoyer, surtout si l'incident peut avoir un impact réglementaire ou contractuel.

Le piège du serveur historique

SharePoint on-premise illustre un problème plus large : les applications historiques restent critiques longtemps après avoir cessé d'être visibles dans la roadmap. Elles hébergent des documents importants, mais leur exploitation quotidienne repose parfois sur une connaissance dispersée entre anciennes équipes, prestataires et procédures non mises à jour.

Quand une faille critique arrive, cette dette opérationnelle devient visible. Qui sait appliquer le patch ? Qui connaît les dépendances ? Qui peut couper l'accès externe sans casser un métier ? Qui sait restaurer ? Qui possède les secrets ? Ces questions devraient être posées avant l'incident.

La mesure pragmatique

La réponse réaliste tient en cinq actions : patcher vite, retirer l'exposition inutile, faire une analyse de compromission, remplacer les secrets et documenter ce qui a été fait. Le reste dépend du contexte, mais ces cinq points évitent l'erreur la plus dangereuse : considérer qu'un correctif efface l'incident.

Les vulnérabilités SharePoint de juillet 2026 ne sont pas seulement un sujet Microsoft. Elles rappellent que la sécurité d'un service exposé dépend autant de la réaction après exploitation que de la vitesse de patch.