LongLogon · CVE-2026-41089

LongLogon est un vérificateur de préconditions non authentifié et non destructif pour CVE-2026-41089, un débordement de tampon sur la pile avant authentification dans le service Windows Netlogon. Sans identifiants et sans envoyer le débordement, il indique si le nom de domaine DNS d'un contrôleur de domaine est suffisamment long pour que le bogue le fasse planter.

Le PoC public pour CVE-2026-41089 fonctionne-t-il vraiment ?

Sur un contrôleur de domaine nommé normalement, non. Les PoC d'exploit publics pour cette CVE (le plus étoilé, et les copies qui ont suivi) prétendent faire planter un contrôleur de domaine en envoyant un nom d'utilisateur long. Ils ne font pas planter un DC non patché sur un domaine ordinaire, pour deux raisons confirmées en différenciant le netlogon.dll pré- et post-patch et en reproduisant le crash en laboratoire :

1. Mauvais NtVer. Ils pingent avec le bit V5EX activé (0x16), ce qui achemine vers BuildSamLogonResponseEx sécurisé aux limites. L'ancienne BuildSamLogonResponse vulnérable n'est atteinte qu'avec ce bit désactivé. LongLogon utilise 0x02.
2. Un nom d'utilisateur long ne peut pas déborder tout seul. Le champ User contrôlé par l'attaquant est limité à 130 caractères larges par le binaire, bien en deçà du tampon de 528 octets. Les octets qui transportent l'écriture sur le cookie de pile sont les propres noms DNS longs du serveur, que la longueur de la charge utile ne modifie pas.

Ainsi, l'exploit populaire échoue sur un domaine ordinaire, et un délai d'attente recv (qu'un seul paquet UDP perdu provoque sur un DC sain) est mal interprété comme un crash. LongLogon n'est pas l'un de ces exploits : c'est l'analyse corrigée et vérifiée par binaire, livrée en tant que vérificateur non destructif qui n'envoie jamais le débordement. Le seuil de crash confirmé en laboratoire et le mécanisme complet sont ci-dessous.

Ce qu'est CVE-2026-41089

Un débordement de tampon sur la pile (CWE-121, CVSS 9.8) dans le chemin de localisation du contrôleur de domaine Netlogon NlGetLocalPingResponse → BuildSamLogonResponse → NetpLogonPutUnicodeString. En répondant à un ping CLDAP ou MAILSLOT, le DC sérialise ses propres noms de forêt, domaine et hôte plus une petite chaîne contrôlée par l'attaquant dans un tampon de pile fixe de 528 octets (ushort local_258[264]), avec le cookie de pile immédiatement après. Lorsque les propres noms DNS du serveur sont suffisamment longs, l'écriture cumulative atteint la fin du tampon, le terminateur final L'\0' dépasse le cookie, __report_gsfailure se déclenche, et lsass.exe meurt avec STATUS_STACK_BUFFER_OVERRUN (0xc0000409). Le contrôleur de domaine redémarre. Non authentifié, un seul paquet UDP.

Là où Zerologon (CVE-2020-1472) abusait d'un défi complètement zéro, LongLogon abuse d'un nom de domaine pathologiquement long.

Ce que cet outil vérifie, et ce qu'il ne fait pas

longlogon.py est non destructif. Il envoie des pings CLDAP bénins avec un champ User minimal, mesure la réponse du constructeur hérité, et indique si la précondition de débordement est remplie : si le domaine de ce DC est suffisamment long pour qu'un DC non patché plante.

Il ne fait pas :

• envoyer le débordement ou faire planter quoi que ce soit, et
• déterminer l'état du patch. Un DC patché emprunte le même chemin de code et refuse l'écriture trop longue, donc vous ne pouvez pas distinguer un DC patché d'un non patché sur le réseau avec un nom de domaine normal.

Savoir lesquels de vos DC sont réellement patchés nécessite une vérification de version avec privilèges (admin) sur l'ensemble du parc. C'est le genre de chose qu'ADscan automatise lors d'un engagement (voir ci-dessous).

Pourquoi presque tous les DC réels sont sûrs

Les seuls octets contrôlés par l'attaquant qui atteignent le tampon proviennent du filtre User CLDAP, limité à 130 caractères larges, bien en deçà du tampon de 528 octets à eux seuls. Les octets qui amènent le curseur sur le cookie sont les propres noms du serveur, que l'attaquant ne contrôle pas. Un DC nommé par défaut (corp.local) ne peut pas être planté. C'est pourquoi Microsoft l'évalue comme « Exploitation moins probable ». En laboratoire, la longueur minimale du nom de domaine DNS pour faire planter Windows Server 2016 (avec un nom d'hôte de 7 caractères) était de 98 caractères.

Utilisation

Avec uv, aucune configuration préalable. Les dépendances sont déclarées en ligne (PEP 723), donc cela installe automatiquement rich dans un environnement éphémère :

uv run longlogon.py <ip-du-dc> <domaine-dns-du-dc>

Ou avec pip :

pip install rich
python3 longlogon.py <ip-du-dc> <domaine-dns-du-dc>

Le domaine DNS doit correspondre à celui servi par le DC. Il n'est pas secret : rootDSE, DNS inversé et CLDAP lui-même le révèlent. La sortie est un verdict de précondition plus le calcul de remplissage du tampon par champ.

Le routage NtVer est important. L'ancienne BuildSamLogonResponse vulnérable n'est atteinte que lorsque (NtVer & 0xc) == 0 et (NtVer & 0x2) != 0. Les tentatives d'exploit publiques qui envoient NtVer=0x16 ou 0x06 activent le bit 2 (0x4) et frappent BuildSamLogonResponseEx sécurisé aux limites, donc elles ne déclenchent jamais le bogue. LongLogon utilise 0x02.

Versions affectées

Contrôleurs de domaine Windows Server non patchés, de 2012 R2 à 2025. Premières versions patchées :

Utilisation responsable

Uniquement pour la recherche en sécurité autorisée et la validation défensive. Ce dépôt livre le vérificateur de préconditions non destructif, pas un crasheur militarisé, pour une CVE activement exploitée et wormable. Patchez vos contrôleurs de domaine.

Aller plus loin

• Article de recherche complet : comment le bogue a été localisé par diffing de patch, la mécanique exacte du tampon, et pourquoi les PoC publics ne fonctionnent pas. https://adscanpro.com/blog/patch-diffing-cve-2026-41089-netlogon
• ADscan LITE (gratuit, open source) : pentest Active Directory depuis un terminal. Énumération, collecte BloodHound, Kerberoasting, ADCS, chemins d'attaque, preuves. https://github.com/ADScanPro/adscan
• ADscan PRO : la même automatisation de kill-chain pour les équipes réalisant des engagements AD. https://adscanpro.com/pro

_{Recherche par Yeray Martín Domínguez · ADscan · CVE-2026-41089 · Netlogon · Active Directory · contrôleur de domaine · débordement de tampon sur la pile · CLDAP · non authentifié · pré-authentification · preuve de concept}