Authentification cassée : pourquoi 2026 ressemble à 2010

cPanel, Cisco SD-WAN, Microsoft Exchange : trois vulnérabilités critiques de printemps, trois CVSS au-dessus de 9, trois mécanismes d''authentification cassés exactement de la même manière. Le pattern n''est plus une coïncidence, c''est un aveu collectif d''échec.

Le retour en force d''une catégorie qu''on croyait éteinte

Pendant des années, l''industrie a vendu l''idée que l''authentification était un problème résolu. OAuth, OIDC, SAML, FIDO2, passkeys : on a empilé les standards modernes et on a poussé les équipes produit à les adopter. Sur le papier, le contournement d''authentification appartenait au passé, à la même époque que les buffer overflows visibles sur les diapos de cours de 2008.

Le printemps 2026 vient brutalement nous rappeler que non. Sur six semaines, on a vu trois cas d''école se succéder : injection CRLF dans le mécanisme de session de cPanel (CVE-2026-41940), branche manquante dans la validation des types de pairs Cisco SD-WAN (CVE-2026-20182), et un XSS spoofing sur Exchange (CVE-2026-42897) qui permet de faire passer un attaquant pour un compte légitime. Ce ne sont pas des bugs exotiques. Ce sont des classiques de l''OWASP des années 2010, qu''on n''aurait jamais dû revoir sur des produits cœur d''infrastructure en 2026.

Le vrai problème : la dette d''architecture

Quand on lit attentivement les write-ups de watchTowr sur cPanel ou de Cisco Talos sur le SD-WAN, on comprend que le bug n''est jamais isolé. C''est toujours le symptôme d''une architecture vieillissante qu''on a empilée par couches successives, sans jamais remettre à plat les fondations.

cPanel, c''est un démon écrit en Perl à la fin des années 1990 qui parse manuellement des en-têtes HTTP. Le concept même d''écrire un fichier de session sur disque avant authentification, c''est une décision de design datée. Cisco SD-WAN, c''est un mécanisme de peering hérité de l''acquisition de Viptela en 2017 qu''on a fait évoluer à coups de patchs successifs sans remettre en cause la logique de validation centrale. Exchange, je ne vais même pas commenter, ça fait quinze ans qu''on tire la nappe sur le même code.

Chez chacun de ces éditeurs, je suis prêt à parier que des ingénieurs internes ont remonté ces problèmes plusieurs fois. Mais la dette technique sur des produits qui génèrent des milliards de chiffre d''affaires, ça ne se rembourse pas en un sprint. Ça demande de réécrire des modules entiers, de casser la compatibilité avec des clients en place depuis vingt ans, et de prendre des risques business que personne ne veut assumer.

Le rôle ambigu de la divulgation responsable

Une autre tendance que je trouve inquiétante, c''est l''accélération du time-to-exploit après divulgation. Sur cPanel, le patch sort le 28 avril, le PoC public le 30, et l''exploitation massive trois jours plus tard. Sur Cisco SD-WAN, l''exploitation précède même l''avis officiel. Le modèle classique de coordinated disclosure suppose que les défenseurs ont une fenêtre pour patcher avant que les attaquants ne disposent de l''exploit. Cette fenêtre se réduit drastiquement.

Plusieurs raisons à cela. D''abord, les attaquants ont industrialisé leurs propres processus de threat intelligence : ils suivent les commits GitHub, les changelogs, les bug bounty publics. Ensuite, les outils d''analyse de patchs (binary diff, IDA Pro, Ghidra) sont devenus si performants qu''à partir du moment où un correctif est publié, l''ingénierie inverse vers un exploit prend quelques heures. Enfin, l''économie souterraine prime le délai : un broker d''accès initial qui exploite une CVE n+1 jour fixe ses prix à plusieurs dizaines de milliers d''euros par accès.

Ce qui doit changer côté défenseurs

Sur le terrain, ce que je constate dans mes missions d''audit, c''est qu''il y a un décalage croissant entre la cadence de publication des CVE critiques et la capacité opérationnelle des équipes à patcher. La plupart des organisations que je rencontre tournent encore sur un cycle de patching mensuel, parfois trimestriel pour les équipements réseau de cœur. Ce rythme n''est plus compatible avec la menace.

Trois actions concrètes que je recommande systématiquement aux RSSI que j''accompagne. Premièrement, identifier précisément le sous-ensemble d''actifs critiques pour lesquels un patch doit pouvoir être déployé sous 24 heures, sans réunion CAB ni signature. Cela veut dire pré-autoriser, pré-tester en bac à sable et pré-positionner des fenêtres de maintenance d''urgence dans les contrats avec les métiers. Deuxièmement, monitorer les indicateurs externes : Shodan, Censys, KEV CISA, listes d''IP d''attaquants. Si votre actif apparaît dans le scope d''une campagne en cours, vous devez le savoir en quelques heures, pas en quelques jours. Troisièmement, prévoir des compensations réseau : si vous ne pouvez pas patcher tout de suite, isoler l''actif derrière un WAF, un VPN dédié ou un MFA imposé en amont.

Conclusion

Trois CVE en six semaines, trois éditeurs majeurs, le même type de bug : on a affaire à un problème systémique, pas à une malchance ponctuelle. La cybersécurité opérationnelle ne se résoudra pas en empilant encore des produits EDR, SIEM ou XDR par-dessus des fondations friables. Elle se résoudra en exigeant des éditeurs qu''ils investissent réellement dans leur SDL, et en construisant côté défenseurs une capacité de réaction à 24 heures sur les vecteurs critiques. C''est moins sexy qu''un cycle de keynotes sur l''IA générative, mais c''est ce qui sauve les boîtes en 2026.