Pe 19 octombrie 2026, Cloudflare a aflat că eMudhra, o autoritate de certificare publică, folosise chei intermediare atât de slabe încât oricine le putea recupera din certificatele publice. Una dintre chei era, literal, numărul 4. Cifra nu e o metaforă: în loc de un număr de 115 cifre, scriptul a ales 4. Celelalte șapte chei erau la fel de previzibile: 56, 66, 115, 155, 156, 230 și 237. Consecința e simplă de formulat și greu de digerat: oricine putea emite certificate frauduloase pentru orice domeniu, acceptate de orice client nepatchuit care nu impune Certificate Transparency.

Ce s-a întâmplat concret, fără înflorituri

Spre deosebire de incidentele DigiNotar, TÜRKTRUST sau TrustWave, unde cheile compromise ajungeau la un număr limitat de atacatori, aici accesul e nelimitat și instantaneu. Nu ai nevoie de o breșă, de o scurgere, de un insider. Extragi cheia din certificatul public, exact cum ai citi un număr de serie. Cloudflare documentează totul în analiza sa publicată pe blog, pe 30 octombrie 2026, sursa aici.

eMudhra a anunțat că iese din businessul de CA public și a invocat o eroare în scriptul de generare a cheilor, dar nu a publicat scriptul. Mai mult: a semnat o listă de revocare (CRL) cu ce pare a fi o cheie corect generată, apoi a corectat-o folosind cheia slabă. Întrebarea pe care o pune Cloudflare, și pe care orice operator de infrastructură ar trebui să o pună, este una singură: de ce nu a sărit niciun alarmist, niciun auditor, niciun cross-signer? Aici nu vorbim despre un bug de aplicație. Vorbim despre lanțul de încredere al internetului.

Cât de repede s-a mișcat Cloudflare și ce a găsit

Cloudflare a început patch-ul pe 19 octombrie, în aceeași zi. Proxy-urile care folosesc Pingora, responsabile pentru majoritatea conexiunilor de ieșire, au respins cheile vulnerabile în câteva ore. În paralel, a rulat o analiză asistată de AI pe codul sursă pentru a găsi toate sistemele care au încredere în aceste chei. În patru ore aveau inventarul complet, apoi ticket-uri per sistem pentru confirmare și remediere.

Ca să vadă dacă cineva încearcă exploatarea, au adăugat logging în Pingora, cu roll-out finalizat pe 21 octombrie. După o săptămână: aproximativ 22.000 de handshake-uri încercate cu cheile slabe. Două treimi erau accesări ale unor site-uri de test, precum emudhra.we-have-a-problem.com. Aproape toate celelalte vizau origin-uri care își creaseră propriul certificat cu intermediarul slab. Toate au fost refuzate, pentru că sistemul era deja patchuit.

Aproximativ 160 de handshake-uri au ieșit în evidență. Certificatele aveau în Subject Alternative Name domenii ale altor organizații, inclusiv dispozitive IoT de consum, diferite de SNI-ul cerut. Unele fuseseră emise după scurgere și erau valide peste doi ani, peste limita oricărei CA publice. Cloudflare spune clar: semnalele arată ca certificatele implicite ale serverelor respective, nu ca o interceptare țintită. Ar fi picat oricum la verificarea hostname-ului. Însă un lucru rămâne cert: un certificat fals văzut avea dată de 20 octombrie, ora 18:19 UTC, la mai puțin de o oră după ce raportul Mozilla devenea public. Cheile au fost folosite pentru falsificare în primele ore.

Asta nu exclude o interceptare țintită, bine ascunsă. Cloudflare o spune direct: pentru asta trebuie să te uiți la semnalele indirecte de compromitere a sistemelor, iar până acum nu au apărut astfel de semnale.

Cine mai e vulnerabil: problema nu e la servere, e la vizitatori

Aici devine interesant pentru cineva care nu lucrează la Cloudflare. Compania nu poate testa direct dacă un vizitator are încă încredere în cheile slabe fără să-i rupă conexiunea. Așa că a folosit paginile de challenge: a trimis două probe, una către un endpoint cu certificat semnat eMudhra și una de control cu certificat normal, pe o fracțiune din paginile servite. Rezultatul vine din 50 de milioane de probe într-o săptămână.

Concluziile, cu avertismentul că traficul pe challenge pages e puternic distorsionat de boți neconfirmați:

Un detaliu care merită atenția oricui lucrează cu date: pe 29 octombrie, în jurul orei 18:00 UTC, Cloudflare a prins un val mare de trafic bot care se dădea drept Chrome 150-154 pe macOS. Graficul arată ca patch-ing, dar e doar o schimbare de clasificare. Aceleași user-agent-uri au crescut în acceptare în graficul de trafic bot. Singura excepție notabilă: Chrome 150-154 pe Linux, unde acceptarea scade constant, ceea ce e consistent cu patch-ing real în acel grup. Cloudflare e onest: dovezile sunt sugestive, nu concludente.

De ce te privește, chiar dacă nu ai un CA în ogradă

Sunt trei lecții pe care le poți aplica fără să fii Cloudflare.

Prima: încrederea în certificate nu e un detaliu de infrastructură, e o decizie de business. Ai un magazin online, procesezi plăți, colectezi date de clienți. Dacă un client al tău (browser, aplicație mobilă, integrator B2B) nu impune Certificate Transparency, un certificat fals e plauzibil. Iar dacă acel client e un dispozitiv IoT vechi, o aplicație de depozit, un terminal de plată, problema nu se rezolvă cu un update de browser. Se rezolvă cu inventarul activelor.

A doua: revocarea e prea lentă ca mecanism de apărare. Cloudflare spune explicit că are nevoie de un mecanism de revocare rapidă în mai multe produse și că proiecte precum upki sunt direcția corectă, pentru că un trust store nu poate fi o listă statică de CA-uri. Dacă în stack-ul tău revocarea durează zile, ai o fereastră de expunere pe care nu o vezi până nu se întâmplă.

A treia: auditul și cross-signing-ul nu sunt garanții. eMudhra a trecut prin procese care ar fi trebuit să prindă o cheie generată ca „4”. Nu au prins. Când un furnizor îți spune „suntem auditați”, întrebarea corectă nu e „de cine”, ci „ce anume verifică auditul și ce nu”.

Ce înseamnă pentru tine, antreprenor sau marketer în România

Hai să traducem în limbaj de zi cu zi. Nu ai nevoie de un laborator de criptografie ca să fii expus. Ai nevoie de un site, de un checkout, de un CRM, de integrări cu platforme care comunică prin TLS.

Ce faci concret, în ordinea priorităților:

  1. Inventariază toate sistemele care fac conexiuni de ieșire și au un trust store propriu: servere, containere, integrări custom, scripturi de sync cu ERP sau curier, terminale din depozit.
  2. Verifică dacă stack-ul tău impune Certificate Transparency și dacă are revocare rapidă. Dacă răspunsul e „nu știu”, e un răspuns greșit.
  3. Nu presupune că „am site pe platformă mare, deci sunt acoperit”. Acoperit e platforma, nu neapărat integrările tale laterale.
  4. Nu trage concluzii din grafice de trafic. Diferența dintre patch-ing real și schimbare de clasificare a botului, exact ce arată Cloudflare pe 29 octombrie, e genul de capcană care te face să crezi că ai rezolvat ceva ce n-ai rezolvat.

Aici e și locul unde se leagă discuția despre date. Dacă nu ai un inventar curat al sistemelor care comunică, nu poți răspunde la întrebarea „sunt expus?”. Despre asta scriam și în analiza pe reconcilierea datelor de plăți și de ce contează: datele bune nu sunt un moft de raportare, sunt infrastructura pe care se iau decizii de securitate.

Ce rămâne nerezolvat

Lista de întrebări deschise e mai lungă decât răspunsurile. Scriptul de generare a cheilor nu e public. Rolul auditorilor nu e clarificat. Cross-signerii nu au explicat nimic public. Iar corecția CRL-ului, semnată cu cheia slabă, ridică o întrebare despre cine validează ce în lanțul de încredere.

Pe partea de patch-ing, cifrele Cloudflare sunt, în cuvintele lor, „sugestive, nu concludente”, pentru că mixul de trafic e schimbător și plin de boți. Nu transforma asta într-o predicție. Nu există aici o dovadă că s-au pierdut bani, că a crescut CPA-ul cuiva sau că vreo companie a fost amendată. Există o dovadă că certificatele au fost falsificate în primele ore, că jumătate din traficul măsurat pe rețelele mari încă acceptă lanțul compromis și că Android WebView rămâne în urmă cu 30-40%.

Întrebări frecvente

Ce înseamnă „cheie slabă” la o autoritate de certificare? Înseamnă că numărul folosit pentru a semna certificate e previzibil și recuperabil din certificatele publice. La eMudhra, una dintre chei era numărul 4, ceea ce permite oricui să emită certificate pentru orice domeniu, acceptate de clienții nepatchuiți care nu impun Certificate Transparency.

Am fost atacat dacă site-ul meu a folosit eMudhra? Nu poți deduce asta din faptul că furnizorul a avut chei slabe. Cloudflare raportează aproximativ 22.000 de handshake-uri încercate, majoritatea pe site-uri de test sau pe certificate proprii ale serverelor, toate refuzate după patch. Pentru o concluzie despre propriul sistem ai nevoie de loguri și de verificare, nu de presupuneri.

Cât de repede trebuie să reacționezi la un astfel de incident? În ore, nu în zile, dacă ai sisteme care fac conexiuni de ieșire. Cloudflare a patchuit în aceeași zi și a avut inventarul complet în patru ore. Restul internetului, conform propriilor măsurători, s-a mișcat mult mai lent și s-a oprit după primul weekend.

AI-ul ajută, dar decizia și execuția rămân umane

Analiza asistată de AI a ajutat Cloudflare să găsească în patru ore toate sistemele care aveau încredere în cheile slabe. Asta e valoarea reală a automatizării: viteză la inventar și la triere, nu înlocuirea judecății. Decizia despre ce patchuiești primul, ce riști dacă amâni și ce comunici clienților rămâne la om, la cel care înțelege arhitectura și contextul.

La fel stă treaba și în marketing. AI-ul poate tria date, poate propune priorități, poate genera rapoarte. Dar media buyer-ul rămâne cel care decide unde se duce bugetul și ce înseamnă un semnal în contul lui, nu în graficul general. Iar pasul concret, de la „am citit analiza” la „am verificat ce sisteme comunică în infra mea”, îl face ALLSoft Agency.

Dacă vrei să înțelegi cum se leagă securitatea infrastructurii de performanța campaniilor și de măsurarea corectă, discutăm. Fără hype, cu cifre.