SharePoint : 4 CVE ajoutées au KEV en 3 semaines — chaîne RCE non authentifiée

Entre le 1er et le 22 juillet 2026, la CISA a ajouté quatre vulnérabilités Microsoft SharePoint à son catalogue Known Exploited Vulnerabilities. Quatre KEV sur un même produit en trois semaines, avec des délais de remédiation imposés de trois jours, ce n'est pas une coïncidence statistique : c'est la signature d'une campagne d'exploitation active contre les déploiements SharePoint on-premises.

Le détail le plus instructif du lot n'est pas la CVE à 9.8 — c'est celle à 5.3. Sa présence au KEV illustre exactement pourquoi le score CVSS ne doit jamais servir seul de critère de priorisation.

Les 4 CVE

Les trois premières ont été publiées le même jour (14 juillet 2026), ce qui correspond à un lot Patch Tuesday. Les ajouts au KEV se sont ensuite étalés sur trois semaines, au rythme des exploitations constatées.

Détails techniques

Les deux désérialisations (CVE-2026-50522 et CVE-2026-58644)

Microsoft reste, comme à son habitude, extrêmement laconique. Le libellé NVD est identique pour les deux :

Deserialization of untrusted data in Microsoft Office SharePoint allows an unauthorized attacker to execute code over a network.

Vecteur pour les deux : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — réseau, complexité faible, aucune authentification, aucune interaction utilisateur, impact maximal sur les trois axes.

Microsoft n'a pas publié le mécanisme précis, mais la classe de vulnérabilité est bien connue sur la pile SharePoint. SharePoint est une application ASP.NET, et les désérialisations exploitables y proviennent classiquement de :

• __VIEWSTATE — si les clés machine (validationKey / decryptionKey) sont connues ou si la validation MAC est contournée, un attaquant forge un ViewState contenant une gadget chain .NET et obtient l'exécution de code dans le worker IIS
• BinaryFormatter / LosFormatter / ObjectStateFormatter appelés sur des données contrôlées par le client
• Les endpoints de web services SharePoint qui acceptent des payloads XML/SOAP désérialisés

Le résultat est une exécution de code dans le contexte du pool d'applications IIS — souvent un compte de service de domaine avec des droits étendus.

La CVE à 5.3 qui compte plus que son score (CVE-2026-56164)

Missing authentication for critical function in Microsoft Office SharePoint allows an unauthorized attacker to elevate privileges over a network.

Vecteur : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N → aucun impact confidentialité, impact intégrité faible, aucun impact disponibilité. D'où le 5.3.

Prise isolément, cette CVE ne permet effectivement pas grand-chose. Chaînée, elle change tout : elle fournit précisément le maillon d'accès non authentifié dont une désérialisation a besoin quand celle-ci exige normalement une session valide. C'est le schéma d'attaque classique sur SharePoint — un bypass d'authentification à faible score suivi d'une désérialisation à fort impact.

C'est aussi pour cela qu'elle a été la première ajoutée au KEV (14 juillet) : les défenseurs l'ont vue utilisée en amont des chaînes observées.

CVE-2026-45659

Ajoutée dès le 1er juillet. Le libellé KEV précise « allows an authorized attacker to execute code over a network » — donc une authentification est requise. Les données NVD (score, vecteur, versions) ne sont pas exposées au moment de la rédaction. À traiter avec le même sérieux que les autres : un compte SharePoint standard est trivial à obtenir dans une organisation de taille moyenne.

Produits et versions affectés

Les données NVD référencent, pour les trois CVE documentées :

⚠️ Ces valeurs sont les bornes de version telles qu'exposées par NVD, pas nécessairement le numéro du correctif à installer. Réfère-toi au bulletin Microsoft pour la KB exacte correspondant à ta version et ta branche.

SharePoint Online (Microsoft 365) n'est pas concerné — Microsoft applique les correctifs côté service. Ce sont les déploiements on-premises (SharePoint Server 2016, 2019, Subscription Edition) qui portent le risque.

Exploitation et impact

Pourquoi SharePoint est une cible de choix

SharePoint on-premises concentre trois propriétés qui en font une cible privilégiée :

1. Exposition Internet fréquente — les portails extranet, espaces partenaires et intranets accessibles en télétravail sont souvent publiés directement
2. Contenu à haute valeur — contrats, données RH, propriété intellectuelle, plans stratégiques
3. Intégration Active Directory profonde — le pool applicatif tourne souvent sous un compte de service de domaine, parfois surprivilégié

Chaîne d'attaque type

1. Reconnaissance : identification d'une instance SharePoint on-prem exposée
2. Bypass d'authentification via CVE-2026-56164 pour atteindre un endpoint normalement protégé
3. Désérialisation (CVE-2026-50522 ou CVE-2026-58644) → exécution de code dans le worker IIS
4. Vol des clés machine (web.config) — permet ensuite de forger des ViewState valides à volonté, donc une persistance qui survit au patch
5. Extraction des credentials du compte de service, puis pivot vers Active Directory
6. Déploiement de webshells dans les répertoires _layouts pour un accès durable

Le point 4 est celui que les équipes oublient systématiquement : patcher ne suffit pas si les clés machine ont fui. Il faut les faire tourner.

Détection et IOC

Journaux IIS

Cherche les POST vers les endpoints historiquement visés sur SharePoint :

# Sur le serveur SharePoint (PowerShell)
Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC*\*.log" `
  -Pattern "ToolPane|_layouts/15/.*\.aspx.*POST|__VIEWSTATE" |
  Select-Object -Last 100

Signaux à corréler :

• Requêtes POST avec __VIEWSTATE anormalement volumineux
• Codes 200 sur des endpoints _layouts depuis des IP externes non attendues
• Referer absent ou forgé sur des requêtes d'administration

Fichiers déposés

# Fichiers .aspx récents dans les répertoires SharePoint
Get-ChildItem "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS" `
  -Recurse -Include *.aspx |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-45) }

Tout .aspx apparu récemment sans opération de maintenance correspondante est à considérer comme un webshell.

Processus enfants suspects

Le worker IIS (w3wp.exe) ne devrait jamais lancer de shell :

Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 500 |
  Where-Object { $_.Message -match "ParentImage:.*w3wp\.exe" -and
                 $_.Message -match "cmd\.exe|powershell\.exe" }

C'est le signal le plus fiable d'une exploitation réussie.

Mitigation et patch

1. Appliquer les correctifs Microsoft

Les quatre CVE sont corrigées par les mises à jour de sécurité de juillet 2026. Sur chaque serveur de la ferme :

Install-WindowsUpdate -Category SecurityUpdates -AcceptAll

Puis exécute l'assistant de configuration produits SharePoint (psconfig) sur chaque serveur de la ferme, dans l'ordre — une mise à jour SharePoint non finalisée par psconfig laisse la ferme dans un état incohérent.

2. Faire tourner les clés machine (indispensable)

Si ta ferme a été exposée pendant la fenêtre d'exploitation, considère les clés machine comme compromises :

Update-SPMachineKey -WebApplication "https://sharepoint.exemple.com"
Restart-Service W3SVC

Sans cette étape, un attaquant ayant déjà exfiltré les clés conserve la capacité de forger des ViewState valides après le patch.

3. Réduire la surface d'exposition

• Retire l'accès Internet direct au portail on-prem : place-le derrière un reverse proxy authentifiant, un VPN, ou Entra ID Application Proxy
• Restreins les privilèges du compte de service du pool applicatif au strict nécessaire
• Active AMSI pour SharePoint si ta version le supporte

4. Chasse rétroactive

Les échéances CISA (3 jours) indiquent une exploitation active depuis début juillet. Si ton patch est postérieur au 20 juillet, mène une chasse : webshells, comptes de ferme créés, tâches planifiées, connexions sortantes inhabituelles depuis les serveurs SharePoint.

Pourquoi surveiller en continu votre parc Microsoft

Cet épisode illustre deux angles morts classiques. D'abord, le CVSS seul ne priorise pas correctement : la CVE à 5.3 était la plus urgente à traiter puisqu'elle ouvrait la chaîne. Ensuite, l'ajout au KEV arrive après la publication du patch — ici jusqu'à trois semaines après. Une organisation qui ne suit que les scores, ou qui attend l'alerte CISA, patche systématiquement trop tard.

Avec cveo.tech, inventorie tes serveurs SharePoint, Exchange et Windows et reçois une alerte automatique dès qu'une CVE touche une de tes versions exactes — avec le statut KEV mis en évidence, pour prioriser sur l'exploitation réelle plutôt que sur le seul score.