L’ajout de CVE-2026-45659 au catalogue Known Exploited Vulnerabilities de CISA n’appelle pas à paniquer tous les clients Microsoft 365. Le signal vise surtout les organisations qui exploitent encore un SharePoint Server sur site, géré par elles-mêmes.

Serveur collaboratif sur site derrière un pare-feu avec documents, identités et liste de correctifs

Microsoft a corrigé le problème dans les mises à jour de mai 2026. CISA l’a ajouté à KEV le 1er juillet après preuve d’exploitation active et a fixé le 4 juillet comme échéance pour les agences fédérales concernées. La question reste ouverte ailleurs: savez-vous où sont vos fermes SharePoint locales, si elles ont les builds corrigés, si elles étaient exposées et si quelqu’un les a touchées avant le correctif?

Ce n’est pas une faille pré-authentification. Microsoft indique qu’une authentification et de faibles privilèges sont nécessaires. Cela réduit le bruit, pas la priorité. Les comptes peu privilégiés sont phishés, volés par infostealers, laissés à des prestataires ou hérités de vieux groupes. Une RCE authentifiée dans SharePoint peut transformer un problème d’identité en problème serveur.

Ce qui s’est passé

CVE-2026-45659 est une exécution de code à distance dans Microsoft SharePoint Server due à la désérialisation de données non fiables. CVE.org la classe CWE-502. Le score CVSS Microsoft est 8.8: réseau, faible complexité, faibles privilèges, aucune interaction utilisateur, impact élevé sur confidentialité, intégrité et disponibilité.

Les produits affectés sont SharePoint Server Subscription Edition, SharePoint Server 2019 et SharePoint Enterprise Server 2016 / SharePoint Server 2016. Les builds corrigés sont 16.0.19725.20280 avec KB5002863, 16.0.10417.20128 avec KB5002870 et 16.0.5552.1002 avec KB5002868.

SharePoint Online n’apparaît pas comme produit affecté à corriger par le client. Le risque se situe dans l’entre-deux: fermes hybrides ou héritées gardées pour workflows, archives, sites métiers, composants personnalisés ou migrations jamais terminées.

Corrigé en mai, urgent en juillet

MSRC explique que la vulnérabilité a été corrigée par les mises à jour de mai, mais que le CVE avait été omis par erreur de la liste May 2026 Security Updates. La révision du 26 mai était informative pour les clients déjà à jour.

Une équipe qui a installé mai est probablement couverte. Une autre a pu classer le sujet dans une fenêtre normale, avec une exploitabilité jugée moins probable. L’entrée KEV change la priorité car elle ajoute une preuve d’exploitation réelle.

Il ne faut pas forcément y voir une faute. Le renseignement vulnérabilité évolue. Les attaquants testent, les défenseurs observent. Un bug peut passer d’important à exploité sans changer de description.

Authentifié ne veut pas dire confortable

Microsoft indique qu’un attaquant authentifié peut déclencher la faille, sans privilèges administrateur, avec des permissions minimales de Site Member. Dans beaucoup d’environnements, ce niveau n’est pas rare.

Les permissions SharePoint s’étendent avec les années: projets, partenaires, départements, groupes hérités, comptes de test, prestataires. Une identité volée peut donner peu d’accès seule; avec une ferme vulnérable, elle peut ouvrir la voie à l’exécution de code, à un web shell ou à un mouvement latéral.

La réponse correcte est donc le cadrage: éditions affectées, builds, exposition internet/VPN/partenaires, groupes trop larges, compromissions d’identités récentes et anomalies SharePoint.

Pourquoi SharePoint est précieux

SharePoint ressemble parfois à un vieux portail interne, mais il contient documents, validations, workflows, applications intranet, archives et processus métier. Il est souvent proche d’Active Directory, SQL Server, comptes de service, intégrations Office, code personnalisé et sauvegardes.

Les fermes locales sont difficiles à corriger car elles sont personnalisées. C’est compréhensible, mais l’exploitation active ne respecte pas les fenêtres de maintenance. BleepingComputer a cité des données Shadowserver montrant plus de 10 000 serveurs SharePoint exposés à internet; ce n’est pas le nombre de serveurs vulnérables, mais c’est un signal d’exposition.

KEV transforme le patch en vérification d’incident

Un ticket classique demande si le correctif est installé. Une vulnérabilité exploitée demande aussi: le serveur était-il joignable avant le patch? y a-t-il eu tentative? faut-il une revue forensique avant de fermer?

CISA mentionne l’évaluation de l’exposition et le triage forensique. Installer le correctif est nécessaire, mais peut ne pas suffire si la ferme était exposée. Une ferme interne déjà corrigée et sans logs étranges demande documentation. Une ferme exposée et vulnérable demande correctif ou isolement plus revue. Une ferme avec activité suspecte demande incident response.

Contrôles pratiques

Inventoriez toutes les fermes SharePoint, y compris migration, test, secours, portails partenaires et serveurs derrière reverse proxy. Comparez édition et build aux builds MSRC.

Réduisez l’exposition si le patch immédiat est impossible: accès public restreint, chemins réseau de confiance, entrées inutiles fermées, vérification des règles proxy/WAF. Si le service n’est pas nécessaire, arrêtez-le jusqu’à mise à jour.

Revoyez logs IIS et SharePoint: requêtes authentifiées inhabituelles, uploads ou scripts inattendus, comptes nouveaux, changements de site collections, comportement étrange des processus, PowerShell, scheduled tasks, connexions sortantes. Côté identité, supprimez accès obsolètes et groupes trop larges.

Ce qu’il ne faut pas faire

Ne traitez pas SharePoint Online comme une ferme locale à patcher pour ce CVE. Ne considérez pas “authentifié” comme une raison d’attendre. Ne lancez pas de PoC aléatoires et ne citez pas des dépôts GitHub faibles comme preuve de campagne. CISA confirme l’exploitation; cela suffit pour défendre. N’attribuez pas non plus le CVE à un ransomware: CISA marque cet usage comme inconnu.

Cinq questions

Avez-vous un inventaire complet? Tous les systèmes affectés ont-ils les builds corrigés ou les mises à jour de mai? Certains étaient-ils exposés à internet ou à un accès distant large? Les logs et changements de comptes ont-ils été vérifiés? Savez-vous quels comptes peu privilégiés peuvent s’authentifier?

CVE-2026-45659 est sérieuse parce qu’elle combine collaboration héritée, identité et patching lent. Elle ne signifie pas que tout SharePoint est compromis. Elle rappelle que les vieux serveurs collaboratifs ne doivent pas être invisibles.

Prioriser sans hystérie

La priorité ne se résume pas au CVSS. Une ferme SharePoint interne, déjà corrigée et accessible seulement par des réseaux maîtrisés, n’a pas le même profil qu’un serveur exposé à internet avec des utilisateurs externes et des permissions accumulées depuis des années. Mais KEV change la discussion: lorsqu’une exploitation active est confirmée, il faut vérifier l’état réel, pas le supposer.

L’ordre utile est exposition, version, identité, signaux. Exposition: qui peut atteindre le serveur. Version: le build est-il corrigé. Identité: quels comptes peu privilégiés peuvent s’authentifier. Signaux: les journaux montrent-ils une activité inhabituelle avant le patch. Cet ordre évite la panique et l’inaction.

Pour les MSP et petites équipes, le piège est souvent l’inventaire. Un client peut penser avoir migré vers le cloud tout en gardant une vieille ferme pour des archives, un workflow ou un service qui n’a jamais terminé sa transition. Dans ce cas, la question n’est pas la sécurité du cloud, mais le serveur oublié qui accepte encore des connexions.

La leçon générale

CVE-2026-45659 montre que la gestion des vulnérabilités en 2026 ne se pilote plus seulement par score. Les décisions combinent exploitation observée, exposition, importance métier, réalité des identités et capacité à patcher sans casser le service. SharePoint concentre ces facteurs: ancien, utile, connecté à l’identité et souvent personnalisé.

Une bonne clôture n’est pas seulement “KB installé”. Elle doit inclure inventaire mis à jour, builds vérifiés, exposition réduite, journaux revus, comptes suspects traités et permissions trop larges corrigées. Ce dossier sera précieux la prochaine fois qu’une vulnérabilité changera de statut plusieurs semaines après son correctif.

La conclusion calme est simple: si vous n’exploitez pas SharePoint Server local, ne transformez pas cette alerte en anxiété inutile. Si vous l’exploitez, ne le traitez pas comme un vieux portail ennuyeux. Traitez-le comme une infrastructure critique, proche des documents et de l’identité.