axios CVE-2026-67320: actualizează la 1.18.0 acum

Pe 1 august, menținătorii axios au dezvăluit CVE-2026-67320, o vulnerabilitate de poluare a prototipurilor în adaptorul HTTP Node.js al bibliotecii. axios este unul dintre cele mai instalate pachete pe npm, deci aceasta ajunge la multe backend-uri. Pe scurt: în condiții favorabile, un atacator care poate polua Object.prototype poate face serverul tău să ruteze cererile HTTP de ieșire printr-un proxy pe care îl controlează. Pentru apelurile http:// în text simplu, acel proxy poate citi header-ul Authorization, credențialele Basic auth, metoda, URL-ul complet, header-ul Host și corpul cererii, returnând apoi un răspuns la alegerea sa. NVD i-a acordat scorul 8.3 (Înalt) pe CVSS 4.0.

Iată mecanismul, pentru că detaliul contează. axios securizează configurația cererii îmbinate construind-o pe un obiect cu prototip null, astfel încât proprietățile moștenite nu pot pătrunde. Dar interceptorii de cereri rulează după această îmbinare, iar un pattern de interceptor foarte comun, return { ...config } sau Object.assign({}, config), convertește silențios acel obiect securizat înapoi într-unul obișnuit cu Object.prototype în lanțul său. Adaptorul Node citește apoi config.proxy de pe acel obiect, parcurge lanțul prototipului și găsește ceea ce a plasat atacatorul la Object.prototype.proxy. Corecția din 1.18.0 citește acele valori de configurare imbricate printr-un accessor sigur care ignoră proprietățile moștenite.

O precauție sinceră: axios singur nu îi oferă atacatorului acest acces. Aceștia au nevoie de o vulnerabilitate separată de poluare a prototipurilor undeva în aplicația ta sau în arborele de dependențe pentru a seta Object.prototype.proxy în primul rând. axios este amplificatorul, nu punctul de intrare. Exact de aceea merită luată în serios. Gadget-urile de poluare a prototipurilor sunt comune în bazele de cod JavaScript, iar aceasta transformă o descoperire pe care multe echipe o consideră teoretică în exfiltrare de credențiale.

Vedem acest tipar constant în cadrul testelor de penetrare și auditurilor de securitate. Scanerul unui client semnalează o problemă de poluare a prototipurilor, cineva o clasifică drept „fără impact real” și rămâne în backlog un an. Apoi apare un bug ca acesta și teoreticul devine o linie dreaptă spre tokenuri scurse. Poluarea prototipurilor este rareori exploitul complet. Este primitivul care face următorul bug mult mai grav.

Acțiunea imediată este banală și ar trebui să o faci astăzi: actualizează axios la 1.18.0, sau la 0.33.0 dacă ești încă pe linia 0.x. Orice versiune de la 1.15.2 până la 1.18.0, sau de la 0.31.1 până la 0.33.0, este afectată. Rulează npm ls axios și îți va afișa fiecare copie din arborele tău, inclusiv cele tranzitive pe care propriul tău cod nu le-a importat niciodată. Acele copii tranzitive sunt de obicei cele care te prind, pentru că nimeni nu le urmărește.

Mergi apoi cu un pas mai departe față de patch. Din munca noastră cu PHP și Docker pentru construirea de backend-uri cloud-native, echipele care gestionează calm aceste dezvăluiri sunt cele care tratează deja traficul de ieșire ca pe ceva de controlat, nu doar cel de intrare. Câteva lucruri care aduc beneficii aici:

Trimite apelurile server-la-server prin https://, întotdeauna. Acest bug nu scurge nimic printr-un TLS validat corespunzător. Apelul intern http:// în text simplu dintre două servicii este cel care te arde.
Restricționează egresul. Dacă un serviciu trebuie să ajungă doar la trei gazde cunoscute, o listă albă de egres sau un proxy pe care îl rulezi efectiv înseamnă că un config.proxy deturnat nu are nicăieri util să meargă.
Păstrează secretele în afara URL-urilor și scurtează durata de viață a oricărui token pe care îl trimiți în Authorization pe hop-uri interne. Tokenurile cu durată scurtă limitează daunele când ceva se scurge.

Există și un unghi mobil, ușor de ratat. În proiectele noastre native iOS și Android, aplicația în sine nu rulează axios, dar backend-ul-pentru-frontend sau API gateway-ul din spatele ei foarte des o face. Un token upstream scurs acolo poate compromite silențios fiecare client mobil din aval, și nu îl vei vedea în jurnalele proprii ale aplicației. Când revizuim un sistem mobil, urmărim tokenul tot drumul înapoi prin backend, nu doar până la primul hop.

Lecția din spatele CVE este cea care merită reținută. Arborele tău de dependențe este suprafață de atac, iar „nu folosim acea funcție” nu este același lucru cu „acel cod nu poate rula.” axios are suport proxy pe care poate nu îl configurezi niciodată, iar vulnerabilitatea a trăit acolo oricum. A ști ce este instalat efectiv și a putea aplica patch-ul într-o după-amiază este o capacitate pe care o construiești înainte să ai nevoie de ea, nu în timpul unui incident.

Dacă nu ești sigur ce se află în arborele tău de dependențe sau cum iese traficul de ieșire din serviciile tale, hai să vorbim.