Quatre CVE en cinq jours, toutes du même type, toutes en CVSS 9+ : F5 BIG-IP APM, GitHub Enterprise, MOVEit Automation, cPanel/WHM. Le contournement d'authentification est en train de devenir la signature dominante des grandes vulnérabilités de 2026. Et personne ne semble s'en émouvoir.

Le pattern qui se répète

Sur les 30 derniers jours, mes flux d'alerte affichent un schéma quasi-identique sur quatre éditeurs sans rapport entre eux. F5 publie le 29 mars un avis sur CVE-2025-53521, contournement d'authentification non-authentifié sur BIG-IP APM, déjà ajouté au KEV de CISA. GitHub corrige début mai CVE-2026-3854, RCE via git push avec une chaîne qui inclut un bypass d'authentification (CVSS 8.7). Progress publie CVE-2026-4670 le 4 mai sur MOVEit Automation, encore un auth bypass non-authentifié, encore CVSS 9.8. Et cPanel patche fin avril CVE-2026-41940, exploité depuis des mois en zero-day, toujours un contournement de l'authentification primaire.

Quatre produits, quatre éditeurs, quatre architectures totalement différentes. Mais une seule classe de bug : CWE-287 (Improper Authentication) et ses cousines CWE-305, CWE-306, CWE-294. Quand un même type de vulnérabilité émerge en parallèle sur des produits qui n'ont rien en commun, ce n'est pas une coïncidence statistique. C'est qu'un mode d'analyse a basculé. Ou que les défenses se sont déplacées vers d'autres surfaces, laissant ce vecteur peu surveillé.

Pourquoi maintenant

Trois facteurs convergent pour expliquer ce retour fracassant de l'auth bypass en 2026. Le premier est l'émergence d'outils d'analyse statique dopés à l'IA capables de modéliser les flux de contrôle d'authentification dans des codebases massives. Là où un chercheur humain mettait des semaines à comprendre la logique d'auth d'un produit type cPanel, un modèle entraîné sur des milliers de patterns d'authentification peut désormais ingérer le code et pointer les écarts en heures. Les laboratoires offensifs (Airbus SecLab, GreyNoise, Watchtowr, Censys) investissent massivement dans ces outils depuis 2025.

Le deuxième facteur est l'épuisement progressif des autres surfaces d'attaque. Les bugs mémoire dans les langages mainstream se font rares à mesure que Rust, Go et les enforcement de Memory Safety en C/C++ moderne s'installent. Les SQLi sont devenues anecdotiques en dehors de produits legacy. Les XSS persistantes critiques sont rares sur les frameworks modernes. Que reste-t-il ? La logique métier. Et le sommet de la logique métier, dans tout produit administrable, c'est le flow d'authentification.

Le troisième facteur est plus structurel : les éditeurs ont accumulé pendant 15 ans des chemins d'authentification multiples. Une URL pour les API, une autre pour le webhook, une troisième pour la console admin, une quatrième pour le legacy SOAP, encore une pour les agents internes. Chaque chemin a sa propre logique d'auth, ses propres exceptions, ses propres "modes spéciaux pour le support". Cette dette d'authentification ne se voit pas dans un audit fonctionnel — mais elle saute aux yeux d'un modèle qui mappe les graphes de contrôle.

Ce que ça change pour les défenseurs

L'auth bypass est la pire classe de vulnérabilité du point de vue défensif, et c'est précisément pourquoi son retour devrait inquiéter. Une RCE classique laisse une trace : payload exotique, comportement processus inhabituel, sortie réseau anormale. Un auth bypass, lui, produit un trafic strictement identique à un trafic légitime. L'attaquant se présente, est authentifié à tort, et navigue ensuite avec les mêmes patterns que n'importe quel administrateur. Aucune signature comportementale ne se déclenche.

Conséquence directe : la défense en profondeur traditionnelle (WAF, EDR, NDR) est largement aveugle à ce vecteur. Le WAF voit un POST sur /login qui réussit. L'EDR voit un processus qui exécute des commandes admin légitimes — c'est son rôle. Le NDR voit du trafic API administratif normal. Seules deux choses peuvent capter une exploitation : une corrélation comportementale fine au niveau identité (UEBA, type ce compte se connecte rarement, jamais à 3h du matin, jamais depuis cette IP) et une analyse des graphes d'accès aux ressources sensibles.

Or, ces deux capacités sont précisément celles que les RSSI ont le moins déployées en 2024-2025. La majorité des budgets sécurité sont allés vers le SOAR, l'automatisation des SOC, l'XDR — qui sont utiles, mais qui ne couvrent pas le scénario d'un acteur qui se présente avec une session valide.

Le vrai problème : la confiance par défaut

Au-delà du diagnostic technique, l'auth bypass révèle un biais culturel profond : on accorde encore une confiance binaire à l'authentification. Une fois le client authentifié, on lui donne accès à tout ce que son rôle permet. Ce modèle, hérité des architectures monolithiques des années 2000, ne tient plus dans un monde où les CVE d'auth bypass se compteront par dizaines en 2026.

Le zero trust en parle depuis dix ans, et pourtant l'implémentation reste majoritairement périmétrique chez les acteurs français. Combien d'organisations vérifient à chaque action sensible (export de données, création de compte, modification de configuration) que l'identité est cohérente avec son comportement habituel et le contexte ? Une poignée. La plupart se contentent d'authentifier en entrée et de faire confiance ensuite. C'est précisément ce que les auth bypass exploitent.

Mon avis d'expert

Le retour de l'auth bypass en 2026 n'est pas un accident. C'est le signe que l'IA offensive bascule plus vite que l'IA défensive. Les laboratoires qui scannent du code source avec des modèles entraînés trouvent ces failles plus rapidement que les éditeurs ne peuvent les corriger ou les défenseurs ne peuvent les détecter. Pour les RSSI, l'urgence n'est plus de patcher plus vite — la fenêtre est trop courte. C'est de réduire drastiquement la surface d'authentification exposée à Internet, et de bâtir une couche de détection comportementale post-authentification. Sinon, on continuera à découvrir les compromissions trois à six mois après, dans les data leak sites des opérateurs ransomware.

Ce qu'il faut faire dès maintenant

Trois chantiers d'urgence pour les six prochains mois. Premier : recenser tous les services d'administration exposés sur Internet — WHM, MOVEit, BIG-IP, GitHub Enterprise, équivalents — et les passer derrière un VPN d'entreprise ou un broker d'identité (ZTNA). La règle doit devenir : aucune console d'administration accessible depuis Internet sans tunnel d'identité préalable. Cette mesure seule neutralise 80 % des CVE d'auth bypass connues, sans dépendre du patch.

Deuxième : mettre en place une UEBA sur les comptes administrateurs des produits sensibles. Pas une UEBA générique pour les utilisateurs métier — une UEBA dédiée aux 50 ou 100 comptes qui ont des privilèges critiques. Quand un de ces comptes se connecte à 3h du matin depuis une IP qu'il n'a jamais utilisée, l'alerte doit être bloquante, pas informative.

Troisième : exiger des éditeurs critiques (banking, MFT, hébergement) une cartographie des chemins d'authentification et un test pentest annuel ciblé sur l'auth bypass. Ce n'est pas un caprice de RSSI. C'est devenu un prérequis pour signer un contrat. Les éditeurs qui ne sauront pas répondre à cette demande dans les 12 mois perdront des marchés, et c'est tant mieux.

Conclusion

L'auth bypass est en train de redevenir la classe de vulnérabilité dominante dans le top 10 des incidents critiques de 2026, après avoir été reléguée au second plan pendant une décennie. Cette inversion est structurelle, pas conjoncturelle. Elle exige une révision profonde des architectures d'exposition et des dispositifs de détection. Les organisations qui prendront ce virage vite éviteront le sort de leurs concurrents qui découvriront leur compromission six mois après dans la presse spécialisée.

Besoin d'un regard expert sur votre exposition d'authentification ?

Discutons concrètement de votre périmètre d'admin exposé et de la pertinence de votre dispositif de détection post-authentification.

Prendre contact