CVE-2026-32201 : 1300 SharePoint exposés, KEV 28/4

Les faits

Microsoft a publié le 14 avril 2026 le correctif de CVE-2026-32201, une vulnérabilité de spoofing affectant SharePoint Server et découlant d'une validation d'entrée insuffisante dans la logique de traitement des requêtes. Selon l'éditeur, la faille était déjà exploitée comme zero-day au moment de la publication, ce qui a conduit la CISA à l'inscrire à son catalogue KEV dès le 28 avril 2026. Le score CVSS de 6.5 masque une réalité opérationnelle bien plus dure : l'exploitation ne requiert ni authentification préalable, ni interaction utilisateur, et permet à un attaquant distant d'usurper l'identité d'un utilisateur légitime pour pivoter vers les données hébergées. Avec près de 1300 instances SharePoint exposées sur Internet et recensées par les moteurs de scan, la surface d'attaque reste considérable et impose un traitement en urgence.

Plusieurs sources concordantes (BleepingComputer, Cyber Security News, SentinelOne) recensent au 26 avril plus de 1 370 serveurs SharePoint accessibles publiquement et toujours vulnérables. La CISA a inscrit la CVE à son catalogue Known Exploited Vulnerabilities dès le 14 avril, avec une deadline de remédiation au 28 avril 2026 pour les agences fédérales américaines (FCEB).

Impact et exposition

Sont concernées les versions SharePoint Enterprise Server 2016, SharePoint Server 2019 et SharePoint Server Subscription Edition (modèle continuous update). Un attaquant non authentifié envoie des requêtes HTTP forgées contre les endpoints publics du serveur, manipulant les chaînes de requête, en-têtes ou champs de formulaire pour influencer la manière dont les contenus sont rendus. Concrètement, des données contrôlées par l'attaquant apparaissent comme du contenu légitime du portail, ouvrant la voie à des usurpations d'identité applicatives, à du vol de session par phishing interne crédibilisé, ou à des escalades vers d'autres systèmes intégrés (Teams, OneDrive, connecteurs métier).

Recommandations

• Appliquer immédiatement le correctif d'avril 2026 sur toutes les instances SharePoint Server, y compris celles considérées comme « internes » derrière un VPN ou un reverse proxy
• Auditer les logs IIS et SharePoint des 30 derniers jours pour détecter des requêtes anormales sur les endpoints _layouts/15/, _api/, _vti_bin/ avec des en-têtes ou paramètres atypiques
• Restreindre l'exposition publique des SharePoint on-premises : pré-authentification au niveau du reverse proxy (WAF, Azure AD App Proxy, F5 APM) avant toute requête atteignant le serveur
• Mettre en place une rotation des secrets des comptes de service et des Managed Service Accounts utilisés par SharePoint, par précaution post-exploitation

Le score CVSS de 6.5 reflète-t-il vraiment la criticité ?

Le vecteur CVSS 3.1 associé à CVE-2026-32201 se lit AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N : attaque réseau, complexité faible, aucun privilège requis, aucune interaction utilisateur, mais un impact limité à l'intégrité seule (I:L), sans confidentialité ni disponibilité affectées selon la métrique brute. C'est précisément ce sous-score d'impact qui tire la note finale vers 6.5 alors que les quatre premières métriques — les plus critiques pour un attaquant — sont toutes au maximum. Ce découplage entre « facilité d'exploitation » et « impact mesuré par le CVSS » est un piège classique : le score ne capture pas la valeur d'une usurpation de contenu SharePoint comme vecteur d'accès initial pour un déplacement latéral vers Teams, OneDrive ou des connecteurs SSO. C'est cette logique de « gravité contextuelle supérieure au score brut » qui a justifié l'inscription immédiate au catalogue KEV de la CISA, un signal que les équipes de gestion des vulnérabilités devraient traiter comme prioritaire indépendamment du chiffre affiché. Le précédent le plus proche reste la chaîne ToolShell (CVE-2025-53770/53771) exploitée en 2025 sur des serveurs SharePoint on-premises, où une faille jugée modérée sur le papier avait servi de porte d'entrée à des opérations de vol de MachineKey et de déploiement de webshells persistants.

Quels indicateurs surveiller dans les logs SharePoint ?

La détection repose sur le croisement des journaux IIS et des logs ULS (Unified Logging Service) de SharePoint. Les indicateurs à rechercher en priorité : requêtes HTTP présentant des chaînes de requête ou en-têtes anormalement longs ou encodés vers les endpoints /_layouts/15/ et /_vti_bin/ ; réponses 200 sur des ressources habituellement protégées sans authentification préalable visible dans les logs d'authentification Windows ; pics de requêtes provenant d'une même adresse IP externe sur de courtes fenêtres temporelles, typiques d'un scan automatisé post-divulgation. Les équipes SOC disposant d'un SIEM devraient créer une règle de corrélation associant absence de jeton d'authentification valide et accès réussi à ces chemins. Microsoft Defender for Endpoint et les solutions XDR intègrent déjà des signatures spécifiques à cette CVE depuis la publication du correctif ; leur activation doit être vérifiée manuellement sur les déploiements on-premises, qui ne bénéficient pas des mises à jour cloud automatiques.

Votre infrastructure est-elle exposée ?

Une vérification rapide consiste à interroger Shodan ou Censys avec les bannières caractéristiques de SharePoint Server (en-tête MicrosoftSharePointTeamServices) pour identifier les instances exposées publiquement, puis à croiser le numéro de build affiché dans /_layouts/15/viewlsts.aspx avec le KB de correctif d'avril 2026. Les organisations utilisant un reverse proxy ou un WAF devant SharePoint ne sont pas à l'abri : la faille exploite la logique applicative interne, pas une exposition réseau directe, ce qui rend les architectures « protégées par périmètre » tout aussi vulnérables tant que le correctif n'est pas appliqué au niveau du serveur lui-même.