Shai-Hulud: npm-mato ja miten tarkistat, koskeeko se buildejasi

Shai-Hulud on itsestään leviävä mato, joka saastuttaa npm-paketteja: ohjelmistotoimitusketjuun kohdistuva hyökkäys, joka värvää jokaisen uhrin levittämään sitä eteenpäin. Se käynnistyy, kun paketti asennetaan, varastaa koneelta npm-tokenit, GitHub-tokenit ja pilviavaimet ja käyttää npm-tokenia julkaistakseen saastuneita versioita uhrin muista paketeista. Ensimmäisen aallon jälkeen syyskuussa 2025 se on palannut toistuvasti, ja toukokuussa 2026 sen tekijät julkaisivat lähdekoodin, joten jokainen sen jälkeinen aalto voi olla eri ryhmän tekemä. Jos jokin buildeistasi asensi saastuneen version, käsittele sitä jobia vaarantuneena ja vaihda jokainen salaisuus, jonka se pystyi lukemaan.

Suurin osa vahingosta syntyy CI:ssä. Marraskuun 2025 aallossa Wiz havaitsi, että vain 23 % tartunnoista oli kehittäjien koneilla ja loput enimmäkseen CI/CD-putkissa, joista GitHub Actions oli yleisin. Buildi asentaa satoja paketteja, sillä on julkaisemiseen ja käyttöönottoon tarvittavat salaisuudet, ja se ajaa jokaisen asennusskriptin kenenkään valvomatta. Kun uusi aalto julkistetaan, jokainen tiimi kysyy siis saman kysymyksen: asensiko jokin buildeistamme saastuneen version?

Mitä tapahtui

Milloin	Aalto	Mikä oli toisin
Syyskuu 2025	Shai-Hulud	postinstall-skripti ajoi 3,6 Mt:n bundle.js-tiedoston, käytti TruffleHogia salaisuuksien etsimiseen ja julkaisi uudelleen enintään 20 ylläpitäjän pakettia. Yli 500 pakettia kärsi, muun muassa @ctrl/tinycolor ja 18 @crowdstrike-pakettia. CISA julkaisi varoituksen 23.9.
Marraskuu 2025	Sha1-Hulud: The Second Coming	Siirtyi preinstall-vaiheeseen, asensi Bun-ajoympäristön ajaakseen 10 Mt:n hyötykuorman, lisäsi takaoven enintään 100 pakettiin ylläpitäjää kohden ja rekisteröi saastuneet koneet itse ylläpidetyiksi GitHub-runnereiksi. Zapierin, ENS:n, PostHogin ja Postmanin paketteihin osui; Wiz laski yli 25 000 repositoriota, joista oli vuotanut salaisuuksia.
Joulukuu 2025	”3.0”-testi	Muokattu versio yhdessä paketissa, ilman merkittävää leviämistä.
Toukokuu 2026	TanStack	84 haitallista versiota 42 @tanstack-paketista. Hyökkääjä ei koskaan varastanut npm-tokenia: pull_request_target-työnkulku, myrkytetty Actions-välimuisti ja runnerin muistista luettu OIDC-token antoivat sen julkaista TanStackin oman trusted publishing -julkaisun kautta. Seurataan tunnisteella CVE-2026-45321, lisätty CISA:n KEV-luetteloon 27.5.
Toukokuu 2026	AntV	639 versiota 323 paketista. GitHub Actionsin Linux-runnereilla hyötykuorma luki salaisuuksia runner-prosessin muistista ja ohitti lokien maskauksen. GitHub mitätöi 61 274 npm-kirjoitustokenia.
Kesäkuu 2026	Miasma	32 @redhat-cloud-services-pakettia, julkaistu injektoitujen työnkulkujen kautta pätevin alkuperätiedoin. Jokaisessa tartunnassa oli yksilöllisesti salattu hyötykuorma, joten tiivisteisiin perustuva tunnistus epäonnistui.
Elokuu 2026	CHAINDROP	Suosittuja välimuistipaketteja, kuten keyv, cacheable ja cache-manager, ja kaikkiaan satoja paketteja. Mato pysyi repositoriossa editorien ja tekoälyavustajien konfiguraatiotiedostojen kautta.
Syyskuu 2026	Paluu	7.9. hyötykuorma palasi neljässä paketissa, jotka pääsivät npm:n uuden julkaisuvaiheen haittaohjelmaskannauksen läpi.
Lokakuu 2026	tensorlake	8.10. julkaistiin [email protected], jossa oli mato. OX Security havaitsi uusia hyökkääjän avaimia ja arvelee kyseessä olevan ”itsenäinen uhkatoimija tai uusi ryhmä, joka käyttää Shai-Hulud-nimeä”.

Mitä mato tekee CI-jobissa

Yksityiskohdat muuttuvat aaltojen välillä, mutta kaava pysyy:

1. Se käynnistyy asennuksessa. preinstall- tai postinstall-skripti suoritetaan heti, kun npm install tai npm ci saavuttaa saastuneen version. Mikään koodissasi ei tarvitse importata sitä.
2. Se kerää salaisuuksia. Ympäristömuuttujat, .npmrc-tokenit, pilvitunnukset metatietopalvelusta ja salaisuuksien hallintajärjestelmistä sekä kaiken, mitä TruffleHog löytää levyltä. Myöhemmät aallot lukivat GitHub Actions -runnerin muistia suoraan, jolloin ne saivat salaisuuksia, joita ei koskaan annettu vaiheelle ja jotka maskaus olisi piilottanut lokeista.
3. Se vie ne ulos. Varhaiset aallot loivat madon mukaan nimettyjä julkisia GitHub-repositorioita ja puskivat niihin työnkulun, joka lähetti jokaisen repositorion salaisuuden osoitteeseen webhook.site. Myöhemmät aallot käyttivät hyökkääjän palvelimia ja viestiverkkoja.
4. Se leviää ja jää. Varastetulla npm-tokenilla se julkaisee saastuneita versioita muista paketeista. GitHub-tokenilla se lisää työnkulkuja, rekisteröi itse ylläpidettyjä runnereita tai istuttaa konfiguraatiotiedostoja, jotka ajetaan, kun joku seuraavan kerran avaa repositorion.
5. Se käyttäytyy CI:ssä eri tavalla. Marraskuun 2025 hyötykuorma tarkisti muuttujat GITHUB_ACTIONS, BUILDKITE, CIRCLE_SHA1 ja vastaavat, ja CI:ssä se ajettiin synkronisesti, jolloin se sai työnsä valmiiksi ennen kuin buildi jatkoi.

Keitä asia koskee

Kaikkia, joiden koneet tai buildit asensivat saastuneen version sen ollessa rekisterissä: kehittäjien kannettavia, CI-jobeja, Docker-buildeja, jotka ajavat npm install -komennon, ja itse ylläpidettyjä runnereita. Sinun ei tarvitse olla suoraan riippuvainen paketista; transitiivinen riippuvuus tai npx:llä ajettu työkalu riittää. Jokaisella aallolla on oma luettelonsa paketeista ja versioista, ja saastuneet versiot poistetaan yleensä tuntien tai päivien kuluessa, joten ratkaisevaa on, asensiko jokin ne tuona aikaikkunana.

Miten se toimii

Shai-Hulud ei ole npm:n bugi. Se on haitallista koodia, joka julkaistaan muuten aidoissa paketeissa, ja GitHubin haittaohjelmatiedotteet luokittelevat saastuneet paketit upotetuksi haitalliseksi koodiksi (CWE-506). Jokainen aalto yhdistää muutamia tekniikoita:

• Suoritus asennuksen aikana. npm ajaa paketin elinkaariskriptit, kuten preinstall, postinstall ja prepare, asennuksen aikana käyttäjän tai CI-jobin oikeuksilla. Saastuneen version tarvitsee vain olla riippuvuuspuussa; mikään ei tarvitse importata sitä.
• Leviäminen varastetuilla julkaisuoikeuksilla. Uhrilta otetulla npm- tai GitHub-tokenilla mato julkaisee uusia versioita uhrin muista paketeista hyötykuorma lisättynä, joten jokainen saastunut ylläpitäjä saastuttaa lisää paketteja.
• Julkaisu uhrin oman julkaisuputken kautta (TanStack, toukokuu 2026). GitHubin tietoturvatiedotteen mukaan hyökkääjä ketjutti pull_request_target-työnkulun, forkin ja perusrepositorion välisen luottamusrajan yli myrkytetyn GitHub Actions -välimuistin ja runnerin muistista luetun OIDC-tokenin ja julkaisi TanStackin trusted publishing -julkaisun kautta muuttamatta julkaisutyönkulkua. Saastuneet versiot ilmoittivat valinnaisen riippuvuuden forkissa olevaan committiin, jonka prepare-skripti ajoi hyötykuorman ja epäonnistui sitten tarkoituksella, jolloin npm hylkäsi sen eikä jättänyt jälkiä hakemistoon node_modules.
• Pätevät alkuperätiedot (Miasma, kesäkuu 2026). Injektoidut työnkulut julkaisivat uhrien omista repositorioista, joten saastuneilla versioilla oli pätevät alkuperätiedot, ja tartuntakohtaisesti yksilöllisesti salattu hyötykuorma ohitti tiivisteisiin perustuvan tunnistuksen.

Miten tarkistat, koskeeko tämä sinua

1. Hanki luettelo kohteena olevista versioista kyseisen aallon osalta. Tietoturvatoimittajat julkaisevat ne tuntien kuluessa; esimerkiksi Datadog ylläpitää vaarantumisen tunnusmerkkien repositoriota, jossa on paketti- ja versioluettelot.
2. Hae jokaisesta lukitustiedostosta jokaisessa haarassa, jossa CI ajettiin aikaikkunan aikana, ei vain oletushaarassa.
3. Hae itse buildeista. Etsi CI-lokeista tiedostoja setup_bun.js, bun_environment.js tai muita tietoturvatiedotteessa mainittuja tiedostonimiä sekä asennustulosteita, joissa mainitaan kyseiset versiot. Jos säilytät buildikohtaisia SBOM:ja, hae niistä versioita.
4. Tarkista GitHub-organisaatiosi: madon mukaan nimetyt uudet repositoriot, työnkulkutiedostot, joita et ole kirjoittanut (esimerkiksi shai-hulud-workflow.yml, discussion.yaml tai formatter_*.yml), ja itse ylläpidetyt runnerit, joita et ole rekisteröinyt.

Komentoja, joita voit muokata. Jos haluat hakea jokaisen etähaaran lukitustiedostoista, kirjoita aallon kohteena olevat versiot tiedostoon affected.txt, yksi name@version riviä kohden:

git fetch --all --quiet
for ref in $(git for-each-ref --format='%(refname:short)' refs/remotes); do
  while read -r pkg; do
    name=${pkg%@*}; version=${pkg##*@}
    git grep -n -A3 -F "$name" "$ref" -- '*package-lock.json' '*yarn.lock' '*pnpm-lock.yaml' \
      | grep -F "$version" | sed "s|^|$pkg  |"
  done < affected.txt
done

Näin listaat organisaatiosi itse ylläpidetyt runnerit, matoon viittaavat uudet repositoriot ja työnkulkutiedostot, joita madon tiedetään luovan (korvaa ORG):

gh api --paginate orgs/ORG/actions/runners --jq '.runners[] | [.name, .os, .status] | @tsv'
gh repo list ORG --limit 1000 --json name,description,createdAt \
  --jq '.[] | select((.description // "") | test("hulud"; "i")) | [.name, .createdAt] | @tsv'
for repo in $(gh repo list ORG --limit 1000 --json name --jq '.[].name'); do
  gh api "repos/ORG/$repo/contents/.github/workflows" --jq '.[].name' 2>/dev/null \
    | grep -E '^(shai-hulud-workflow\.yml|discussion\.yaml|formatter_.*\.yml)$' \
    | sed "s|^|$repo  |"
done

Repositorioilla voi olla myös omia runnereita (gh api repos/ORG/REPO/actions/runners), ja varhaiset aallot loivat repositorioita niiden kehittäjien henkilökohtaisille tileille, joiden tokenit ne varastivat, joten pyydä kehittäjiäsi tarkistamaan omansa.

Miksi lukitustiedosto ei ratkaise asiaa

Tavallinen neuvo on hakea kyseisiä versioita tiedostoista package-lock.json, yarn.lock tai pnpm-lock.yaml. Tee se ensin, mutta puhdas lukitustiedosto ei todista buildin olevan puhdas:

• Lukitustiedoston ulkopuolella asennetut paketit. npx some-tool asentaa npm-välimuistiin paketin, joka ei ole projektin riippuvuus. npm install -g valmisteluvaiheessa, build-skriptin sisällä asennettu työkalu ja npm install Dockerfilessa ohittavat kaikki projektin lukitustiedoston.
• Haaran tämänpäiväinen lukitustiedosto ei ole se, joka ajettiin. Kolme viikkoa sitten ajettu buildi käytti sitä, mitä lukitustiedostossa silloin luki, siinä haarassa, joka sen käynnisti. Riippuvuuksien päivitys-pull requestit ajavat CI:n uusia versioita vasten ennen kuin kukaan katselmoi niitä.
• Välimuistit palauttavat sen, mitä aiemmin asennettiin. Palautettu node_modules tai npm-välimuisti voi sisältää version, jota nykyinen lukitustiedosto ei enää mainitse.
• npm ci asentaa sen, mitä lukitustiedostossa lukee. Jos saastunut versio oli jo lukittu, tiukka asennus asentaa sen uskollisesti.
• Oikein julkaistu versio voi silti olla haitallinen. TanStack ja Miasma vaarannettiin niiden omien julkaisutyönkulkujen kautta, ja Miasman saastuneilla versioilla oli pätevät alkuperätiedot. Sen tarkistaminen, että versio on julkaistu asianmukaisesti, ei kerro, että se on puhdas.

Todellisuudessa tarvitset tallenteen siitä, mitkä pakettiversiot kukin buildi haki, kaikissa repositorioissa ja kaikissa haaroissa, koko sen ajan, kun saastunut versio oli rekisterissä. Katso koskeeko tämä meitä? Näin arvioit uuden CVE:n kaikissa buildeissasi.

Miten korjaat sen, ja mitä tehdä, jos et voi vielä paikata

1. Jos jokin buildi asensi kyseisen version, käsittele jobia vaarantuneena. Vaihda jokainen salaisuus, jonka se pystyi lukemaan: npm-tokenit, GitHub-tokenit, pilvitunnukset ja käyttöönottoavaimet. Koska myöhemmät aallot julkaisivat varastettuja salaisuuksia muiden uhrien tileille, älä oleta olevasi turvassa sen vuoksi, ettei omalle tilillesi ilmestynyt mitään.
2. Tyhjennä välimuistit. Poista GitHub Actions -välimuistit ja npm-välimuisti kehittäjien koneilta ja itse ylläpidetyiltä runnereilta, jotta seuraava buildi asentaa puhtaat versiot:

gh cache delete --all --repo ORG/REPO   # GitHub Actions caches, per repository
npm cache clean --force
rm -rf node_modules "$(pnpm store path)"   # pnpm; for Yarn: yarn cache clean

3. Kiinnitä puhtaaseen versioon ja poista työnkulut, repositoriot, runnerit ja konfiguraatiotiedostot, jotka mato lisäsi.

Varmista siivous

1. Jokainen lukitustiedosto ratkeaa puhtaisiin versioihin. Jokaisessa haarassa npm ls <package> (tai pnpm why tai yarn why) näyttää asennetun version; mikään niistä ei saa olla aallon luettelossa.
2. Puhdas asennus ei sisällä hyötykuormatiedostoja. Asenna yllä kuvatun välimuistin tyhjennyksen jälkeen uudelleen ja etsi tietoturvatiedotteissa mainittuja hyötykuormatiedostoja:

find node_modules -name bundle.js -size +3M \
  -o -name setup_bun.js -o -name bun_environment.js -o -name router_init.js

3. Vanhat tunnukset eivät enää toimi. Mitätöidyt npm-tokenit ovat poissa npm token list -luettelosta, vanhat GitHub-tokenit ja käyttöönottoavaimet on poistettu, ja pilviavaimet on poistettu käytöstä eikä vain korvattu.
4. Välimuistit ovat poissa. gh cache list ei näytä missään kyseisessä repositoriossa yhtään ennen siivousta luotua välimuistia.
5. Mitään madon lisäämää ei ole jäljellä: ei repositorioita, työnkulkutiedostoja, itse ylläpidettyjä runnereita eikä editorien tai tekoälyavustajien konfiguraatiotiedostoja, joita et ole luonut.
6. Seuraava buildi on puhdas. Tarkista versiot, jotka se todella asensi, sen lokista tai buildikohtaisesta SBOM:sta, ei pelkästä lukitustiedostosta.

Miten vähennät vahinkoja ensi kerralla

• Poista asennusskriptit käytöstä, missä voit. Heinäkuussa 2026 julkaistu npm v12 poistaa asennusskriptit oletuksena käytöstä ja antaa sallia ne pakettikohtaisesti. pnpm ja Yarn tarjoavat vastaavia kontrolleja.
• Odota ennen uusien versioiden käyttöönottoa. Useimmat saastuneet versiot löydetään ja poistetaan tuntien tai päivien kuluessa. Riippuvuuspäivitysten odotusaika (cooldown), jota sekä Dependabot että Renovate tukevat, pitää ne poissa buildeistasi. GitHubin package firewall, joka on ollut julkisena esiversiona GitHub Enterprise Cloudissa 20.10.2026 alkaen, tarkistaa npm-asennukset haitallisten pakettien varalta ja tarjoaa myös odotusajat.
• Julkaise trusted publishingilla ja lyhytikäisillä tokeneilla. npm mitätöi kaikki klassiset tokenit joulukuussa 2025. Käytä CI:stä OIDC-pohjaista trusted publishingia pitkäikäisten tokenien sijaan, ja pidä julkaisutyönkulut erillään build- ja testityönkuluista.
• Kovenna työnkulut, joita mato käyttää hyväkseen. Vältä pull_request_target-laukaisinta, kiinnitä actionit commit-SHA:ihin ja anna GITHUB_TOKEN-tokenille vain ne oikeudet, joita kukin jobi tarvitsee. Katso GitHub Actionsin salaisuudet: miten ne vuotavat ja miten ne suojataan.
• Rajoita, mihin buildit voivat ottaa yhteyttä. Buildi tarvitsee pakettirekisterinsä ja muutaman API:n. Jos se ylettyy vain niihin, madon kutsut osoitteeseen webhook.site tai sen omille palvelimille epäonnistuvat. Katso miten egress-käytäntö pysäyttää tietojen vuotamisen GitHub Actionsista. Tämä ei estä tietojen vuotamista sellaisen palvelimen kautta, jota buildi käyttää oikeutetusti, kuten GitHubin oman API:n, johon jotkin aallot nojasivat.

Tarkista vaarantuminen

Shai-Hulud on tarkoituksella haitallinen: jokainen kone tai jobi, joka asensi saastuneen version, ajoi sen. Tunnusmerkit vaihtelevat aalloittain, joten käytä tarkistamasi aallon tietoturvatiedotetta. Ensisijaisista lähteistä:

Aalto	Tunnusmerkit	Lähde
Syyskuu 2025	Hyötykuorma bundle.js, SHA-256 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09; työnkulku .github/workflows/shai-hulud-workflow.yml haarassa shai-hulud; julkinen repositorio nimeltä Shai-Hulud; yhteydet osoitteeseen webhook.site	StepSecurity, CISA
Marraskuu 2025	setup_bun.js, SHA-1 d1829b4708126dcc7bea7437c04d1f10eacd4a16; bun_environment.js, SHA-1 d60ec97eea19fffb4809bc35b91033b52490ca11 tai 3d7570d14d34b0ba137d502f042b27b0f37a59fa; repositoriot, joissa on cloud.json, contents.json, environment.json, truffleSecrets.json ja actionsSecrets.json; työnkulut .github/workflows/discussion.yaml ja formatter_*.yml; itse ylläpidetty runneri nimeltä SHA1HULUD	Wiz
Toukokuu 2026, TanStack	"@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c" kohdassa optionalDependencies; hyötykuorma router_init.js (noin 2,3 Mt) paketin juuressa; apuskripti tanstack_runner.js; yhteydet osoitteisiin filev2.getsession.org ja seed1.getsession.org–seed3.getsession.org sekä toisen vaiheen lataukset osoitteesta litter.catbox.moe	GHSA-g7cv-rxg3-hmpx

Myöhemmät aallot muuttivat hyötykuormaa tartunnoittain, joten tiiviste, joka ei täsmää, ei todista mitään; vertaa ensin pakettiversioita.

Milloin olettaa vaarantuminen. Käsittele jokaista konetta ja CI-jobia, joka asensi kyseisen version, vaarantuneena, vaikka asennus epäonnistui tai ei jättänyt mitään hakemistoon node_modules. GitHubin TanStack-tiedotteen mukaan jokaista kehittäjä- tai CI-ympäristöä, joka asensi kyseisen version, ”tulee pitää vaarantuneena”. Tarkista saastuneen version ensimmäisestä julkaisusta alkaen, älä siitä päivästä, jona aalto julkistettiin.

Vaihda tunnukset. Vaihda kaikki, mihin asennus pystyi ulottumaan. TanStack-aallossa se tarkoitti jälkianalyysin mukaan AWS-, GCP-, Kubernetes-, Vault-, GitHub-, npm- ja SSH-tunnuksia. Käy läpi pilven audit-lokit kyseisten koneiden toiminnan osalta asennusikkunan aikana ja sen jälkeen.

Tyhjennä välimuistit ja artefaktit. Hae artefaktirepositorioista ja riippuvuusvälityspalvelimista kyseisten versioiden välimuistiin tallennettuja kopioita ja poista ne, kuten CISA neuvoo. Poista node_modules, npm-välimuisti ja CI-välimuistit; TanStack-aallossa hyökkääjä pääsi sisään myrkytetyn pnpm store -välimuistin kautta, joten tarkista Actions-välimuistit pakettivälimuistien lisäksi. Rakenna ja julkaise uudelleen kaikki, mitä vaarantunut jobi tuotti.

Mitä kertoa asiakkaillesi

Jos toimitat npm:llä rakennettuja ohjelmistoja, asiakkaat kysyvät, sisältääkö tuotteesi madon tai onko julkaisuputkesi vaarantunut. Vastaa kertomalla, mitä tarkistit ja mitä teit:

Tarkistimme jokaisen [tuote]-buildin ajalta [päivämäärä]–[päivämäärä] Shai-Hululla saastuneiden npm-pakettiversioiden julkaistuja luetteloita vasten. [Yksikään buildi ei asentanut kyseistä versiota.] / [[Komponentti]-buildit [päivämäärä] asensivat paketin [package@version]; vaihdoimme tunnukset, joihin näillä buildeilla oli pääsy, rakensimme [tuote]-tuotteen uudelleen puhtaista riippuvuuksista ja julkaisimme version [versio]. Julkaisut [x–y] ovat haavoittuvia; päivitä versioon [versio].] Päivitämme tätä tiedotetta, jos uudet aallot muuttavat tilannetta.

Jos tarkistus on vielä kesken, kerro se ja kerro, milloin vastaat. Ensimmäisen alustavan tiedotteen ja pohjat kuhunkin lopputulokseen löydät sivulta miten vastata asiakkaille toimitusketjuhyökkäyksen jälkeen.

Miten CRACI auttaa

CRACI ajaa GitHub Actions -jobisi omilla runnereillaan (runs-on: craci) ja tallentaa jokaisen paketin, jonka kukin jobi todella hakee npm:stä ja muista rekistereistä, myös välimuisteista palautetut paketit. Tallenne kattaa yllä kuvatut sokeat pisteet: npx-työkalut, globaalit asennukset ja build-skriptien sisäiset asennukset näkyvät kaikki, koska tallenne syntyy siitä, mitä jobi latasi, eikä siitä, mitä lukitustiedostossa ilmoitettiin. Kun uusi aalto julkistetaan, haet kyseiset versiot CRACI:n tallentamista buildeista sen sijaan, että kokoaisit ne lukitustiedostoista ja lokeista, ja kunkin jobin verkkoliikenteen jäljet näyttävät, mihin se otti yhteyttä. Buildihistoria säilyttää jokaisen aiemman buildin SBOM:ineen, joten näet, mitkä buildit sisälsivät saastuneen version ja minkä aikaikkunan olit altistuneena, säilytysaikasi rajoissa.

CRACI:n egress-käytäntö rajoittaa, mihin jobi voi ottaa yhteyttä, validoidaan ennen jobin käynnistymistä ja noudattaa fail closed -periaatetta: virhetilanteessa liikenne estetään. Se myös hälyttää, kun jobi yrittää tavoittaa kohteen, jota käytäntö ei salli. Saastuneet julkaisut, joille on julkaistu CVE, kuten TanStack-aalto, merkitään kuten mikä tahansa muu haavoittuvuus, ja käytäntöportit voivat estää buildit, jotka sisältävät niitä. CRACI ei pisteytä paketteja haitallisen käyttäytymisen perusteella eikä merkitse uutta saastunutta versiota ennen kuin siitä on tietoturvatiedote; yhdistä se pakettien maineen arviointityökaluun, jos haluat saastuneet versiot estettäviksi ennen asennusta.

Katso yhden oman buildisi pakettitallenne

Muut tapaukset: kaikki haavoittuvuudet.

Lähteet ja päivitykset

Ensisijaiset lähteet ja alkuperäinen tutkimus:

• CISA: varoitus 23.9.2025, KEV-luettelo
• GitHub: GHSA-g7cv-rxg3-hmpx (CVE-2026-45321), suunnitelmamme turvallisemmasta npm-toimitusketjusta, npm:n klassiset tokenit mitätöity
• TanStackin jälkianalyysi
• Wiz marraskuun 2025 aallosta ja sen jälkiseurauksista
• Microsoft AntV:stä ja Microsoftin tunnistusohjeet
• Datadog ja Elastic CHAINDROPista
• StepSecurity syyskuun 2025 aallosta
• FIRST: CVE-2026-45321:n EPSS-pisteet

Päivitykset:

• 2026-11-11: Lisätty tietolaatikkoon EPSS, CWE-luokka ja kiitokset, kopioitavat tarkistukset sekä osiot madon toiminnasta, siivouksen varmistamisesta ja vaarantumisen tarkistamisesta aaltokohtaisine tunnusmerkkeineen.
• 2026-11-11: Siirretty blogista haavoittuvuusosioon. Lisätty 8.10.2026 tensorlake-aalto, syyskuun 2026 paluun päivämäärä, CVE-2026-45321 ja sen KEV-merkintä TanStack-aallolle sekä GitHubin package firewall.
• 2026-09-25: Julkaistu ensimmäisen kerran CRACI:n blogissa.