An attacker quietly pushed malicious versions of two legitimate MemTensor packages onto npm and PyPI, and anyone who installed the wrong version handed over their cloud keys, registry tokens, source-code access, and developer secrets. The payload is a Go-based stealer called sckit, and the ugly part is that it behaves like a worm: it carries the templates to reinstall itself into other npm packages, Python packages, and GitHub Actions workflows. This is not “a bad package got published.” This is a supply chain attack that tries to keep spreading through whoever it lands on.
We deal with the fallout of compromised developer machines and deployment pipelines regularly, and this one is worth understanding in detail because the delivery method, stealing a project’s own publishing tokens, is becoming the standard playbook. If your site’s build or deploy touches npm or PyPI, read the indicators below and check yourself today.
What got compromised
Two real MemTensor libraries were poisoned across both ecosystems. The specific versions matter, because not every release is malicious:
- npm:
@memtensor/memos-cloud-openclaw-pluginversions 0.1.21, 0.1.23, and 0.1.25 are malicious. Versions 0.1.22 and 0.1.24 are clean. Note the pattern: the attacker interleaved bad and clean releases, which is a deliberate way to slip past anyone who assumes “the latest version is fine.” - PyPI: MemoryOS version 2.0.34. The project is currently quarantined on PyPI.
The npm package is a MemOS Cloud plugin that connects the OpenClaw agent runtime to a memory service, and it declares integration points for the Clawdbot and Moltbot runtimes too. On npm, the hidden Go payload fires when the agent gateway starts and again every time the plugin handles a memory-recall event. Worse, the launcher passes the host process environment and, during recall, the user’s actual prompt text straight to the malicious binary. On the PyPI side it is even more direct: the statically linked Go binary launches the moment the memos module is imported into an application. No special trigger, just import and you are running it.
What sckit steals
Once running, sckit is a cross-platform credential harvester built for Windows, Linux, and macOS. It goes after exactly the things a developer or a CI job tends to have lying around, and ships them to an external server at skyleen[.]fr. Per the researchers who analyzed it, the targets include:
- Credential files:
.npmrc,.vault-token,id_ecdsa,credentials.db,access_tokens.json, andstored_tokens. - Environment variables that signal secrets: anything pointing to tokens, passwords, API keys, private keys, session cookies, and database or message-broker connection strings, including
NPM_TOKENandPYPI_API_TOKEN. - Named credentials: AWS access keys, GitHub and GitLab tokens, npm and PyPI tokens, plus Hugging Face, HashiCorp Vault, Slack, Stripe, and SendGrid keys, and JWTs.
Read that list as a whole and the intent is obvious. This is not opportunistic browser-cookie theft. It is a targeted sweep of the exact keys that let you publish packages, push code, and reach cloud infrastructure. Those are the keys that turn one infected laptop into a breach of everything that laptop can deploy to.
How the attacker got in: the project’s own release pipeline
This is the detail every team should sit with. The attacker did not phish a maintainer’s password. According to the supply chain analysis, they obtained MemTensor’s publish tokens straight from the project’s own GitHub Actions release pipelines, by pushing commits that caused the workflow to hand over the npm or PyPI token.
In other words, the CI/CD automation that exists to make releases safe and repeatable became the thing that leaked the keys to the kingdom. A release workflow with a publish token in its environment is a high-value target, and if an attacker can influence what that workflow runs, they can make it cough up the token. This is the same class of weakness that keeps showing up in supply chain incidents: over-privileged automation holding long-lived publishing credentials.
The worm behavior is why this cannot be shrugged off
sckit is not a passive stealer that sits and exfiltrates once. Analysis shows it can self-proliferate through GitHub and by directly publishing to npm and PyPI. It collects credentials from developer machines and from CI jobs, it receives signed tasks from a command-and-control server, and it carries templates to install itself into npm packages, Python packages, and GitHub Actions workflows.
Put those pieces together and you get the mechanism: infect a developer or a CI runner, steal their publishing tokens, then use those tokens to poison the next set of packages, which infects the next set of victims. As of now it is unclear whether packages beyond MemTensor were caught in the spread, and that uncertainty is exactly the problem with a worm. “We only know about MemTensor so far” is not the same as “it stopped at MemTensor.”
What to do right now
The malicious npm versions were still downloadable at the time of reporting, so this is not a “wait for it to clear” situation. Concrete steps:
- Pin to a known-safe baseline. For the npm package, pin to 0.1.20. For the PyPI package, pin to 2.0.33. Do not just grab “latest,” given how the attacker interleaved clean and malicious releases.
- Rotate every exposed secret. If any affected version touched a machine or a CI job, assume everything reachable from that environment is burned. Rotate npm and PyPI tokens, AWS keys, GitHub and GitLab tokens, Vault tokens, SSH keys, and any of the third-party keys listed above. Rotation, not just revocation, because you do not know what was already used.
- Kill any running sckit process on affected hosts. If you are not confident you found everything by hand, that is exactly the kind of sweep our emergency malware removal team runs on a compromised environment.
- Block skyleen[.]fr and all its subdomains at your DNS and egress firewall, so any implant you have not found yet cannot phone home.
- Audit your CI/CD publish tokens. This is the real lesson. Check whether your release workflows hold long-lived npm or PyPI tokens, whether those tokens are scoped as tightly as possible, and whether an untrusted commit or pull request can influence what a workflow with those tokens runs. Move to short-lived or OIDC-based publishing where you can. It’s exactly the kind of gap a penetration test of your release pipeline is built to catch before an attacker finds it first.
The takeaway
The MemTensor compromise is a clean illustration of where the risk has moved. The vulnerable surface is no longer just your production server, it is the entire path a piece of code travels before it gets there: the packages you pull, the machine you build on, and the automation that publishes on your behalf. A single poisoned dependency, installed once, can drain the credentials that reach your cloud, your repos, and your deploy pipeline in one motion, and this one tries to reproduce through those same credentials. Pin your versions, rotate anything that was exposed, block the exfiltration domain, and treat your CI publishing tokens as the crown jewels they actually are. If you want an outside team keeping watch on that whole chain instead of catching it after the fact, that ongoing coverage is what our managed security hardening and server management services are for.