Er is een nieuwe supply-chain dreiging opgedoken die raakt aan ontwikkelomgevingen: gecompromitteerde MemTensor pakketten zijn via npm en PyPI voorzien van een kwaadaardige Go-implant (genaamd sckit). Meerdere onderzoekers melden dat deze implant bedoeld is om op verschillende platformen (Windows, Linux en macOS) credentials te verzamelen en door te sturen.
Wat dit extra vervelend maakt, is dat het om aangepaste versies gaat van legitieme bibliotheken. In veel organisaties draaien diezelfde pakketten in CI/CD, op developer workstations en zelfs in geautomatiseerde publicatieflows—waardoor gestolen tokens direct waardevol zijn voor verdere aanvallen.
Welke MemTensor pakketten zijn geraakt?
Volgens meldingen van onder meer Aikido, SafeDep, Socket en StepSecurity zijn specifieke versies van MemTensor libraries gemanipuleerd.
- npm: @memtensor/memos-cloud-openclaw-plugin versies 0.1.21, 0.1.23 en 0.1.25 (versies 0.1.22 en 0.1.24 zijn schoon).
- PyPI: MemoryOS versie 2.0.34 (project is op dit moment gequarantineerd op PyPI).
De aanvallers hebben dus niet het hele project “omgedraaid”, maar gekozen versies aangepast. Dat maakt het des te belangrijker om precies te controleren wat er in jouw builds, containers en lockfiles staat.
Hoe werkt de sckit-implant?
De kern van de aanval is een platform-specifieke, Go-based implant: sckit. De manier van starten verschilt per ecosysteem, maar het doel blijft hetzelfde: credentials verzamelen en vervolgens exfiltreren.
Bij npm zit de kwaadaardige payload verborgen in een legitieme AI memory-integratie. De implant kan starten wanneer een agent gateway opkomt en opnieuw wanneer de plugin een zogenoemde “memory-recall” afhandelt. Daarbij wordt onder andere de omgeving van het hostproces doorgegeven. Tijdens recall wordt bovendien de prompttekst van de gebruiker direct doorgegeven aan de kwaadaardige executable.
Bij PyPI start de implant zodra een toepassing het betreffende memos-module importeert. Vervolgens wordt een statisch gecompileerde Go-binary uitgevoerd.
Welke gegevens wil sckit stelen?
De aanvallers mikken op waardevolle secrets die vaak in dezelfde software- en ontwikkelketen aanwezig zijn. Onderzoekers beschrijven dat sckit zich richt op een combinatie van credentialbestanden en omgevingsvariabelen die tokens, wachtwoorden en sleutels bevatten.
Voorbeelden van gestolen credentialbestanden die genoemd worden:
- .npmrc
- .vault-token
- id_ecdsa
- credentials.db
- access_tokens.json
- stored_tokens
Daarnaast zoekt sckit naar omgevingsvariabelen met daarin secrets, zoals tokens, wachtwoorden, API keys, private keys, session cookies en verbindingsstrings voor database of message brokers. In de meldingen komen namen terug als NPM_TOKEN en PYPI_API_TOKEN—typen gegevens die in CI-systemen juist vaak worden gebruikt.
Ook platforms en systemen die als doel worden genoemd omvatten onder meer GitHub, GitLab, AWS, Vault en SSH-gerelateerde geheimen. Verder gaat het om sleutels voor diensten en tooling zoals Hugging Face, HashiCorp Vault, Slack, Stripe en SendGrid, plus JWT’s.
Exfiltratie via een extern domein
Uit de technische analyse blijkt dat de verzamelde data naar een externe server wordt gestuurd op een domein dat in de meldingen terugkomt als skyleen[.]fr (inclusief subdomeinen). Omdat de implant nog steeds te downloaden is in de getroffen versies, is het blokkeren van dat domein een praktische stap om verdere datalekken te beperken.
Hoe konden de aanvallers publicatie-tokens bemachtigen?
SafeDep beschrijft dat de aanvallers publicatie-tokens hebben verkregen uit de eigen GitHub Actions release pipelines van MemTensor. Dat gebeurde door commits te plaatsen die ervoor zorgden dat de workflow de npm– of PyPI-token zou afgeven aan de aanvaller.
Daarmee ontstaat een gevaarlijk scenario: niet alleen wordt het pakket zelf aangepast, maar de aanvaller kan mogelijk ook vervolgbesmettingen organiseren via dezelfde publicatieketen.
Potentieel “worm-achtig” doorpakken
Verder lijkt de implant de mogelijkheid te hebben om zich te verspreiden door te publiceren via GitHub en door packages opnieuw op npm en PyPI te publiceren. In de meldingen is aangegeven dat het implantatiegedrag zou kunnen aansluiten op GitHub- en packaging-workflows.
Het is op het moment van de rapportage niet duidelijk of er ook andere niet-MemTensor packages zijn getroffen. Toch is de observatie belangrijk: als een aanvaller toegang krijgt tot publicatietokens, kan de impact in korte tijd toenemen.
Wat je nu kunt doen (concreet en actiegericht)
Omdat de gemanipuleerde versies nog beschikbaar kunnen zijn voor download, is het verstandig om nu gericht te handelen. Hieronder staan de belangrijkste maatregelen die in de meldingen worden genoemd, plus waarom ze zinvol zijn in een echte beheerpraktijk.
- Pin pakketten naar een veilige baseline: voor npm wordt genoemd om terug te gaan naar 0.1.20. Voor PyPI wordt genoemd om uit te wijken naar 2.0.33.
- Roteer blootgestelde secrets: draai tokens en sleutels die in CI/CD of op werkstations kunnen zijn gebruikt terug. Denk aan npm/PyPI tokens en andere integratie-credentials.
- Stop en beëindig actieve sckit-processen: op systemen waar de malware kan draaien, is het zaak de processen te beëindigen en opnieuw een schoon baseline te draaien.
- Blokkeer exfiltratie-domeinen: blokkeer skyleen[.]fr en alle subdomeinen in egress filtering en (waar mogelijk) in je netwerkbewaking.
Als je werkt met automatisering: zorg dat je CI jobs met tokens niet langer kunnen draaien met getroffen afhankelijkheden. Het “even één build overslaan” is vaak onvoldoende als lockfiles al besmet zijn of als meerdere services dezelfde dependency gebruiken.
Waarom dit ook buiten MemTensor impact kan hebben
De aanval richt zich op de typische waarde die in moderne softwareketens aanwezig is: credentials die nodig zijn om te deployen, publiceren en integreren. Dat betekent dat het pakket zelf niet per se het enige risico is. Als een gecompromitteerde dependency draait in een omgeving met uitgegeven tokens, kan de schade zich uitbreiden naar andere domeinen zoals pakketregistraties, bronplatformen en cloudservices.
Dit past in een bredere trend waarbij supply-chain aanvallen vooral slagen als ze goed aansluiten op ontwikkelprocessen—denk aan bots die workflows activeren, of inloggegevens die automatisch worden geïnjecteerd in CI.
Extra context: supply-chain aanvallen en AI-ecosystemen
Als je wilt zien hoe dit soort dreiging ook in andere contexten speelt, kan het nuttig zijn om vergelijkbare patronen te bekijken. Zo beschrijft onze site eerder hoe AI-modellen minder vaak in de fout gaan—maar dat staat los van het kernprobleem hier: de keten rondom tooling en dependencies kan al misleid worden voordat AI ooit relevant wordt.
Ook eerder volgden we berichten over verdachte pakketgedragingen in het ontwikkelecosysteem, bijvoorbeeld bij een malafide npm-pakket als Twilio probe. De gemeenschappelijke les is dat je niet alleen naar “wat een library doet” moet kijken, maar ook welke versie je gebruikt en waar die versie vandaan komt.
Conclusie
Gecompromitteerde MemTensor pakketten op npm en PyPI laten zien hoe snel een supply-chain aanval waardevol wordt zodra ontwikkelomgevingen betrokken raken. De sckit-implant kan op meerdere besturingssystemen starten, zoekt naar een breed scala aan secrets en probeert die data naar een extern domein te exfiltreren.
Door getroffen versies te vervangen door de genoemde veilige baselines, tokens te roteren, verdachte processen te beëindigen en uitgaande communicatie te blokkeren, verklein je de kans op echte credential-diefstal. Controleer daarna proactief je dependencies in zowel development als CI/CD, zodat herhaling minder waarschijnlijk wordt.
Bron: https://thehackernews.com/2026/09/compromised-memtensor-packages-deliver.html
