CVE-2026-0073 : Bypass d'authentification critique dans ADB-over-TCP d'Android permettant une RCE

🔍 Contexte PubliĂ© le 5 mai 2026 par BARGHEST sur leur blog, cet article constitue une divulgation coordonnĂ©e avec Google d’une vulnĂ©rabilitĂ© critique dĂ©couverte dans le dĂ©mon ADB (adbd) d’Android, identifiĂ©e sous CVE-2026-0073. 🐛 VulnĂ©rabilitĂ© CVE-2026-0073 est un bypass d’authentification dans le chemin d’authentification ADB-over-TCP d’Android, plus prĂ©cisĂ©ment dans la fonction adbd_tls_verify_cert du fichier platform/packages/modules/adb/daemon/auth.cpp. La cause racine est une mauvaise utilisation de l’API EVP_PKEY_cmp de BoringSSL/OpenSSL : L’API retourne 1 (clĂ©s identiques), 0 (mĂȘme type, clĂ©s diffĂ©rentes), -1 (types diffĂ©rents), -2 (opĂ©ration non supportĂ©e) Le code vulnĂ©rable traite toute valeur non nulle comme un succĂšs Un attaquant prĂ©sentant un certificat TLS client avec une clĂ© non-RSA (EC P-256 ou Ed25519) face Ă  une clĂ© stockĂ©e RSA provoque un retour de -1, interprĂ©tĂ© comme une authentification rĂ©ussie if (EVP_PKEY_cmp(known_evp.get(), evp_pkey.get())) { verified = true; // -1 est truthy en C/C++ } ⚙ Conditions d’exploitation Developer options activĂ©es ADB-over-TCP activĂ© (Wireless debugging ou exposition du service adbd) Au moins une clĂ© RSA prĂ©cĂ©demment appairĂ©e dans /data/misc/adb/adb_keys AccessibilitĂ© rĂ©seau au port TCP ADB (typiquement port 5555) 🔗 ChaĂźne d’exploitation L’exploitation nĂ©cessite trois Ă©tapes sĂ©quentielles : ...

8 mai 2026 Â· 3 min

État de la migration post-quantique des protocoles rĂ©seau et sĂ©curitĂ© largement dĂ©ployĂ©s

🔬 Contexte PubliĂ© le 30 mars 2026 sur arXiv (cs.NI), cet article acadĂ©mique de Tushin Mallick, Ashish Kundu et Ramana Kompella constitue une Ă©tude de synthĂšse (survey) sur l’état de prĂ©paration post-quantique des protocoles rĂ©seau et de sĂ©curitĂ© les plus rĂ©pandus. ⚠ Menace identifiĂ©e L’émergence de l’informatique quantique reprĂ©sente une menace structurelle pour les primitives cryptographiques Ă  clĂ© publique classiques, notamment : RSA Cryptographie sur courbes elliptiques (ECC) Ces primitives sont au cƓur des mĂ©canismes d’échange de clĂ©s et d’authentification de la majoritĂ© des protocoles rĂ©seau critiques. ...

5 avril 2026 Â· 2 min

Fuite massive de clĂ©s privĂ©es : 2 622 certificats TLS encore valides selon une Ă©tude Google–GitGuardian

Source : GitGuardian (blog), en collaboration avec Google — rĂ©sultats prĂ©sentĂ©s Ă  Real World Crypto (RWC) 2026 Ă  Taipei. L’étude analyse Ă  l’échelle d’Internet l’impact rĂ©el des fuites de clĂ©s privĂ©es en reliant des clĂ©s exposĂ©es publiquement aux certificats TLS via Certificate Transparency (CT). ‱ PortĂ©e et risque 🔐: Depuis 2021, environ 1 M de clĂ©s privĂ©es uniques ont Ă©tĂ© dĂ©tectĂ©es sur GitHub et DockerHub. En s’appuyant sur l’infrastructure CT de Google, les chercheurs ont associĂ© >40 000 clĂ©s Ă  140 000 certificats TLS. Au septembre 2025, 2 622 certificats restaient valides, dont >900 protĂ©geant des Fortune 500, des Ă©tablissements de santĂ© et des agences gouvernementales. Les fuites de clĂ©s TLS permettent l’usurpation de sites, l’interception/manipulation de donnĂ©es et potentiellement la dĂ©cryption de communications passĂ©es si la PFS n’était pas gĂ©nĂ©ralisĂ©e. ...

11 mars 2026 Â· 3 min

RFC 9849 : Publication du standard TLS Encrypted Client Hello (ECH) par l'IETF

🌐 Contexte PubliĂ© le 3 mars 2026 sur le datatracker de l’IETF (https://datatracker.ietf.org/doc/rfc9849/), ce document constitue la RFC 9849, un standard de la catĂ©gorie Standards Track produit par le groupe de travail TLS de l’IETF. Les auteurs sont Eric Rescorla (Independent), Kazuho Oku (Fastly), Nick Sullivan (Cryptography Consulting LLC) et Christopher A. Wood (Apple). 🔐 Objet du standard La RFC 9849 spĂ©cifie le mĂ©canisme TLS Encrypted Client Hello (ECH), une extension TLS permettant aux clients de chiffrer leur message ClientHello sous la clĂ© publique du serveur. Ce mĂ©canisme protĂšge notamment : ...

4 fĂ©vrier 2026 Â· 2 min

Web PKI réinventé : Google lance les Merkle Tree Certificates pour l'Úre post-quantique

📅 Source : Feisty Duck Cryptography & Security Newsletter, numĂ©ro 135, publiĂ© le 31 mars 2026. 🔐 Contexte gĂ©nĂ©ral Cet article de newsletter spĂ©cialisĂ©e couvre plusieurs dĂ©veloppements majeurs en cryptographie et PKI. Le sujet central est la refonte du Web PKI par Google via les Merkle Tree Certificates (MTCs), en rĂ©ponse aux contraintes imposĂ©es par la cryptographie post-quantique (PQC) et les limites actuelles de Certificate Transparency (CT). 🌳 Merkle Tree Certificates : la refonte du Web PKI Google travaille depuis dĂ©but 2023 sur une nouvelle architecture PKI. Fin 2025, ce travail a Ă©tĂ© transfĂ©rĂ© au groupe de travail IETF PLANTS, en collaboration avec Cloudflare. Les grandes Ă©tapes annoncĂ©es : ...

4 fĂ©vrier 2026 Â· 3 min

Nintendo Switch : contournement de la vérification TLS via SKID dans ImportServerPki (corrigé en 20.2.0)

Source : billet de blog de Yannik Marchand. Contexte : analyse de l’implĂ©mentation TLS du sysmodule « ssl » de la Nintendo Switch (librairie NSS) et dĂ©couverte d’un dĂ©faut de vĂ©rification permettant l’interception de trafic 🔒. RĂ©sumĂ© technique : la vĂ©rification des certificats dans le callback SslAuthCertCb comporte un cas spĂ©cial pour les certificats importĂ©s via nn::ssl::Context::ImportServerPki. Lorsque le certificat reçu figure dans la liste « de confiance » du contexte, la signature n’est pas validĂ©e par NSS. La fonction CertificateStore::IsTrusted ne compare que le Subject Key Identifier (SKID) — une valeur contrĂŽlable par un attaquant — au lieu de vĂ©rifier la chaĂźne et la signature. En forgeant un certificat auto-signĂ© avec le mĂȘme SKID qu’un certificat importĂ©, un attaquant peut rĂ©ussir une attaque de type man-in-the-middle (MITM) et usurper un serveur. ...

31 aoĂ»t 2025 Â· 3 min

Nouvelle attaque 'Opossum' compromet les communications sécurisées

L’article publiĂ© par gbhackers.com le 10 juillet 2025, met en lumiĂšre une nouvelle attaque de type man-in-the-middle nommĂ©e “Opossum”, capable de compromettre les communications sĂ©curisĂ©es. Opossum cible une large gamme de protocoles d’application couramment utilisĂ©s, tels que HTTP, FTP, POP3, SMTP, LMTP et NNTP, qui prennent en charge le TLS “implicite” sur des ports dĂ©diĂ©s et le TLS “opportuniste” via des mĂ©canismes de mise Ă  niveau. En exploitant des diffĂ©rences subtiles d’implĂ©mentation entre ces deux modes, un attaquant peut provoquer une dĂ©synchronisation entre le client et le serveur, compromettant ainsi les garanties d’intĂ©gritĂ© du TLS et manipulant les donnĂ©es vues par le client. ...

10 juillet 2025 Â· 1 min

Faille de sécurité dans le processus de validation de domaine SSL.com

SSL.com pourrait dĂ©livrer un certificat TLS de confiance pour le nom de domaine d’une adresse e-mail du demandeur, mĂȘme si ce dernier n’a pas Ă©tabli le contrĂŽle administratif de ce domaine.

20 avril 2025 Â· 1 min
Derniùre mise à jour le: 19 mai 2026 📝