What happened
Between 02:23 and 05:25 UTC on 23 September 2026, the malicious npm and PyPI releases were published across the two package registries. On 24 September 2026, SC Media independently reported the affected versions, sckit execution conditions and developer-secret exposure. The malicious npm releases were @memtensor/memos-cloud-openclaw-plugin 0.1.21, 0.1.23 and 0.1.25, with 0.1.20 identified as last known good; the malicious PyPI release was MemoryOS 2.0.34, with 2.0.33 identified as last known good. The npm plugin launched sckit when the OpenClaw gateway started and during memory recall, while MemoryOS 2.0.34 launched it when the memos module was imported.
Published credential targets include .npmrc, .pypirc, .git-credentials, .netrc, id_rsa, id_ecdsa, id_ed25519, .vault-token, msal_token_cache, access_tokens.json and access_tokens.db. Published command-and-control infrastructure includes skyleen[.]fr and the subdomains 8a8acaf167b3[.]skyleen[.]fr, 0b48fafd6fbe[.]skyleen[.]fr and 266297c6df27[.]skyleen[.]fr. Package SHA-256 values are 995a208944176c437a023f4a5c11baad2eb77a91847893c82e5866eaabedb810 for 0.1.21, 6caf89b059e9b6c82bb4ac4727816d516753c4d26833434dea0ecda44a346eb3 for 0.1.23 and a6870826cd7c7ec8d32af227252efcdcdca03ac956d4702cdc2157ca82641673 for 0.1.25. OSV lists SHA-256 d9a0eac2487bbfeb09fc34a95e93bfb2045e65bc069fc3054acfa326996b995a for lib/sckit.js and 65faf8ccbcf5b34eb4f72c71bf82815fa9c1e2f947b9c898491540e866132c31 for the Darwin AMD64 sckit binary.
The affected components were MemTensor’s MemOS memory framework and its OpenClaw memory plugin; the cited sources did not identify an AI agent making security decisions in the attack. The cited sources did not identify an underlying AI model or version. The cited sources did not identify an AI operator configuration; execution was triggered by package-load hooks. The server-delivered modules were not observed, so their contents and follow-on capabilities were not published. The cited sources did not establish how the attacker obtained package-publishing access. Attribution posture: The cited sources did not identify the attacker or establish how publishing access to the registries was obtained. The cited source did not publish the actor-attribution detail described as Initial publishing-access mechanism unresolved. The cited source did not publish the underlying model detail described as No underlying model involved or identified. The cited source did not publish the specific operational detail described as No AI operator configuration identified.
Why this matters now
This is not resolved by deleting a dependency. The implant targeted credentials stored in developer home directories and CI environments, including package-registry, source-control, cloud, Vault and SSH material. The npm plugin also received user prompt text during its memory-recall hook. A host that loaded an affected release must therefore be treated as a credential-compromise event with possible downstream package publication, not as a routine vulnerable-component finding.
The alternating clean and malicious npm releases show why a current version number or latest tag is not adequate supply-chain assurance. Organisations need immutable package hashes, controlled internal mirrors and evidence connecting source, build workflow, publisher identity and registry artefact. AI platform teams require the same software-supply-chain controls as conventional application teams, particularly where plugins can access prompts, credentials, agent context and publishing workflows.
The decision for security leaders
Treat execution of an affected package as host and identity compromise. The response owner should isolate the system, preserve the package and process evidence, rebuild from a trusted image and rotate every secret accessible to the affected user from a clean system. Rotation scope must include registry tokens, source-control credentials, cloud keys, Vault material, SSH keys and secrets entered into OpenClaw prompts.
Require application security and platform engineering to examine whether stolen publishing credentials created new versions of internal or public packages. Pinning to the last known-good release is an interim containment step, not evidence of closure. Future restoration should rely on verified artefact hashes and trusted build provenance rather than a registry’s latest tag.
Evidence of closure
- SBOM and lockfile exports show no affected versions in active environments.
- Credential-rotation records cover every secret reachable from affected user homes.
- Registry audits confirm no unauthorised downstream package releases.
- Rebuilt hosts show no sckit artefacts or command-and-control traffic.
The Security.io assessment
The package versions, execution hooks, credential paths, domains and hashes are corroborated by the OSV malicious-package record, Socket’s static analysis and independent reporting. The unresolved initial-access method matters because registry, maintainer and repository controls may require different remediation. It does not alter the immediate conclusion that any host loading the affected releases had a credential-stealing native binary executed in its user context.
This event is an AI security issue because memory plugins operate close to prompts, agent context and developer credentials, not because an AI model conducted the attack. The mechanical compromise was conventional package malware. Security leaders should resist collapsing these distinctions: AI ecosystem components require mature dependency controls, while claims about agent autonomy or model capability are neither necessary nor supported here.
Questions for the morning meeting
- Did any developer, build runner or AI-agent host load an affected package version?
- Which credentials and publishing tokens were reachable from each affected user home?
- Can package owners prove that stolen tokens did not create downstream malicious releases?