SharePoint CVE-2026-45659 : RCE active, la CISA sonne l’alarme

La faille CVE-2026-45659 affectant Microsoft SharePoint Server a changé de statut opérationnel : il ne s’agit plus seulement d’une vulnérabilité corrigée par l’éditeur, mais d’un risque prioritaire désormais confirmé comme activement exploité. Selon la couverture de The Hacker News, la vulnérabilité a été ajoutée au catalogue KEV de la CISA après constat d’exploitation dans la nature. Pour les équipes sécurité, infrastructure Windows, administrateurs SharePoint et environnements hybrides Microsoft 365, ce basculement est déterminant : un serveur SharePoint on-premises exposé et non corrigé devient une cible de choix pour une compromission initiale, suivie potentiellement d’une élévation d’impact vers l’Active Directory, les comptes de service, les serveurs applicatifs et le SI interne.

Le point central n’est pas seulement la présence d’un correctif publié par Microsoft en mai 2026, mais le fait que l’écosystème défensif américain, via la CISA, considère désormais cette faille comme suffisamment critique et exploitée pour exiger une remédiation prioritaire chez les entités concernées. En pratique, cela signifie que les organisations ayant conservé des déploiements SharePoint Server on-premises, y compris dans des architectures hybrides avec Microsoft 365, doivent vérifier sans délai leurs versions, l’état de patching, l’exposition Internet éventuelle, et les indices de compromission sur les hôtes Windows concernés.

Les informations relayées publiquement à ce stade établissent les faits suivants : CVE-2026-45659 est une exécution de code à distance sur Microsoft SharePoint Server, un correctif a été publié par Microsoft en mai 2026, et la faille a été ajoutée au KEV de la CISA après exploitation active. Le score CVSS n’est pas confirmé dans les éléments fournis ici ; il convient donc de se référer à l’avis Microsoft officiel et à l’entrée KEV de la CISA pour la valeur exacte si elle est publiée. L’enjeu, lui, est clair : sur un serveur SharePoint exposé, l’exécution de code à distance peut ouvrir la voie à une prise de contrôle du serveur, à la collecte d’identifiants, à des rebonds internes et à un mouvement latéral dans un environnement Windows d’entreprise.

Source mentionnée : couverture de The Hacker News sur l’ajout de CVE-2026-45659 au catalogue Known Exploited Vulnerabilities de la CISA, après confirmation d’exploitation active. La source technique de référence reste l’advisory officiel de Microsoft ainsi que l’entrée KEV de la CISA.

Versions affectées

Les éléments communiqués dans le brief confirment que la vulnérabilité touche Microsoft SharePoint Server et qu’une version corrigée a été publiée par Microsoft en mai 2026. En revanche, les numéros de versions exacts affectés et corrigés ne sont pas fournis dans les informations disponibles ici. Dans un contexte de sécurité applicative et d’exploitation active, il est préférable de ne pas inventer de build, de canal de mise à jour ou de KB spécifique.

Sur une base strictement factuelle, on peut donc retenir :

• Produit concerné : Microsoft SharePoint Server en déploiement on-premises.
• Vulnérabilité : CVE-2026-45659.
• Type : exécution de code à distance.
• Statut : corrigée par Microsoft en mai 2026.
• Priorité : élevée, car la CISA a ajouté la faille à son catalogue KEV après exploitation active.

Pour les environnements de production, la bonne pratique consiste à établir immédiatement un inventaire des serveurs SharePoint on-premises, puis à rapprocher chaque instance de l’advisory officiel Microsoft :

• version majeure du produit ;
• niveau de mise à jour installé ;
• date du dernier patch de sécurité ;
• rôle du serveur dans la ferme SharePoint ;
• exposition Internet directe ou via reverse proxy ;
• présence d’interconnexions avec Active Directory, SQL Server, Exchange, ADFS ou d’autres composants Microsoft.

Dans de nombreuses organisations francophones, cet inventaire n’est pas trivial. Des déploiements historiques subsistent encore chez des collectivités, des établissements de santé, des sites industriels et des groupes ayant migré partiellement vers Microsoft 365 sans retirer totalement les briques on-premises. Chez des hébergeurs ou infogéreurs opérant sur OVHcloud, Scaleway, ou sur des infrastructures dédiées administrées pour le compte de clients, cette visibilité doit être obtenue rapidement, y compris lorsque SharePoint n’est plus perçu comme un service exposé de premier plan.

Si l’environnement est managé par un prestataire, il faut exiger :

• la confirmation écrite de la présence ou non de Microsoft SharePoint Server ;
• la version exacte et le niveau de correctif appliqué ;
• la date d’application du patch de mai 2026 ;
• les preuves de redémarrage ou de finalisation du processus de mise à jour si requis par l’éditeur ;
• les journaux de sécurité associés à la période précédant le patch.

En l’absence de certitude sur la version, la posture défensive raisonnable est simple : tout serveur SharePoint Server on-premises non explicitement validé comme corrigé doit être considéré comme potentiellement vulnérable.

Vecteur d’attaque

CVE-2026-45659 est décrite comme une RCE, c’est-à-dire une faille d’exécution de code à distance. Même sans détailler un mécanisme d’exploitation non confirmé publiquement dans les éléments fournis, les conséquences techniques d’une telle classe de vulnérabilité sur SharePoint sont bien connues des équipes défensives : un attaquant peut viser le serveur applicatif lui-même pour exécuter du code dans le contexte du processus affecté, puis exploiter la position centrale de SharePoint dans le SI pour étendre son contrôle.

SharePoint n’est pas un simple site web isolé. Dans les environnements d’entreprise, il s’insère généralement dans un ensemble de dépendances et de relations de confiance :

• authentification intégrée à Active Directory ;
• comptes de service privilégiés ;
• accès à des bibliothèques documentaires sensibles ;
• intégration à SQL Server ;
• liens avec des workflows, composants métiers, connecteurs et outils d’administration ;
• publication externe via reverse proxy, WAF ou frontal web.

Cette centralité fait de SharePoint un point d’entrée particulièrement intéressant pour un acteur malveillant. Lorsqu’une faille RCE est exploitée sur un serveur exposé, plusieurs scénarios deviennent réalistes :

Compromission initiale d’un serveur exposé

Le premier scénario est celui d’un serveur SharePoint directement accessible depuis Internet, ou indirectement exposé via un frontal. L’attaquant vise le service web afin d’exécuter du code sur l’hôte Windows. À partir de là, il peut déposer des outils, ouvrir une session persistante, créer une tâche planifiée, installer un web shell, ou préparer une chaîne d’attaque plus large.

Dans un contexte de réponse à incident, la question n’est pas seulement “le patch est-il appliqué ?” mais aussi “le serveur a-t-il été compromis avant l’application du patch ?”. C’est précisément ce que change l’ajout au KEV de la CISA : la présence d’un correctif ne suffit plus, il faut désormais envisager l’hypothèse d’une exploitation déjà réalisée.

Prise de contrôle applicative et collecte d’identifiants

Une fois l’exécution de code obtenue, l’attaquant peut chercher à récupérer :

• des secrets d’application ;
• des identifiants de comptes de service ;
• des fichiers de configuration ;
• des informations de connexion vers d’autres composants ;
• des jetons ou éléments de session ;
• des artefacts utiles pour rebondir vers d’autres hôtes.

Sur Windows, un serveur SharePoint compromis peut aussi devenir une base de collecte d’informations système : services installés, connexions réseau, appartenance au domaine, privilèges du compte d’exécution, tâches planifiées, journaux applicatifs et traces d’administration distante.

Mouvement latéral en environnement Windows / AD

Le brief éditorial insiste à juste titre sur le mouvement latéral. C’est un point clé pour les RSSI et les administrateurs systèmes. Un serveur SharePoint n’est pas seulement un actif applicatif ; c’est souvent un nœud de confiance dans un domaine Windows. Si l’attaquant obtient une exécution de code suffisante, il peut chercher à :

• rebondir vers SQL Server ;
• cibler des comptes de service réutilisés ;
• accéder à des partages réseau ;
• explorer les relations d’approbation du domaine ;
• préparer une compromission plus large de l’Active Directory.

Le risque est particulièrement important dans les architectures historiques où les comptes de service disposent de droits étendus, ou lorsque les serveurs applicatifs sont placés dans des segments réseau trop permissifs. Dans ce type d’environnement, une RCE sur SharePoint peut devenir l’événement initial d’une attaque de plus grande ampleur.

Impact métier

Au-delà de l’aspect purement technique, la compromission d’un serveur SharePoint a souvent un impact métier direct :

• accès à des documents internes, RH, juridiques ou financiers ;
• altération ou suppression de contenus ;
• indisponibilité de portails internes ou extranet ;
• dégradation de la confiance dans les workflows documentaires ;
• point d’appui pour une campagne de ransomware.

Dans des environnements hybrides Microsoft 365, un autre risque tient à la confusion opérationnelle : certaines équipes supposent que la migration vers le cloud a “réduit” le périmètre SharePoint, alors que des serveurs on-premises subsistent encore pour des besoins de compatibilité, de fédération, d’archives ou d’intégration métier. Ce sont précisément ces îlots résiduels qui peuvent être oubliés dans les cycles de patching, tout en restant exposés.

Pourquoi l’ajout au KEV change la priorité

Le catalogue Known Exploited Vulnerabilities de la CISA n’est pas une simple liste théorique. Il signale des vulnérabilités pour lesquelles une exploitation active a été observée ou confirmée. Pour les équipes de défense, cela a plusieurs implications :

• la fenêtre d’opportunité pour patcher “plus tard” est refermée ;
• les acteurs malveillants ont probablement industrialisé ou partagé des chaînes d’exploitation ;
• les scanners opportunistes et ciblages automatisés augmentent rapidement après médiatisation ;
• les actifs exposés deviennent prioritaires dans les campagnes de compromission.

Autrement dit, une faille SharePoint déjà corrigée mais encore non traitée sort du registre “backlog sécurité” pour entrer dans celui de la gestion d’incident potentielle.

Impact

L’impact principal associé à CVE-2026-45659 est l’exécution de code à distance sur Microsoft SharePoint Server. Dans un environnement réel, cet impact se décline en plusieurs niveaux.

Compromission du serveur SharePoint

Le premier niveau est la compromission complète ou partielle de l’hôte applicatif. L’attaquant peut exécuter des commandes, déposer des fichiers, altérer la configuration, ou maintenir un accès persistant. Cela suffit souvent à dégrader la confidentialité, l’intégrité et la disponibilité du service.

Accès aux données hébergées

SharePoint héberge fréquemment des contenus sensibles : documentation interne, procédures, contrats, dossiers projet, livrables, parfois données réglementées. Une compromission du serveur peut exposer ces contenus à l’exfiltration ou à la manipulation.

Pivot interne

Le troisième niveau, souvent le plus critique, est le pivot vers le reste du SI. Un serveur SharePoint compromis peut servir de tête de pont pour atteindre d’autres systèmes Windows. Ce risque est renforcé lorsque :

• les flux inter-serveurs sont trop ouverts ;
• les comptes techniques sont sur-privilégiés ;
• la segmentation réseau est insuffisante ;
• les outils d’administration distante sont présents ;
• les journaux ne sont pas centralisés ou peu surveillés.

Risque ransomware

Sans affirmer de chaîne spécifique non documentée, il est raisonnable de rappeler qu’une RCE sur un serveur Windows exposé représente un point d’entrée classique pour des opérations d’extorsion. Un attaquant qui obtient un accès initial sur SharePoint peut chercher à élever ses privilèges, se déplacer latéralement, désactiver des protections et chiffrer des ressources critiques.

Pour les organisations françaises soumises à des obligations de continuité, de protection des données ou de notification d’incident, ce risque doit être évalué immédiatement. Si l’exposition Internet est confirmée et si le patch n’a pas été appliqué rapidement après sa publication en mai 2026, une revue forensique devient pertinente.

Comment patcher

Le message opérationnel est simple : appliquer sans délai le correctif Microsoft publié en mai 2026 pour CVE-2026-45659 sur tous les serveurs Microsoft SharePoint Server concernés. Les éléments fournis ici ne détaillent pas le numéro de KB, le build cible ni la procédure exacte propre à chaque édition ; il faut donc s’appuyer sur l’advisory officiel Microsoft et la documentation de mise à jour SharePoint correspondante.

Dans un environnement Windows Server, la remédiation passe généralement par le canal de mise à jour Microsoft utilisé dans l’organisation. Les commandes exactes dépendent de l’outillage en place, mais les approches suivantes sont les plus courantes :

Via Windows Update / Microsoft Update

Si le serveur utilise le mécanisme de mise à jour standard de Microsoft, il faut rechercher et installer la mise à jour de sécurité publiée pour SharePoint en mai 2026, puis redémarrer si nécessaire selon les indications de l’éditeur.

Start > Settings > Windows Update

En environnement administré, cette opération est souvent pilotée centralement et non localement. Il faut alors vérifier dans la console d’administration que le correctif SharePoint a bien été approuvé, distribué et installé sur tous les nœuds concernés.

Via WSUS ou gestion centralisée

Dans de nombreuses infrastructures, le déploiement passe par WSUS, Microsoft Endpoint Configuration Manager ou une solution équivalente. Les équipes doivent :

• identifier la mise à jour de sécurité SharePoint de mai 2026 correspondant à CVE-2026-45659 ;
• approuver le déploiement en urgence ;
• cibler tous les serveurs SharePoint de production, préproduction et secours ;
• contrôler le succès d’installation ;
• vérifier les redémarrages et la disponibilité post-maintenance.

Exemple de vérification PowerShell

La commande ci-dessous ne permet pas, à elle seule, de confirmer la correction de CVE-2026-45659 sans connaître le KB exact, mais elle peut aider à inventorier les mises à jour installées et à documenter l’état du serveur.

Get-HotFix | Sort-Object InstalledOn -Descending

Pour rechercher une mise à jour spécifique lorsque le numéro exact est connu depuis l’advisory Microsoft :

Get-HotFix -Id KBXXXXXXX

Remplacer KBXXXXXXX par l’identifiant officiel communiqué par Microsoft.

Vérifier le niveau de build SharePoint

Les fermes SharePoint nécessitent souvent une vérification applicative complémentaire après installation des correctifs. Selon la version déployée, les administrateurs doivent contrôler :

• la version affichée dans l’administration centrale ;
• l’état de la ferme ;
• la cohérence des nœuds ;
• l’absence d’échec sur les jobs d’administration ou de configuration.

Il est également prudent de valider :

• le fonctionnement des applications web ;
• les accès utilisateurs ;
• les workflows ;
• les intégrations tierces ;
• les connecteurs d’authentification ou de fédération.

Fenêtre de maintenance et précautions

Sur SharePoint, le patching doit être traité comme une opération sensible :

• sauvegarde préalable cohérente ;
• validation des dépendances ;
• ordre de mise à jour documenté ;
• plan de retour arrière ;
• surveillance renforcée après redémarrage.

Pour les environnements hébergés ou infogérés, notamment chez des prestataires s’appuyant sur des infrastructures OVHcloud, Scaleway ou d’autres clouds privés, il faut obtenir la preuve du déploiement effectif et pas seulement l’annonce d’une “campagne de patchs en cours”.

Si le serveur est exposé à Internet et que le patch n’a pas encore été appliqué, la mesure la plus prudente est de réduire immédiatement l’exposition jusqu’à finalisation de la remédiation.

Mitigation

Lorsque l’application immédiate du correctif n’est pas possible, les mesures de mitigation ne remplacent pas le patch, mais elles peuvent réduire la surface d’attaque et limiter le risque pendant une courte période. Étant donné l’exploitation active confirmée par l’ajout au KEV de la CISA, ces mesures doivent être considérées comme transitoires.

Réduire l’exposition Internet

La priorité est de déterminer si le serveur SharePoint est accessible depuis Internet, directement ou via un frontal. Si oui :

• restreindre l’accès par filtrage IP si possible ;
• désactiver temporairement la publication externe non indispensable ;
• limiter l’accès via VPN ou bastion ;
• bloquer les chemins non nécessaires au niveau du reverse proxy ou du WAF.

Dans certaines organisations, cette simple réduction d’exposition permet de casser l’attaque opportuniste le temps d’appliquer le correctif.

Renforcer la surveillance du serveur SharePoint

Un serveur potentiellement ciblé doit faire l’objet d’une surveillance accrue :

• journalisation IIS ;
• événements Windows ;
• création de processus inhabituels ;
• écritures de fichiers dans les répertoires web ;
• tâches planifiées nouvelles ou modifiées ;
• connexions réseau sortantes anormales ;
• authentifications suspectes de comptes de service.

Pour les environnements supervisés par un SIEM, il faut augmenter temporairement le niveau d’alerte sur les hôtes SharePoint et leurs dépendances immédiates.

Durcir les comptes de service

Si l’application du correctif doit attendre une fenêtre de maintenance, il est utile de revoir sans délai :

• les privilèges des comptes de service SharePoint ;
• la rotation des secrets ;
• les droits d’accès aux partages ;
• les délégations Kerberos ou permissions excessives ;
• la séparation des comptes d’administration et d’exploitation.

Cette mesure ne corrige pas la faille, mais elle peut réduire l’impact d’une compromission initiale.

Segmenter et filtrer les flux internes

Le mouvement latéral est une préoccupation majeure. Il convient donc de vérifier rapidement :

• les flux autorisés entre SharePoint et le reste du SI ;
• les accès d’administration à distance ;
• les communications vers les contrôleurs de domaine, SQL Server et serveurs de fichiers ;
• les ports inutiles encore ouverts.

Une segmentation plus stricte peut limiter la capacité de pivot si un serveur est déjà compromis.

Détection

Le passage au statut de vulnérabilité activement exploitée impose une démarche de détection rétrospective et prospective. Même après patch, il faut vérifier si des signes de compromission sont présents.

Indicateurs de compromission à rechercher

Les éléments publics fournis ici ne détaillent pas d’IoC spécifiques publiés par Microsoft ou la CISA pour CVE-2026-45659. Il serait donc imprudent d’inventer des noms de fichiers, chemins ou motifs de requêtes. En revanche, les équipes peuvent rechercher des indicateurs comportementaux cohérents avec une compromission d’un serveur SharePoint :

• requêtes HTTP inhabituelles dans les journaux IIS, en particulier vers des chemins SharePoint rarement sollicités en usage normal ;
• pics de réponses HTTP en 500, 403 ou autres codes anormaux autour de tentatives d’exploitation ;
• création ou modification inattendue de fichiers sous les répertoires applicatifs web ;
• présence de scripts ou binaires non reconnus sur le serveur ;
• lancement de processus enfants depuis des composants web ou services applicatifs ;
• connexions sortantes inhabituelles depuis le serveur SharePoint vers Internet ou vers des segments internes non habituels ;
• authentifications anormales utilisant des comptes de service SharePoint ;
• tâches planifiées, services ou mécanismes de persistance récemment créés ;
• désactivation ou altération des outils de sécurité locaux.

Sources de logs à prioriser

Pour une investigation initiale, les sources suivantes sont prioritaires :

• journaux IIS ;
• journaux d’événements Windows, notamment sécurité, système et application ;
• logs SharePoint natifs ;
• télémétrie EDR ;
• logs du reverse proxy ou du WAF ;
• logs d’authentification Active Directory ;
• journaux réseau des pare-feu et proxys sortants.

Exemples de vérifications système

Ces commandes ne constituent pas des IoC spécifiques à CVE-2026-45659, mais elles peuvent aider à la revue rapide d’un serveur Windows potentiellement compromis :

Get-Process | Sort-Object ProcessName Get-ScheduledTask | Select-Object TaskName,TaskPath,State Get-Service | Sort-Object Status,DisplayName netstat -ano Get-ChildItem -Path "C:\inetpub\" -Recurse | Sort-Object LastWriteTime -Descending

Ces vérifications doivent être corrélées avec la connaissance du serveur, des applications installées et des changements légitimes récents. Une date de modification inhabituelle, un binaire inattendu ou un processus non documenté doit déclencher une investigation plus poussée.

Quand déclencher une réponse à incident

Une réponse à incident formelle doit être envisagée si au moins un des cas suivants est observé :

• serveur SharePoint exposé non patché pendant une période significative après la publication du correctif ;
• traces de requêtes anormales compatibles avec des tentatives d’exploitation ;
• fichiers ou processus suspects sur l’hôte ;
• activité réseau sortante non expliquée ;
• usage anormal de comptes de service ;
• signes de pivot vers d’autres systèmes Windows.

Dans le contexte français, il peut être pertinent de suivre également les communications du CERT-FR si une note ou un relais d’alerte est publié sur ce sujet, notamment pour les administrations, opérateurs et structures soumises à des exigences de sécurité renforcées.

Pourquoi les équipes Windows, hybrides M365 et RSSI doivent réagir immédiatement

Le cas CVE-2026-45659 illustre un schéma désormais classique mais toujours sous-estimé : une vulnérabilité critique est corrigée, puis passe quelques semaines ou mois plus tard dans la catégorie des menaces prioritaires dès qu’une exploitation active est confirmée. Ce décalage entre publication du patch et exploitation réelle pénalise surtout les organisations qui maintiennent un patrimoine on-premises important ou mal inventorié.

Pour les équipes infrastructure Windows, le sujet dépasse le simple patch management. Il faut traiter SharePoint comme un serveur applicatif à haute valeur, potentiellement interconnecté avec des composants critiques du domaine. Pour les administrateurs d’environnements hybrides Microsoft 365, le risque est celui des angles morts : un tenant cloud bien gouverné ne compense pas un serveur SharePoint local oublié ou maintenu pour compatibilité. Pour les RSSI, l’ajout au KEV signifie qu’il faut demander un statut immédiat des actifs concernés, une preuve de remédiation et, si nécessaire, une chasse aux compromissions.

Sur le plan de la gouvernance, cette faille rappelle aussi l’importance :

• d’un inventaire fiable des composants exposés ;
• d’une priorisation basée sur l’exploitation active, pas seulement sur la sévérité théorique ;
• d’une supervision adaptée des serveurs applicatifs Windows ;
• d’une segmentation réseau réellement appliquée ;
• d’une revue régulière des comptes de service et des dépendances AD.

La source initiale relayée par The Hacker News doit être lue comme un signal d’urgence opérationnelle, mais la référence de travail reste l’advisory officiel Microsoft complété par l’entrée CISA KEV. Si vos serveurs Microsoft SharePoint Server ne sont pas explicitement confirmés comme corrigés depuis la publication de mai 2026, il faut les considérer comme prioritaires, réduire leur exposition et lancer immédiatement la vérification de compromission. Pour compléter cette réponse avec des mesures de durcissement et d’hygiène défensive, un détour par la catégorie /categorie/pratiques de FailleWeb est particulièrement pertinent.