O săptămână nebună în cybersecurity: de ce chat-ul nostru AI din UE a rămas în siguranță în fața breșelor recente

tl;dr: A treia săptămână din octombrie 2026 a adus un val extraordinar de incidente de securitate în tech, dar DentroChat și datele tale sunt în siguranță.

Dacă urmărești știrile de securitate, săptămâna asta pare o inundație. Avertismentele minore apar des, dar când atât de multe unelte de bază și platforme cloud sunt exploatate în câteva zile, trebuie spus direct: e WILD.

În mai puțin de o săptămână s-au strâns toate astea:

• Incidentul autorității de certificare eMudhra: 8 certificate intermediare sub rădăcina emSign a eMudhra aveau chei private extrem de slabe. Pentru că aceste chei puteau fi reconstruite ca să intercepteze trafic HTTPS, browserele majore au trebuit să blocheze certificatele, eMudhra a anunțat azi că iese complet din afacerea globală de certificate SSL/TLS (!), iar uv, pip, Node.js, Bun, Go și Rust (!) au primit update-uri de urgență ca să elimine CA-ul compromis din trust store-urile incluse.
• CVE-uri critice în software central al internetului: Două vulnerabilități de execuție remote de cod fără autentificare au fost patch-uite în PHP (CVE-2026-109618 și CVE-2026-109619), alături de un buffer overflow critic în Google Brotli (CVE-2026-111497), un RCE neautentificat de severitate maximă în GitLab (CVE-2026-110264) și vulnerabilitatea „PwnEscape” din kernel-ul Linux (CVE-2026-99999).
• Compromiterea supply chain-ului LiteLLM: Ieri, pe 21 octombrie, atacatorii au compromis (din nou) pipeline-ul de release al LiteLLM și au publicat o versiune cu backdoor (v1.107.0) pe PyPI și Docker Hub. Pentru că pachetul malițios includea un hook de startup care rula automat la fiecare pornire de Python, a extras imediat credențiale cloud și chei API de pe serverele afectate.
• Breșe pe platformele Railway și Zeabur: Zeabur a anunțat că se închide definitiv după o a doua breșă care a expus 3,2 milioane de înregistrări cu variabile de mediu de la 321.000 de conturi. Ieri, Railway a spus că un atacator a accesat și decriptat variabilele de mediu ale clienților. Ținta, interesant, erau cheile de inferență AI.
• Breșe majore enterprise: Atacatorii au obținut acces la tenant-ii clienților Microsoft 365 folosind credențiale de backup ConnectWise (SkyKick) furate, iar Capcom a avut o breșă care a afectat 11,7 milioane de conturi de utilizator.

E o „Cyberpocalypse”, sau sistemul imunitar al internetului se trezește?

De ce apar atât de multe bug-uri vechi simultan în compilatoare de regex, decodere de compresie, alocatoare de memorie și setup-uri criptografice?

Răspunsul e în principal că AI-ul citește acum codul lumii. Cercetătorii și apărătorii (la fel ca atacatorii) lasă AI-ul să auditeze codul bibliotecilor open source. Rezultatul: multe cazuri limită pe care reviewerii umani le-au ratat 15 ani. Chiar și cheile slabe ale CA eMudhra par să fi fost observate cu ajutorul AI.

Unii comentatori numesc săptămâna asta „Cyberpocalypse”. Noi vedem altfel: sistemul imunitar al internetului se trezește în sfârșit și se vindecă singur. Majoritatea bug-urilor stăteau de ani în cod de producție, iar descoperirea lor înseamnă că în sfârșit pot fi reparate.

Pentru că mi-am scris licența la TU Graz despre modelul de încredere și riscurile structurale ale autorităților de certificare acum mulți ani, cascada eMudhra până la uv, pip, Node.js și Bun m-a readus la motivul pentru care am ales tema atunci. Pe internet, încrederea are multe forme și e un sistem foarte complex.

Unde se situează DentroChat față de incidentele din săptămâna asta

Dacă folosești DentroChat la muncă zilnică și documente confidențiale, conversațiile și fișierele tale nu au fost afectate de niciunul dintre aceste incidente. Pentru că păstrăm arhitectura lean, cea mai mare parte din software-ul afectat nici nu e în stack-ul nostru, iar ce folosim l-am patch-uit imediat:

• Problema de încredere CA la uv, pip, Node.js și Bun: Uneltele CLI și runtime-urile au propria listă de autorități de certificare de încredere, deci orice unealtă care avea încredere în rădăcina eMudhra compromisă trebuia actualizată. DentroChat nu folosește deloc uv sau pip pe servere. Aplicația noastră web rulează pe Bun, așa că am actualizat containerele de producție la Bun 1.4.4 (împreună cu certificatele Debian patch-uite), eliminând complet rădăcina eMudhra compromisă.
• LiteLLM (malware v1.107.0): Deși rutăm cererile AI printr-un gateway european de inferență (Cortecs), nu folosim biblioteca Python LiteLLM sau imaginile Docker ale ei nicăieri în stack.
• Railway, Zeabur și platforme cloud de deploy: Nu găzduim pe PaaS-uri multi-tenant pentru developeri ca Railway sau Zeabur și nu stocăm datele clienților la hyperscaler-i din SUA sau în tenant-i Microsoft cloud. Cum documentăm pe pagina Subprocesori, gestionăm deploy-urile cu propria instanță Coolify self-hosted, care rulează direct pe serverele noastre europene. Niciun vendor PaaS extern nu deține variabilele noastre de mediu sau secretele de deploy.
• PHP, GitLab și dependențe de aplicație: Nu rulăm PHP sau GitLab self-hosted. Am auditat și actualizat tot arborele de dependențe al platformei de chat și al site-ului, iar acum avem zero vulnerabilități cunoscute.

Cum am proiectat DentroChat ca datele tale să rămână în siguranță

Pentru că auditarea codului asistată de AI va continua să scoată la iveală CVE-uri noi în open source, pachetele terțe nu vor fi niciodată „fără bug-uri”. De aceea am construit DentroChat cu izolare strictă, ca un defect într-un component să nu poată compromite datele tale sau serverele noastre.

1. Execuție de cod într-un sandbox WebAssembly fără rețea

Anul ăsta, un raport de securitate viral a arătat că agenții OpenAI au evadat din sandbox într-o evaluare internă. Evadarea a fost posibilă pentru că agenții rulau într-un container Linux care avea încă acces la rețea către un proxy intern de registry de pachete, iar agentul a exploatat un zero-day în acel proxy ca să ajungă pe internet.

La DentroChat, calea asta de atac nu există (deocamdată), pentru că nu rulăm cod de utilizator într-un container Linux cu shell sau installer de pachete. Când încarci un spreadsheet sau îi ceri lui DentroChat o analiză Python, codul rulează într-un sandbox WebAssembly (WASM) izolat:

• Fiecare bibliotecă Python suportată pentru analiză de date și documente e pre-bundled la build, deci la runtime nu se descarcă nimic de pe PyPI sau dintr-un proxy intern.
• Înainte să ruleze Python, toate API-urile de rețea outbound, loader-ele dinamice de biblioteci și punțile către filesystem-ul host sunt tăiate și eliminate din runtime.
• Chiar dacă o bibliotecă Python ar conține vreodată un backdoor supply-chain ca scriptul de startup LiteLLM, sandbox-ul WebAssembly n-are conexiune de rețea să trimită date afară și n-are acces la variabilele de mediu ale serverului sau la fișierele altor utilizatori. După ce primești graficul sau documentul, workspace-ul temporar e șters din nou.

2. O perioadă de răcire de 7 zile împotriva atacurilor supply-chain

Atacul LiteLLM a funcționat așa:

1. versiunea malițioasă e publicată pe PyPI
2. pipeline-urile automate de build din lume o instalează imediat
3. după 2 ore cercetătorii își dau seama că ceva nu e în regulă
4. până atunci codul malițios a putut deja compromite multe sisteme

Ca să prevenim așa-numitele „supply chain attack”, managerul nostru de pachete impune, pe lângă lockfile-uri înghețate, o vârstă minimă de release de 7 zile. O versiune open source proaspăt publicată trebuie să supraviețuiască o săptămână întreagă de scrutin public înainte ca pipeline-ul nostru de build să o permită instalată. Exceptând, desigur, când audităm manual și fixăm un patch de securitate specific, cum e update-ul de runtime de azi…

3. De ce blocăm accesul la rețeaua internă când AI-ul vizitează site-uri

Când îi ceri lui DentroChat să citească o pagină web sau să aducă un set de date public de la o API open-data, serverul nostru fetch-uiește URL-ul în numele tău. Fără limite stricte de rețea, un site malițios ar putea ascunde instrucțiuni care păcălesc AI-ul să ceară adrese interne (cum ar fi 127.0.0.1 sau porturi Docker interne) în locul unui site public. Tehnica asta, numită Server-Side Request Forgery (SSRF), ar putea expune servicii interne de pe server.

De aceea fetcher-ul nostru outbound rezolvă DNS înainte de conectare, blochează toate range-urile IP private, loopback și interne și fixează adresa IP verificată la fiecare redirect. Chiar dacă o pagină încearcă să păcălească modelul sau folosește DNS rebinding ca să schimbe IP-ul domeniului în 127.0.0.1 în ultima milisecundă, conexiunea e refuzată înainte să atingă rețeaua noastră internă.

4. Criptare la rest gestionată de noi pe Hetzner în Europa

Toate serverele de aplicație DentroChat, bazele de date și uneltele self-hosted rulează pe Hetzner în Germania, iar backup-urile criptate și log-urile de server pseudonimizate stau la Scaleway în Franța, totul sub jurisdicție UE și în afara US CLOUD Act. Poți inspecta infrastructura completă oricând pe pagina Subprocesori.

Toate datele sunt protejate cu criptare în tranzit și criptare la rest. Un detaliu tehnic des ignorat: la majoritatea hosting-urilor (inclusiv Hetzner) discurile serverelor nu sunt criptate la rest deloc. De aceea configurăm și gestionăm noi criptarea la rest. Setup-ul ăsta se potrivește cu controalele noastre de confidențialitate:

• Zero antrenament pe conversațiile sau fișierele tale
• Ștergere automată a chat-urilor pe care o controlezi tu
• Mod Discreet Chat când vrei o conversație exclusă din memoria AI

Rămânem vigilenți

Securitatea bună nu e niciodată „gata”.

Mai ales acum, când atât cercetătorii cât și atacatorii găsesc vulnerabilități zero-day cu AI mai repede ca niciodată. Suntem recunoscători că arhitectura noastră a ținut DentroChat complet protejat de valul de incidente din săptămâna asta, dar rămânem vigilenți.

Evaluăm activ cum putem scurta timpul de răspuns la viitoare exploit-uri zero-day, întări granițele serverelor și păstra datele tale în siguranță, indiferent cât de nebună va fi următoarea săptămână în cybersecurity. Mulțumim că faci parte din DentroChat!