Cloudflare spune că cheile private pentru opt certificate intermediare eMudhra au fost compromise, ceea ce permite unui atacator să falsifice certificate pentru orice domeniu. Browserele au fost actualizate repede. Munca rămasă e pe servere, în containere și în trust store-urile incluse în aplicații.
Pe 19 octombrie 2026, în jurul orei 17:00 UTC, Cloudflare a aflat că cheile private pentru opt certificate intermediare eMudhra au fost compromise. Relatarea Cloudflare, publicată pe 20 octombrie, este singura sursă pentru tot ce urmează, iar detaliile de mai jos sunt afirmațiile ei.
Certificatele erau larg acceptate de browsere, de sistemele de operare și chiar în interiorul Cloudflare. Cloudflare spune că cheile sunt slabe, deci un atacator poate crea un certificat falsificat pentru orice domeniu și îl poate folosi ca să se dea drept serverul real, apoi să intercepteze sau să modifice traficul. Cloudflare numește incidentul grav, cu implicații în tot Internetul. Analiza ei de securitate nu a găsit exploatare activă pe serviciile Cloudflare. Afirmația privește infrastructura Cloudflare, nu pe a voastră.
Care e problema și care nu e
Cloudflare subliniază că este vorba despre autentificarea pe bază de certificate, nu despre o slăbiciune a algoritmilor de criptare din TLS. Traficul poate fi în continuare criptat. Riscul este să-l criptați către partea greșită.
Distincția contează la triaj. Orice client care decide în cine are încredere consultând o listă de autorități de certificare este expus până când lista nu mai acordă încredere celor opt certificate intermediare.
De ce remedierea nu e uniformă
Cloudflare spune că dezvoltatorii de browsere au putut remedia problema „dintr-o simplă apăsare de buton”, pentru că majoritatea browserelor folosesc mecanisme de revocare rapidă, precum Chrome CRLSets. În plus, au de actualizat o singură aplicație, nu sute.
La voi e invers. Verificarea certificatelor poate sta într-o bibliotecă HTTP, într-un runtime, în sistemul de operare, într-o imagine de bază sau într-o configurație proprie de trust store. Ghidul Cloudflare pentru dezvoltatori e direct: uitați-vă sub SDK. Dacă actualizați doar SDK-ul, politica de verificare de dedesubt poate rămâne neschimbată.
Un test reușit în browser nu dovedește că un serviciu din fundal este protejat.
Asta e remarca Cloudflare și ar trebui să vă ghideze la verificare. Nici un test cu curl nu dovedește protecția, dacă aplicația folosește alt verificator. Testați pe calea pe care aplicația o folosește de fapt.
Ce a făcut Cloudflare și ce cere clienților
Cloudflare spune că a tratat întâi serviciile care folosesc certificate publice pentru a autentifica endpoint-uri la distanță, precum proxy-urile care se conectează la origini și aplicațiile care apelează API-uri externe. A actualizat trust store-urile comune și imaginile de bază și a însoțit asta de reîncărcări, reporniri și deploy-uri de imagini. Aplicațiile cu trust store-uri incluse sau personalizate au fost evaluate separat.
Pentru clienți, Cloudflare enumeră aceste acțiuni:
- Cloudflare One Client și aplicația 1.1.1.1: treceți la versiunile corectate pe care le indică pentru fiecare platformă.
- Cloudflare Tunnel (cloudflared): treceți la versiunea 2026.10.2, iar pentru containere actualizați imaginea corectată și faceți deploy din nou.
- Autentificarea TLS a clientului configurată de client: verificați trust store-ul de mutual TLS și orice autorități de certificare încărcate de voi pentru verificarea certificatelor clientului.
- Certificate de origine personalizate: verificați-le, împreună cu configurația serverului, dacă folosiți modul de criptare Full (strict) sau Strict.
- Cloudflare Containers, inclusiv Sandboxes: verificați imaginile și dependențele pentru trust store-uri afectate.
Cloudflare spune că actualizează Automatic SSL/TLS ca să anunțe clienții care încă folosesc certificatele retrase din încredere, pentru că acestea ar duce la erori de conexiune. Mai spune că clienții Zero Trust cu Gateway și cu un client la zi sunt protejați automat.
Unde e tentația de a greși
După actualizare, e posibil să vedeți erori de certificat în dashboard-uri. Cloudflare avertizează că nu trebuie rezolvate prin dezactivarea verificării, pentru că așa eliminați chiar protecția pe care actualizările o readuc.
Cloudflare trimite la o listă de pachete des folosite și deja corectate, adunată colaborativ de Dennis Jackson de la Mozilla, plus un site de test cu verificări în browser, instrucțiuni de testare în afara browserului și informații despre actualizarea pachetelor. Multe dintre pachetele afectate vor fi dependențe indirecte, așa că citiți arborele de dependențe, reconstruiți imaginile și stabiliți dacă fiecare aplicație cere reîncărcare, repornire sau deploy din nou.
Cronologie
Cronologia Cloudflare, toate orele în UTC: aflarea problemei în jurul orei 17:00 pe 19 octombrie; actualizările pentru client și WARP publicate la 02:00 pe 20 octombrie; actualizarea cloudflared la 09:15; măsurile pentru CDN și Zero Trust pe partea de server, implementate complet la 19:20. Cloudflare spune că remedierea continuă.
Lecția de fond
Cloudflare susține că un trust store nu poate fi o listă statică de autorități de certificare rădăcină. Trebuie actualizat rapid cu informații de revocare și chei de certificate transparency. Citează proiectul upki ca un efort în această direcție. Cloudflare notează că majoritatea browserelor folosesc mecanisme de revocare rapidă, precum Chrome CRLSets.
Ce înseamnă pentru planurile voastre
Astăzi, faceți inventarul tuturor locurilor în care sistemele voastre verifică certificate publice: servicii care apelează API-uri externe, proxy-uri, containere cu trust store-uri incluse și configurații de mutual TLS. Actualizați de la arborele de dependențe în jos, nu doar SDK-ul, reconstruiți imaginile, faceți deploy din nou și testați pe calea TLS reală a fiecărei aplicații. Nu ascundeți erorile noi de certificat dezactivând verificarea. Apoi întrebați-vă dacă trust store-urile voastre pot primi o actualizare de revocare în câteva ore, nu la următorul release.
Surse
- blog.cloudflare.com 8 eMudhra certificates are compromised. Here's what you need to know · 20 octombrie 2026
Briefing documentat și scris de sistemul editorial SKYLOGIQ: un model AI care scrie și un model AI care verifică faptele, cu o coadă de verificare umană pentru tot ce refuză editorul. Sursele sunt listate mai sus. Cum se face Briefing-ul
Versiunea în română e adaptată automat după originalul în engleză și verificată de un al doilea model AI. Originalul în engleză