Axios, una dintre cele mai folosite biblioteci JavaScript pentru cereri HTTP, a fost compromisă temporar la finalul lunii martie 2026, după ce atacatorii au obținut acces la contul unui maintainer și au publicat pe npm două versiuni malițioase: axios 1.14.1 și axios 0.30.4. Potrivit post-mortem-ului publicat de Jason Saayman, aceste versiuni au fost online aproximativ trei ore, timp în care au putut instala un remote access trojan (RAT) pe sisteme Windows, macOS și Linux.
Cum s-a produs compromiterea
Din informațiile publicate de echipa axios, compromiterea nu a pornit de la codul proiectului, ci de la un atac de social engineering asupra lead maintainer-ului. Post-mortem-ul oficial arată că atacul a început cu aproximativ două săptămâni înainte de publicarea pachetelor compromise și că accesul obținut pe PC-ul maintainer-ului a permis atacatorilor să folosească acreditările npm pentru a publica versiunile infectate.
Relatări ulterioare despre incident arată că atacatorii au construit o infrastructură foarte credibilă pentru a câștiga încrederea țintei: un spațiu Slack fals, branding clonat și un meeting online folosit ca pretext pentru descărcarea malware-ului. Potrivit TechCrunch și BleepingComputer, întâlnirea a fost folosită pentru a afișa un fals mesaj de eroare și pentru a convinge maintainer-ul să instaleze ceea ce părea a fi o actualizare necesară, dar era de fapt troianul care a dus la compromiterea contului.
Ce conțineau versiunile malițioase de axios
Cele două versiuni compromise au introdus o dependență nouă, plain-crypto-js@4.2.1, care nu exista în release-urile legitime și care nu avea rol funcțional real în bibliotecă. Analizele StepSecurity și Microsoft arată că această dependență rula un mecanism de tip postinstall, contacta infrastructura atacatorului și descărca payload-uri diferite în funcție de sistemul de operare.
Microsoft spune că, după conectarea la serverul de comandă și control, era livrat automat un al doilea stadiu al RAT-ului pentru Windows, macOS sau Linux. StepSecurity adaugă că malware-ul încerca apoi să își șteargă urmele și chiar să își înlocuiască propriul fișier package.json cu o versiune curată, tocmai pentru a îngreuna analiza ulterioară.
Ce versiuni au fost afectate și care este intervalul critic
Potrivit post-mortem-ului publicat de axios, versiunile compromise au fost 1.14.1 și 0.30.4, iar intervalul critic a fost între 31 martie 2026, 00:21 UTC și 31 martie 2026, 03:15 UTC. Maintainer-ul spune explicit că utilizatorii care erau deja fixați pe o versiune curată și nu au rulat o instalare nouă în acel interval nu sunt afectați.
Tot acolo sunt indicate și versiunile considerate sigure pentru revenire: axios 1.14.0 pentru ramura 1.x și axios 0.30.3 pentru ramura 0.x. Microsoft repetă aceeași recomandare și avertizează că orice sistem pe care au fost instalate versiunile compromise trebuie tratat ca potențial compromis.
Cine este suspectat
Atribuirea către actori nord-coreeni a fost făcută public de mai multe surse. TechCrunch a relatat că Google Threat Intelligence Group a legat atacul de gruparea UNC1069, iar Microsoft a spus separat că infrastructura și compromiterea axios au fost atribuite actorului Sapphire Sleet, un nume folosit de Microsoft pentru un actor nord-coreean.
Faptul că Google și Microsoft folosesc denumiri diferite nu schimbă esența concluziei: incidentul este tratat ca un atac de supply chain asociat unor actori nord-coreeni specializați în operațiuni bine coordonate, adesea motivate financiar.
De ce contează pentru utilizatorii de Windows, macOS și Linux
Acest incident este relevant nu doar pentru dezvoltatorii care folosesc axios, ci și pentru echipele care rulează npm install în pipeline-uri de build, pe stații de lucru sau pe servere CI/CD. Pentru că malware-ul era livrat în funcție de sistemul de operare, riscul nu a fost limitat la o singură platformă, iar compromiterea putea duce la furt de token-uri, chei, parole și alte secrete existente pe mașina afectată.
Impactul potențial este amplificat și de popularitatea bibliotecii. Microsoft o descrie ca având peste 70 de milioane de descărcări săptămânale, iar StepSecurity o plasează la peste 100 de milioane, ceea ce explică de ce amploarea exactă a incidentului este încă greu de estimat.
Ce ar trebui să facă organizațiile și dezvoltatorii
Recomandarea oficială a echipei axios este clară: dacă în lockfile sau în logs apare axios 1.14.1, axios 0.30.4 sau dependența plain-crypto-js, sistemul trebuie tratat ca compromis. Pașii indicați includ revenirea la o versiune sigură, ștergerea dependenței malițioase, rotirea tuturor secretelor, token-urilor și credentialelor și verificarea conexiunilor către infrastructura identificată în analiză.
Pentru mediile de CI/CD, recomandarea este și mai strictă: orice build care a rulat în fereastra afectată și a injectat secrete în runner trebuie investigat, iar secretele respective trebuie rotite. Microsoft mai recomandă și dezactivarea actualizărilor automate pentru pachetele axios compromise, deoarece payload-ul includea un mecanism care continua să încerce actualizarea.
Lecția mai mare după incidentul axios
Dincolo de pachetul compromis în sine, cazul axios arată cât de vulnerabil poate deveni întregul lanț software atunci când un singur cont cu încredere ridicată este compromis. Post-mortem-ul proiectului spune că echipa a șters complet dispozitivele afectate, a resetat toate acreditările și lucrează la măsuri precum publicarea prin fluxuri OIDC și setări de release mai greu de deturnat.
Pentru ecosistemul open-source, incidentul este un avertisment serios: atacatorii nu mai urmăresc doar breșe tehnice clasice, ci și oamenii din spatele proiectelor critice. Iar pentru organizații, mesajul este la fel de clar: un simplu npm install într-un moment nepotrivit poate transforma un utilitar banal într-un vector de compromitere extinsă.
