MemTensor Compromise: Poisoned MemOS Releases on npm and PyPI

What it is

On 23 September 2026 UTC, three malicious versions of @memtensor/memos-cloud-openclaw-plugin were published to npm, and MemoryOS 2.0.34 followed on PyPI at 05:25 UTC. Both belong to MemTensor's MemOS memory layer for AI agents. Socket found that each bundled a Go binary, sckit, that harvested credentials and secret environment variables and reported to servers under skyleen.fr. OSV tracks them as MAL-2026-16476 (npm, alias GHSA-mhjf-v53x-7p87) and MAL-2026-16475 (PyPI, alias PYSEC-2026-3987). Both registries have removed the malicious versions.

How it works

• npm plugin: sckit starts when the OpenClaw gateway starts, and again on every memory recall. The user's prompt is passed to it in the SCKIT_EVENT_TEXT environment variable, so prompts sent while a bad version was loaded count as exposed.
• PyPI package: sckit starts on import memos, with no API call needed.
• Both: it runs detached in the background with the host's full environment. It looks for credential files and secrets for npm, PyPI, GitHub, GitLab, AWS, Vault, SSH and other services. Strings in the binary suggest it could republish packages using stolen registry tokens.

The malicious npm releases came from an existing maintainer account but had no gitHead, so the project's CI did not build them. The malicious code first appeared in commits that no branch or tag references. How the attacker got access has not been published.

Preconditions / Affected

• npm: three malicious versions of the plugin. The grep below targets 0.1.21, 0.1.23 and 0.1.25. As of 18 October the registry no longer listed those, and latest pointed to 0.1.24.
• PyPI: MemoryOS 2.0.34 only. latest is 2.0.33.
• Versions 0.1.22 and 0.1.24 were published between the malicious releases and match 0.1.20 apart from version strings.

What to do

Check lock files, requirements files and SBOMs:

grep -rnE 'memos-cloud-openclaw-plugin|"0\.1\.2[135]"' --include=package-lock.json --include=pnpm-lock.yaml --include=yarn.lock .
grep -rniE '^memoryos([=<>~ ]|$)' --include='requirements*.txt' --include=poetry.lock --include=uv.lock .
pip show MemoryOS 2>/dev/null | grep -i '^version'

Look for runtime artifacts on hosts and containers that ran either package:

pgrep -fl sckit
ls -la ~/.openclaw/.cache/runtime/ ~/.memos/.cache/runtime/ 2>/dev/null
find / -path '*/.sckit/*' -name sckit 2>/dev/null | head
python3 -c "import memos, os; print(os.listdir(os.path.dirname(memos.__file__)))" 2>/dev/null | grep -E '_stage0|_sckit|_pypi_bridge'

Search DNS, proxy and egress logs for skyleen.fr and any subdomain from 23 September onward. Then:

1. Pin to 0.1.20 for the npm plugin and 2.0.33 for MemoryOS. Prefer 0.1.20 over 0.1.24 until the maintainers publish a verified release, because 0.1.24 was published inside the attack window. Avoid floating ranges.
2. Treat any host that loaded a bad version as compromised, including CI runners and containers. Kill sckit processes and delete the package directories and the .cache/runtime folders.
3. Rotate every secret reachable from the home directory and environment: registry tokens, Git hosting tokens, cloud keys, Vault tokens, SSH keys and .env values.
4. If an affected host held npm or PyPI tokens, review your own packages for releases you did not make.
5. Block skyleen.fr and alert on historical hits.
6. Treat secrets or customer data that users pasted into prompts while a bad version ran as a data exposure.

To spot a similar publishing change, compare registry metadata across recent versions of a dependency:

npm view some-package@1.2.3 gitHead dist.attestations --json

A release that lacks a gitHead or attestation its predecessors had deserves a pause.

Caveats

The entry point of the compromise is unpublished. The findings come from Socket's analysis, and the binary's republishing ability is inferred from strings, not demonstrated.