Which versions of memoryos are malicious?

The following PyPI versions of memoryos are flagged malicious: 2.0.34. Treat any of these as compromised.

How do I remediate memoryos if I installed it?

memoryos is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.

I already installed memoryos — how do I know if it already compromised me?

If memoryos was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.

Is memoryos part of a known attack campaign?

Yes — memoryos is associated with the 2026-09-compr-memoryos, IN-MAL-2026-020490 campaign. Packages in the same campaign often share infrastructure and payloads, so check whether any related packages are also in your dependency tree.

How do I find memoryos across my projects, lockfiles, and CI pipelines?

Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for memoryos (version 2.0.34). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging memoryos across your stack and pipelines.

Malicious package

memoryosPyPI

memoryos is a confirmed malicious PyPI package (MAL-2026-16475) that steals credentials and exfiltrates sensitive data (malicious version 2.0.34). Do not install it — remove it immediately and rotate any exposed credentials.

Malicious code in memoryos (PyPI)

MAL-2026-16475

Immediate action

Remove the package, then rotate any secrets the build/runtime could reach.

pip uninstall memoryos

What this malware does

On September 23, 2026, an attacker published malicious versions of two MemTensor packages. The affected packages are the OpenClaw plugin @memtensor/memos-cloud-openclaw-plugin on npm and the MemOS Python library MemoryOS on PyPI. Both versions contain the same Go implant, sckit. The binary runs in the background each time the package loads. It collects credentials from the home directory and sends them to servers under skyleen[.]fr. It also includes the code it needs to copy itself into other repositories and packages that the stolen credentials can reach.

Credential collection: the implant's credentialPaths, readCredentialFile and extractJSONCredentials functions target .npmrc, .pypirc, .git-credentials, .netrc, id_rsa, id_ecdsa, id_ed25519, .vault-token, msal_token_cache, access_tokens.json and access_tokens.db. Two regular expressions pick out secrets: one matches secret-like variable names (token, secret, password, api_key, database_url), the other matches known token formats.

C2 protocol: the internal/wire package uses CBOR, X25519 key exchange and XChaCha20-Poly1305 (sckit/xchacha/v1), and handles signed leases, manifests and modules. The server delivers the modules at run time, so their contents were not observed. scheduleSelfDelete and deleteExecutable remove the binary after it runs.

C2 paths: /<24 hex>/config (control), /status (preflight), /batch (results).

Package archive SHA-256 digests:

memoryos-2.0.34-py3-none-any.whl: 39ee644406829a4b630b31759c20478bc22d576d6a59b253ed86f72c360aa5ef
memoryos-2.0.34.tar.gz: 92b46d18fc553c494eda714f204459edb74c205bf53b18a9092bcf02c7a6c5be

On import memos, memos/init.py invokes configure_logging() which reaches memos._stage0.trigger(). That function locates a per-OS/arch prebuilt Go binary shipped inside the wheel at src/memos/.sckit/{darwin,linux,windows}-{amd64,arm64}/sckit (linux-amd64 is a 7.4MB ELF, sha256 c1b0998347b489582bae7b7f4930f9831d9ef4b6bc150cfd488ee1a43272dd36) and Popen-launches it detached (start_new_session=True, output silenced) with a base64 --config64 payload. The decoded configuration declares campaign_id "memos-semi-nuclear", an Ed25519 root_public key, state_dir $HOME/.memos/.cache/runtime, inventory_roots=["$HOME"], and three anonymous hex-subdomain fronts https://c747d139e7e9.skyleen.fr, https://73376a079d87.skyleen.fr and https://d4f77a3a8cb0.skyleen.fr with config/status/batch endpoints — instructing the launched agent to enumerate the installer's home directory and POST batches to attacker-controlled infrastructure. Separately, the package's PEP 517 build backend (sckit_poetry_build.py) wraps poetry.core.masonry and, when GITHUB_ENV is set, appends BASH_ENV=src/memos/_pypi_bridge.sh to $GITHUB_ENV so that any subsequent bash step in the same CI job auto-sources _pypi_bridge.sh; under a twine publish path this invokes _initial_ci_delivery.py to fetch and execute an Ed25519-signed emitter from https://10729e014d0e.skyleen.fr and reads $INPUT_PASSWORD and $PYPI_API_TOKEN before unsetting them, giving the attacker access to downstream publishing credentials. The combination of import-time detached execution of a bundled multi-arch binary, base64-obfuscated runtime manifest, anonymous hex-subdomain C2 fronts, declared $HOME inventory harvest, and a CI-only sideloader that steals publish tokens is a supply-chain implant.

Versions 2.0.34 were compromised.

The package was compromised and contains a malicious executable. First discovered by Safedep.

Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.

Campaign: 2026-09-compr-memoryos

Reasons (based on the campaign):

compromised-package

Malicious versions

1 flagged

2.0.34

Indicators of compromise (SHA-256)

d17530b4f32046961be6354a73139dafa5a7d73ca9f7226dcf6bb3a3510bde20

f615efcaee7120884365656085be5fdd17450a486945e6154004e36ddab0ac89

91081756ee0d7e550180abd300ce4ed9634862248dd07ea9eed5fb740e4aaffc

86a27870b919aa000ef05a66cedd4622cbf521a2ea6867a579dbec8c90d66f77

Detection & response playbook

Credential / info stealer

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for memoryos (version 2.0.34). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging memoryos across your stack and pipelines.
If you installed it — respond
memoryos is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.
Did it already run?
If memoryos was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.
How O3 protects you
O3 blocks memoryos before install through its supply-chain scanner, and if it has already run, detects and severs the exfiltration or C2 callback at runtime through L7 egress monitoring and eBPF.

Frequently asked questions

No. memoryos on PyPI has been identified as a malicious package (version 2.0.34 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

2026-09-compr-memoryosIN-MAL-2026-020490

References

Credits

Amazon Inspector · finder
Kamil Mańkowski (kam193) · reporter
SafeDep · finder

Detect & block this

O3 blocks memoryos-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the credential exfiltration and severs the channel.

Malware detection Runtime egress monitoring

Explore

All malware advisories How O3 detects malware Vulnerability database