Napad na Axios: Zakaj odprtokodenskim npm odvisnostim ne smete slepo zaupati

Vaša ekipa pregleda kodo. Zaženete teste. CI cevovod je zelen. In vseeno paket, ki mu 100 milijonov razvijalcev vsak teden zaupa, na vsaki napravi, ki zažene npm install, namesti trojanca za oddaljen dostop. To se je zgodilo z Axisom marca 2026 — in to je opozorilo, na katerega večina inženirskih ekip in tehničnih direktorjev še ni pripravljena.

Navdih: ta članek. Perspektiva in analiza spodaj sta izvirni.

Kaj se je zgodilo z Axisom

Axios je na obljubah temelječ HTTP odjemalec, ki se uporablja v skoraj vsaki kategoriji sodobnih JavaScript aplikacij — spletnih aplikacijah, zgrajenih z React, Vue ali Angular; namiznih aplikacijah na osnovi Electron; mobilnih aplikacijah z React Native; SaaS skrbniških ploščah; CI/CD orodjih. V grafu odvisnosti sedi neopazno. Prav ta nevidnost je tisto, kar napadalci izkoriščajo.

Konec marca 2026 je napadalec z ogroženimi poverilnicami vodilnega vzdrževalca projekta objavil dve zastrupljeni različici na npm: axios@1.14.1 in axios@0.30.4. Nobena različica se ne pojavi na uradnem seznamu oznak v repozitoriju Axios na GitHubu. Kakršna koli avtomatizirana preveritev, ki primerja objavljene različice npm z oznakami repozitorija, bi opazila neskladnost — toda večina cevovodov tega preverjanja ne izvaja.

Obe zlonamerni različici sta vbrizgali novo odvisnost — plain-crypto-js@4.2.1 — ki se nigjer ne pojavi v zakoniti izvodni kodi Axisa. Ko je bila nameščena z omogočenimi npm skripti, je kljuka postinstall sprožila node setup.js, ki je prenesla zabrisani dropper. Ta dropper je nato pridobil platformno specifičen trojanski korak (RAT), ki je ciljal na macOS, Windows ali Linux.

Zakaj standardna orodja tega ne zaznajo

Podrobnost, ki bi morala skrbeti vsako DevOps ekipo, je naslednja: dropper zlonamerne programske opreme se je počistil za seboj. Po izvedbi kateri koli pregled imenika nameščenega paketa pokaže povsem čist manifest. Brez skripte postinstall. Brez setup.js. Brez sumljivega polja v package.json. Zagon npm audit ali ročni pregled nameščenih datotek ne razkrije ničesar.

Odsotnost dokazov ni dokaz odsotnosti. Standardna varnostna orodja npm so slepa za to vrsto napada, ko je dropper že tekel.

Kazalniki ogroženosti, ki jih dejansko lahko iščete, so:

• Omrežna domena: sfrclak[.]com
• IP naslov: 142.11.206.73
• macOS artefakt: /Library/Caches/com.apple.act.mond
• Linux artefakt: /tmp/ld.py
• Windows artefakti: %PROGRAMDATA%\wt in datoteke %TEMP%, ki ustrezajo *.vbs ali *.ps1 (obstajajo le kratko med izvajanjem)
• SHA-256 — axios@1.14.1: 2553649f2322049666871cea80a5d0d6adc700ca
• SHA-256 — axios@0.30.4: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
• SHA-256 — plain-crypto-js@4.2.1: 07d889e2dadce6f3910dcbc253317d28ca61c766

Če vaši dnevniki omrežnega odtoka kažejo katero koli povezavo z domeno ali IP naslovom med gradbenem oknom, obravnavajte to kot potrjeno ogroženost ne glede na to, kaj kaže imenik paketa.

Kaj je bilo dejansko ogroženo

Pot okužbe je korak namestitve ali gradnje — ne izvajanje aplikacije. Končni uporabniki, ki nalagajo spletno aplikacijo v brskalniku, niso neposredno izpostavljeni. Cilj je razvijalsko okolje in, kar je še bolj kritično, CI/CD cevovod.

Kateri koli delovni tok, ki je namestil prizadeto različico z omogočenimi npm skripti, je morda izpostavil vsako skrivnost, dostopno v tem okolju ob času namestitve. To vključuje:

• Poverilnice ponudnika oblaka shranjene v okoljskih spremenljivkah — dostopne ključe AWS, GCP, Azure
• Ključe za uvajanje repozitorija ki se uporabljajo za potiskanje kode ali sprožitev uvajanja v nadaljnji verigi
• Žetone za objavo npm — ki bi jih napadalec lahko uporabil za zastrupitev dodatnih paketov in razširitev napadne površine
• API ključe za interne storitve, ponudnike plačil ali katero koli integracijo tretjih strank, dostopno iz gradbenega okolja

Če obstaja kakršna koli možnost, da je vaša ekipa ali cevovod zagnal eno od prizadetih različic, obravnavajte ta okolja kot v celoti ogrožena. Zamenjajte vsako skrivnost, ki je bila dostopna med namestitvijo. Napadalec z dostopom do repozitorija ali ključi za podpisovanje lahko doda stranska vrata v prihodnje izdaje — ali se neposredno obrne k vašim uporabnikom in zalednim sistemom.

Temeljni vzrok: Varnost poverilnic za vzdrževalce

Ta napad je uspel, ker je napadalec ogrozil poverilnice zaupanja vrednega vzdrževalca. Vse ostalo — zastrupljeni paketi, koristna obremenitev RAT, samočistilni dropper — je operativna izvedba načrta, ki ga je omogočila ena ukradena poverilnica.

Za vodje inženiringa, ki objavljajo pakete ali upravljajo interne registre, je to neposredna lekcija. Računi vzdrževalcev za katerikoli npm paket — interni ali zunanji — morajo uveljavljati večfaktorsko avtentikacijo. Žetoni za objavo morajo biti omejeni na minimalno zahtevano dovoljenje, redno zamenjani in nikoli shranjeni v čistem besedilu kot CI okoljske spremenljivke, vidne vsem opravilom cevovoda.

Zaupanje v odprto kodo ni lastnost paketa. Je lastnost procesov in praks upravljanja poverilnic, ki varujejo vsako osebo, pooblaščeno za objavo. Ko je en račun ogrožen, zaupanje, ki ga je paket pridobil pri 100 milijonih tedenskih prenosih, postane napadni vektor.

Kaj naj inženirske ekipe storijo zdaj

Incident Axios ni razlog za prenehanje uporabe odprtokodenskih paketov. Je razlog za aktivno upravljanje zaupanja v odvisnosti namesto predpostavljanja le-tega. To so konkretni koraki, ki obravnavajo specifičen vzorec napada:

1. Uveljavljajte datoteke z zaklepanjem in zgoščenimi vrednostmi v CI. Uporabite package-lock.json ali yarn.lock z npm ci v cevovodih. Nikoli ne dovolite, da npm install razreši na različico, ki ni zaklenjena v datoteki z zaklepanjem. Obravnavajte spremembe datoteke z zaklepanjem kot zahtevne izrecni pregled v zahtevah za vlečenje.
2. Preglejte nepričakovane tranzitivne odvisnosti. Ko paket, kot je Axios, pridobi novo tranzitivno odvisnost, ki prej ni bila prisotna, je to signal. Orodja, kot sta npm ls in poročanje o razlikah odvisnosti v CI, lahko samodejno razkrijejo nove tranzitivne dodatke za pregled.
3. Navzkrižno preverite različice, objavljene na npm, z oznakami GitHuba. Če je različica objavljena na npm, a se ne pojavi na seznamu oznak repozitorija, je ne namestite. To preveritev avtomatizirajte v delovnih tokovih posodabljanja odvisnosti.
4. Omejite skripte namestitve npm v CI. Kjer je mogoče, za namestitve produkcijskih odvisnosti uporabite --ignore-scripts ali zaženite kljuke postinstall v izoliranih okoljih brez dostopa do skrivnosti. Skripte postinstall, ki niso bile izrecno pregledane in odobrene, ne smejo izvrševati z dostopom do poverilnic oblaka.
5. Spremljajte omrežni odtok iz gradbenega okolja. Nepričakovane odhodne povezave z neznanimi domenami med namestitvijo paketa so kazalnik ogroženosti. CI cevovodi morajo imeti seznam dovoljenih za odtok, kjer infrastruktura to dovoljuje.
6. Zamenjajte skrivnosti po katerem koli nepreverjenem namestitvenem dogodku. Ko obstaja kakršna koli negotovost glede tega, katere različice paketov so se izvajale v okolju, ga obravnavajte kot potencialno ogroženo in preventivno zamenjajte. Stroški zamenjave so daleč nižji od stroškov nezaznane izpostavljenosti poverilnic.

Kaj bi morali tehnični direktorji razumeti o tveganju dobavne verige

Napadi na dobavno verigo npm niso teoretični scenariji. So operativni. Incident Axios sledi vzorcu, ki je bil viden pri desetinah podobnih napadov v zadnjih letih — specifična novost je obseg ciljnega paketa in sofisticiranost čiščenja po namestitvi.

Vprašanje za vodstvo inženiringa ni, ali je ta vrsta napada resnična. Nedvomno je. Vprašanje je, ali bi vaše trenutne prakse upravljanja odvisnosti, konfiguracija CI in ravnanje s skrivnostmi omejile škodo, če bi paket, ki mu vaša ekipa danes zaupa, jutri postal napadni vektor.

Za večino organizacij je pošten odgovor: verjetno ne v celoti. Blažilni ukrepi niso eksotični — so inženirska disciplina, sistematično aplicirana na življenjski cikel odvisnosti. Začnite z uveljavljanjem datoteke z zaklepanjem, revizijo tranzitivnih odvisnosti in izolacijo skrivnosti v gradbenem okolju. Zgradite nadzor in opozarjanje okoli tega. Naredite to del pregleda izdaj, ne naknadne misli.

Excellence Consulting sodeluje z ekipami programske inženiringov in tehnološkim vodstvom pri oceni in krepitvi praks varnosti programske dobavne verige — od upravljanja odvisnosti do utrjevanja CI/CD cevovoda. Če incident Axios dviga vprašanja o vaši trenutni varnostni drži, z veseljem pregledamo, kako bi izgledala praktična ocena za vaše okolje.