AI-ul găsește bug-uri mai repede decât le poți corecta

Două știri au apărut săptămâna aceasta care, privite împreună, ar trebui să pună pe gânduri orice echipă de dezvoltare și securitate.

Prima, cea mare: Anthropic a anunțat Claude Mythos Preview, un nou model AI pe care îl consideră prea periculos pentru a fi lansat public. Motivul? Este extraordinar de bun la descoperirea vulnerabilităților de securitate. Nu vorbim despre exemple simple din competiții CTF. Mythos a găsit un bug vechi de 27 de ani în OpenBSD, unul dintre cele mai securizate sisteme de operare din lume. A descoperit o vulnerabilitate în FFmpeg pe care instrumentele de testare automată o rataseră de cinci milioane de ori. A înlănțuit mai multe vulnerabilități ale kernel-ului Linux pentru a escalada de la acces de utilizator obișnuit la control complet al mașinii. Mii de zero-day-uri în toate sistemele de operare și browserele majore, majoritatea necorectat până când Anthropic le-a raportat.

Anthropic nu lansează modelul public. În schimb, a lansat Project Glasswing, oferind acces la aproximativ 40 de organizații (printre care unele dintre cele mai mari companii tech din lume) pentru a-și scana și corecta propriul cod. De asemenea, oferă credite de utilizare în valoare de 100 de milioane de dolari și 4 milioane de dolari pentru fundații de securitate open-source.

A doua știre, mai mică, dar poate mai instructivă: CVE-2026-39987, o vulnerabilitate de execuție de cod de la distanță pre-autentificare în Marimo, un notebook Python open-source popular printre data scientists. Scor CVSS 9,3. Vulnerabilitatea se afla într-un endpoint WebSocket (/terminal/ws) care pur și simplu nu verifica autentificarea, deși toate celelalte endpoint-uri WebSocket din codebase o făceau. Sysdig a implementat honeypot-uri și a observat exploatarea la 10 ore după divulgarea publică. Zece ore.

Ce au în comun aceste două știri

Firul care leagă Mythos și CVE-ul Marimo este același: fereastra dintre existența unei vulnerabilități și exploatarea ei s-a prăbușit.

În cazul Mythos, avem un AI care poate găsi bug-uri pe care cercetătorii umani le-au ratat timp de decenii. În cazul Marimo, avem atacatori care weaponizează o vulnerabilitate dezvăluită înainte ca majoritatea echipelor să fi citit măcar advisory-ul. Ambele indică aceeași direcție: viteza de corecție și conștientizarea suprafeței de atac nu mai sunt discipline opționale. Sunt o chestiune de supraviețuire.

Și iată ce mă îngrijorează. Directorul de red teaming frontier al Anthropic a estimat că modelele open-weight vor ajunge la nivelul de descoperire a bug-urilor specific Mythos în șase până la optsprezece luni. Asta înseamnă că această capabilitate nu va rămâne pentru totdeauna blocată în spatele unui preview de cercetare cu acces restricționat. Se va răspândi.

Ce înseamnă asta pentru echipele de dezvoltare

Dacă construiești aplicații web, API-uri sau orice altceva cu un strat WebSocket, bug-ul din Marimo ar trebui să-ți pară inconfortabil de familiar. Un singur endpoint care a omis autentificarea. Toate celelalte endpoint-uri au procedat corect. Exact acest tip de inconsistență scapă prin code review, trece de QA și stă în producție luni de zile.

Din munca noastră cu PHP și Docker la clienți enterprise, vedem constant acest tipar. O echipă adaugă un endpoint nou, copiază dintr-unul existent, elimină „temporar" middleware-ul de autentificare în timpul dezvoltării și ajunge în producție. Restul aplicației este perfect securizat. Un singur route nu este. Asta e tot ce trebuie.

Când facem teste de penetrare pentru studiouri de gaming și platforme de travel, căutăm specific aceste inconsistențe. Endpoint-ul de debug complet deschis în spatele unui load balancer. Panoul de administrare care verifică autentificarea, dar nu autorizarea. API-ul de staging care a ajuns accidental să fie pointat prin DNS la producție. Acestea sunt bug-urile din care se fac vulnerabilități CVSS 9+, și exact tipul de vulnerabilități la nivel de logică pe care modelele AI de tip Mythos le vor descoperi la scară largă.

Și aspectul mobil contează

Dacă te gândești „asta e o problemă server-side, aplicația mea mobilă e în regulă", mai gândește-te o dată. În proiectele noastre native iOS și Android, am văzut aplicații care se bazează pe server pentru toată validarea de securitate. Dacă backend-ul este compromis printr-o vulnerabilitate precum CVE-2026-39987, tot ce trimite și primește aplicația mobilă este expus. Token-uri API, date ale utilizatorilor, credențiale de sesiune.

Am văzut asta în aplicații de healthcare și IoT unde clientul mobil stochează date sensibile local și le sincronizează cu un backend pe care echipa îl considera sigur „pentru că e în spatele unui firewall". Vulnerabilitatea din Marimo putea fi exploatată printr-o singură conexiune WebSocket neautentificată. Firewall-urile nu ajută dacă ușa e deja deschisă din interiorul stratului aplicației.

Noile cerințe App Store ale Apple pentru conformitatea cu SDK-urile watchOS și iOS 26 adaugă și ele presiunea termenelor limită. Echipele care se grăbesc să respecte termenele din aprilie, menținând în același timp securitatea backend-ului, sunt exact tipul de situație operațională în care verificările de autentificare sunt omise.

Un lucru pe care îl poți face chiar acum

Iată un pas concret: auditează fiecare endpoint WebSocket și real-time din aplicația ta pentru consistența autentificării. Nu doar „necesită aplicația autentificare?", ci „fiecare endpoint în parte, inclusiv cele de debug, terminal, monitorizare și cele interne, aplică efectiv autentificarea?"

Vulnerabilitatea din Marimo a existat deoarece endpoint-ul lor WebSocket de terminal folosea websocket.accept() fără a apela validate_auth(). Celelalte endpoint-uri o apelau. Acel decalaj — un singur apel de funcție lipsă dintr-un singur fișier — a fost un RCE pre-autentificare cu scor CVSS 9,3.

Dacă faci parte dintr-o echipă care gestionează aplicații web sau API-uri, alocă o oră săptămâna aceasta și caută în codebase handler-ele de accept WebSocket. Verifică-le pe fiecare. Dacă folosești Starlette, FastAPI, Express cu ws sau orice framework care tratează conexiunile WebSocket ca o cale separată față de middleware-ul HTTP, probabil ai endpoint-uri care ocolesc stiva normală de autentificare. Găsește-le înainte să o facă altcineva.

Imaginea de ansamblu

Anthropic prezintă Project Glasswing ca „defenders first" — ideea este de a le da un avans celor cu intenții bune înainte ca capabilitățile de tip Mythos să devină larg disponibile. Aceasta este o poziție rezonabilă, dar se bazează și pe o premisă inconfortabilă: singura modalitate de a te proteja împotriva unui AI care găsește bug-uri este să-l construiești primul și să speri că faci patch-uri mai repede decât pot exploata atacatorii.

Din munca noastră de securitate în configurarea Cloudflare și Akamai pentru protecție DDoS pe platforme de travel la scară largă, trăim deja într-o lume în care atacurile automate se mișcă mai repede decât timpii de răspuns umani. Diferența cu descoperirea vulnerabilităților asistată de AI este că atacurile nu vor fi doar mai rapide. Vor fi mai inteligente. În loc de scanare brute-force, vei obține exploatarea țintită a vulnerabilităților de logică pe care nicio regulă WAF nu le poate prinde, deoarece atacul arată ca o cerere legitimă.

Asta schimbă modul în care arhitecturezi apărările. Regulile statice nu mai sunt suficiente. Ai nevoie de securitate stratificată: autentificare la fiecare endpoint, segmentare corespunzătoare a rețelei astfel încât un server notebook compromis să nu poată accesa baza de date de producție, și monitorizare reală — nu doar agregarea logurilor, ci detecție efectivă a anomaliilor în ceea ce fac conexiunile tale WebSocket.

Am discutat cu clienții noștri despre această schimbare și înainte. Săptămâna aceasta a făcut-o să pară mult mai puțin teoretică.

Unde mergem de aici

Industria de securitate urmează să devină mult mai aglomerată. Modelele AI care pot găsi mii de zero-day-uri într-o săptămână vor forța menținătorii de software într-un sprint permanent. Proiectele open-source cu echipe mici, precum Marimo, vor fi cele mai afectate, deoarece nu au resursele necesare pentru a face patch-uri la viteza pe care o impune acum amenințarea.

Dacă echipa ta construiește pe baza unor instrumente open-source de data science, notebook-uri pentru dezvoltatori sau orice tooling intern proiectat pentru rețele de încredere, dar care acum se află undeva aproape de internet, acesta este semnalul tău de alarmă. Tratează fiecare instrument din stack ca parte din suprafața ta de atac. Fă patch-uri agresiv. Și nu presupune că ceva este sigur doar pentru că este „intern".

Dacă ceva din toate acestea sună ca o conversație pe care echipa ta trebuie să o aibă, hai să vorbim.