Skip to content
The AI-First Web

Malicious MemOS Packages on npm and PyPI Steal Developer Credentials

Compromised MemTensor releases ran secret-stealing binaries on import, exposing developer machines and CI runners

K
Kannan SP
· 5 min read
Share on X LinkedIn
Malicious MemOS Packages on npm and PyPI Steal Developer Credentials
Key finding

PyPI package size increase in the compromised release: 951,210 to 19,201,772 bytes (Source: Socket (September 2026))

A memory framework for AI agents shipped a hidden binary

On September 23, 2026, a threat actor published malicious releases of two packages belonging to MemTensor's MemOS, an open source memory framework used by large language models and AI agents, according to Socket. The compromised packages were the npm package @memtensor/memos-cloud-openclaw-plugin and the PyPI package MemoryOS. Both dropped a cross-platform Go binary named sckit that ran in the background, searched the host's home directory for credentials, and reported to command-and-control servers under the domain skyleen[.]fr, Socket's static analysis of the published artifacts found.

951,210 to 19,201,772 bytes
PyPI package size increase in the compromised release
Source: Socket (September 2026)

The payload ran on import, no explicit action needed

For the PyPI package, the malicious code hooked configure_logging(), a function that get_logger() calls. Socket found that 149 modules in the package call get_logger() at module level, including a module imported by the package's own __init__.py. The practical effect: simply running "import memos" was enough to start the payload once per process, without any developer calling a specific function. The npm plugin behaved similarly, launching the binary when the OpenClaw gateway started and again on every memory-recall event, passing the user's prompt text to the binary each time.

149
PyPI modules that trigger the payload merely by importing the package
Source: Socket (September 2026)

The compromise moved across two registries in hours

Socket's timeline shows the malicious npm version 0.1.21 published at 02:23 UTC on September 23, followed by a malicious commit to the MemOS GitHub repository at 03:17, two further npm releases, and a malicious MemoryOS 2.0.34 wheel and source distribution uploaded to PyPI at 05:25. The npm releases came from the same account used for legitimate releases but lacked a gitHead reference, meaning they did not originate from the project's CI workflow. Socket said it could not confirm how the attacker obtained publishing access to either registry.

just over 3 hours (02:23 to 05:25 UTC, September 23)
Time from first malicious npm release to malicious PyPI upload
Source: Socket (September 2026)

What the binaries targeted, and how long the operation was configured to run

Strings recovered from the sckit binaries show they searched for credential files including .npmrc, .vault-token, id_ecdsa and stored_tokens, alongside environment variables and secrets formatted as AWS access keys, GitHub and GitLab tokens, npm and PyPI tokens, Hugging Face keys, Slack, Stripe and SendGrid keys, and JWTs, Socket reported. Each of the six binaries carried an embedded configuration set to expire on October 22, 2026, after which the attacker's control channel would stop functioning under its current setup. Socket also noted binary strings referencing package manifest encoding and repository file installation, which it said could indicate the malware is capable of republishing packages using stolen registry tokens.

October 22, 2026
Configuration expiration date embedded in the malware
Source: Socket (September 2026)

What a budget-holder should ask their team

Socket's guidance is specific: any environment that loaded npm versions 0.1.21, 0.1.23 or 0.1.25, or imported PyPI MemoryOS 2.0.34, should be treated as compromised — including CI runners and containers that only ran tests. For organizations building on AI agent tooling, the relevant questions are: does anything in our stack depend on MemOS or an OpenClaw plugin pulled via a "latest" tag rather than a pinned version, and would our dependency-scanning process have caught a same-day, same-account release with no CI provenance? Teams should also confirm whether any host that ran the affected packages held npm or PyPI publish tokens for the organization's own packages, and whether logs show any egress to skyleen[.]fr since September 23.

Share this insight