MemTensor-pakker på npm og PyPI kapret: sckit stjeler nøkler fra agentmiljøet
Lås @memtensor/memos-cloud-openclaw-plugin til 0.1.20 og MemoryOS til 2.0.33, og roter alle nøkler i hjemmekatalogen hvis du installerte en av de kaprede versjonene 23. september.
Ifølge sikkerhetsselskapet SafeDep publiserte en angriper 23. september ondsinnede versjoner av to pakker fra MemTensor, selskapet bak minnelaget MemOS: OpenClaw-pluginen @memtensor/memos-cloud-openclaw-plugin i versjon 0.1.21, 0.1.23 og 0.1.25 på npm, og Python-biblioteket MemoryOS i versjon 2.0.34 på PyPI. Begge inneholder den samme Go-binæren, kalt sckit, bygget for Windows, Linux og macOS. Den leter etter hemmeligheter under hjemmekatalogen og sender dem til servere under domenet skyleen[.]fr. Da SafeDep samlet inn data, var 0.1.25 merket som latest på npm og 2.0.34 den nyeste versjonen på PyPI, så en helt vanlig installasjon hentet bakdøren.
Målet er valgt med omhu. Pluginen kobler agent-runtimen OpenClaw til en minnetjeneste: den henter relevante minner før agenten behandler en prompt og lagrer nye etter kjøringen. StepSecurity, som også har analysert angrepet, peker på hva det betyr:
«Dette plasserer pluginen inne i en prosess som rutinemessig håndterer brukerinput og kan arve verdifulle nøkler.» — StepSecurity
npm-versjonene har ingen install-skript. Binæren startes når OpenClaw-gatewayen starter og på nytt ved hver minnehenting, og får med seg hele miljøet til prosessen. Ved minnehenting sendes også brukerens prompt til binæren, men StepSecurity understreker at det ikke er påvist at promptene faktisk sendes ut. MemoryOS starter binæren første gang biblioteket setter opp logging, noe nesten alle importstier gjør. Derfor hjelper ikke --ignore-scripts.
Innbruddet gikk via MemTensors egne release-pipelines i GitHub Actions. Kontoen Memtensor-AI pushet en kortlivet sc/release-*-gren fem ganger mellom 00:48 og 02:03 UTC. Endringen fikk et valideringsskript tidlig i jobben til å skrive en BASH_ENV-oppføring til $GITHUB_ENV, slik at angriperens skript kjørte før selve publiseringssteget og ga npm-tokenet videre. Første ondsinnede versjon kom 20 minutter etter siste push. For PyPI ble taggen v2.0.34 slettet og gjenskapt på en usignert commit utenfor main. SafeDep vet ikke hvordan angriperen fikk push-tilgang, men mener et stjålet token for kontoen er den mest sannsynlige forklaringen.
Binæren kan også spre seg videre. Den inneholder maler for å installere seg selv i npm-pakker, Python-pakker og GitHub Actions-workflows som de stjålne nøklene gir tilgang til.
«Den samler inn nøkler fra utviklermaskiner og fra CI-jobber.» — SafeDep, gjengitt av The Hacker News
SafeDep fant ingen andre berørte pakker, men skriver at lista kan vokse fordi ormen sprer seg. For deg som kjører agenter lokalt er poenget ubehagelig konkret: minne- og verktøy-plugins lever i den prosessen som har flest nøkler og ser alle promptene dine.
Hva bør du gjøre?
- Søk gjennom package-lock.json og Python-miljøene dine etter versjon 0.1.21, 0.1.23, 0.1.25 og 2.0.34, og lås til 0.1.20 og 2.0.33.
- Drep alle sckit-prosesser, blokker skyleen[.]fr med alle subdomener, og roter npm-, PyPI-, GitHub-, GitLab-, SSH-, AWS- og Vault-nøkler som lå tilgjengelig under hjemmekatalogen.
- Gå gjennom egne release-workflows: kan et tidligere steg i samme jobb skrive til
$GITHUB_ENVfør publiseringen, kan det samme skje hos deg. Legg publiseringen i en egen jobb uten lagrede tokens der det er mulig.
KI-kuratert — innholdet er generert av KI-agenter basert på originalkilden.