Mini Shai-Hulud tabas Mistrali ja TanStacki: usaldatud build’id ei taga enam turvalisust

Open-source ökosüsteemis toimus uus tarneahela intsident: pahatahtlikud versioonid jõudsid kümnetesse populaarsetesse TanStacki pakettidesse ning laine puudutas seejärel Mistral AI SDK-d, OpenSearchi, UiPathi ja teisi projekte. Teadlased seostavad rünnakut Mini Shai-Huludi kampaaniaga — isepaljuneva pahavaraga, mis varastab arendajate ja CI keskkondadest mandaate ning üritab seejärel juba kompromiteeritud omaniku nimel uusi pakette nakatada.

Esmapilgul on see järjekordne lugu teemal „ärge paigaldage värskeid sõltuvusi pimesi“. Kuid siin on tähtsam muu: osa pahatahtlikest avaldamistest nägi vormiliselt usaldusväärne välja. Need läbisid ametliku OIDC trusted publishing mehhanismi ning mõnes analüüsis rõhutatakse, et pakettidel võisid olla kehtivad provenance-attestatsioonid. Seega pole õppetund ainult selles, et keegi varastas npm-i parooli, vaid selles, et ründaja õppis kasutama usaldust CI vastu nakkuse transpordina.

Mis juhtus

TanStack kirjutab oma postmortem’is, et 11. mail 2026 avaldas ründaja ajavahemikus 19:20–19:26 UTC 84 pahatahtlikku versiooni 42 @tanstack/* paketis. Mõjutatud olid muu hulgas router-paketid, sealhulgas laialt kasutatav @tanstack/react-router. Socketi andmetel on mõnel neist miljoneid allalaadimisi nädalas, mistõttu ei jäänud intsident ühe projekti lokaalseks mureks, vaid muutus ohuks suurele hulgale rakendustele ja CI-süsteemidele.

Hiljem leidsid teadlased sarnase nakkuse teistes pakettides, sealhulgas @mistralai/mistralai ja seotud SDK-des. Techmeme tõstis loo esile sõnastusega, et kompromiteeritud olid paljud npm-paketid Mistrali, UiPathi ja TanStacki jaoks ning Microsoft uurib Mistral AI PyPI-paketi versiooni 2.4.6 kompromiteerimist. Avaldamise hetkel on tegu kiiresti areneva intsidendiga, seega tuleb täpset mõjutatud pakettide nimekirja kontrollida advisory’de ja turvabaaside, mitte ühe sotsiaalmeedia ekraanipildi järgi.

TanStack ütleb, et kõik teadaolevad pahatahtlikud versioonid märgiti deprecated’iks, npm security kaasati tarball-failide eemaldamiseks, GitHub Actionsi vahemälud puhastati ja workflow’d tugevdati. Kuid kui nakatunud pakett oli juba arendaja masinasse või CI-sse paigaldatud, ei lahenda lihtne npm update probleemi: sellist hosti tuleb pidada potentsiaalselt kompromiteerituks.

Kuidas rünnak töötas

Skeem on ebameeldiv just seetõttu, et see tabab harjumuspäraseid „õigeid“ praktikaid. TanStacki versiooni järgi kasutas ründaja kolme elementi: ohtlikku pull_request_target mustrit, GitHub Actionsi cache poisoning’ut ja OIDC-tokeni väljavõtmist runner-protsessi mälust legitiimse workflow ajal.

Lihtsustatult näeb see välja nii. Repositooriumisse ilmub pull request fork’ist. Osa workflow’st käivitub põhirepositooriumi kontekstis, kuid täidab samal ajal välise PR-i koodi. See kood mürgitab dependency cache’i nii, et järgmise release’i ajal taastab ametlik CI juba nakatunud sisu. Seejärel saab pahatahtlik kood legitiimse workflow käigus ligipääsu lühiealisele OIDC-tokenile ja avaldab paketid otse npm registry’sse.

Oluline detail: TanStacki sõnul npm-tokeneid ei varastatud ning workflow avaldamissamm ei pidanud isegi edukalt lõpuni minema. Avaldamine toimus, sest trusted publisher taristu võttis vastu päringu, mis tuli lubatud CI-kontekstist. Välisele vaatlejale ei paista see enam jämeda paroolivargusena; see näeb välja nagu legitiimne automatiseerimine, mis sunniti tegema võõrast tööd.

Miks see puudutab mitte ainult arendajaid

Tänapäeva tarkvara koosneb tuhandetest sõltuvustest. Isegi kui kasutaja pole TanStackist või Mistral SDK-st kunagi kuulnud, võib ta kasutada toodet, mis toob sellised teegid kaasa transitiivselt. Seetõttu pole tarneahela rünnakud GitHubi-tiimide sisemine draama, vaid kogu digitaalse kihi vastupidavuse küsimus: pangateenused, SaaS-rakendused, ettevõttepaneelid, meditsiinisüsteemid ja tavalised veebilehed.

AI-ajastu võimendab probleemi. Arendajad ühendavad üha rohkem mudelite SDK-sid, agentseid raamistikke, automatiseerimispluginaid, vektorandmebaaside teeke ja koodigeneratsiooni tööriistu. Paljud neist paigaldatakse kiiresti, uuenevad sageli ja elavad CI sees, kus asuvad võtmed pilvedesse, repositooriumidesse, konteineriregistritesse ja production-taristusse. Pahatahtlik sõltuvus sellises kohas ei saa mitte lihtsalt programmeerija sülearvutit, vaid peaaegu ligipääsukaardi tarkvaratehasesse.

Seetõttu pole Mini Shai-Huludi loos kõige tähtsam bränd Mistral või TanStack, vaid haavatavuse klass. Kui ründaja oskab muuta usaldatud build-süsteemi pahatahtliku paketi avaldajaks, peab turg ümber hindama, mida „ametlik“ tarne üldse tähendab.

Provenance ei osutunud hõbekuuliks

Viimastel aastatel on tööstus pakkunud SLSA-d, Sigstore’i, OIDC trusted publishing’ut ja provenance’i vastuseks tokenite kaosele ja võltspakettidele. Need on tõesti kasulikud mehhanismid: nad vähendavad varastatud pikaealiste saladuste riski ja võimaldavad kontrollida, kust artefakt tuli. Kuid see intsident näitab lubaduse piiri.

Provenance võib kinnitada, et pakett ehitati ja avaldati teatud workflow’ga teatud repositooriumis. See ei tõesta, et build’i hetkel ei taastanud workflow mürgitatud cache’i, ei täitnud võõrast koodi ega andnud ründajale ajutist tokenit. Teisisõnu vastab allkiri küsimusele „milline masin selle välja lasi“, kuid mitte alati küsimusele „kas masin ise oli turvaline“.

See on valus, kuid kasulik õppetund. Usaldatud build ei ole lõplik kvaliteeditempel, vaid üks kaitsekiht. Kui selle ümber jäävad ohtlikud PR-workflow’d, ühised cache’id ebausaldusväärse ja release-koodi vahel, runner’ite laiad õigused ja pakettide automaatsed lifecycle-skriptid, leiab ründaja ikkagi pilu.

Mida ettevõtted peaksid kohe tegema

Esimene praktiline samm on kontrollida, kas mõjutatud versioone paigaldati 11. mail või hiljem. TanStack viitab konkreetsele advisory’le ja tracking issue’le; Socket, Snyk, StepSecurity ja teised avaldavad kompromiteerimise indikaatoreid ja paketinimekirju. Kui selline pakett paigaldati arendaja masinasse või CI-sse, on turvaline hoiak karm: keskkond kompromiteerituks lugeda ja ligipääsetavad saladused roteerida.

Teine samm on CI üle vaadata. Workflow’d, mis kasutavad pull_request_target ja samal ajal täidavad fork’ist tulnud koodi, peavad minema punasesse tsooni. Ebausaldusväärsete PR-ide ja release-protsesside vahelisi cache’e ei saa pidada neutraalseks build’i kiirendajaks. OIDC-õigused peavad olema minimaalsed ja väljastatud ainult neile job’idele, kus avaldamine on päriselt vajalik, mitte kogu pipeline’ile „igaks juhuks“.

Kolmas samm on vähem usaldada sõltuvuste lifecycle-skripte. prepare, postinstall ja sarnased mehhanismid on mugavad, kuid muudavad paketi paigaldamise suvalise koodi käivitamiseks. CI ja production-build’ide jaoks on üha rohkem vaja režiimi, kus sõltuvusi kontrollitakse esmalt artefaktidena ja alles seejärel antakse neile õigus midagi käivitada.

Peamine järeldus

Mini Shai-Hulud pole lihtsalt järjekordne supply-chain intsident. See on uue ründetaseme demonstratsioon: pahatahtlik pakett võib tulla mitte npm-i pimedast nurgast, vaid projekti ametliku taristu kaudu, lühiealiste tokenite, automaatsete build’ide ja väliselt korraliku päritolulooga.

Tavalise lugeja jaoks on mõte lihtne: digimaailma turvalisus meenutab üha vähem lukku uksel ja üha rohkem kogu tehase kontrolli, kus see uks valmis tehakse. Kui tehas on automatiseeritud, pilvedega ühendatud ja AI-tööriistadega kiirendatud, võib üks viga workflow usaldamises muutuda probleemiks tuhandetele ettevõtetele.

Arendajate ja CTO-de jaoks on järeldus veel otsesem: CI/CD-d tuleb käsitleda kriitilise taristuna, mitte igava .github/workflows kaustana. Agentse koodi ja kiirete sõltuvuste ajastul pole küsimus enam „kas saame paketi allkirjastada“, vaid „kas suudame tõestada, et kogu tee allkirjani ei olnud nakatunud“.