On September 23, malicious releases of MemTensor's MemOS packages appeared on both npm and PyPI, turning a component designed to give AI agents long-term memory into a credential-stealing supply-chain vector. Security researchers at Socket and StepSecurity identified three affected releases of the official OpenClaw plugin — @memtensor/memos-cloud-openclaw-plugin 0.1.21, 0.1.23 and 0.1.25 — plus MemoryOS 2.0.34 on PyPI. OSV now records the Python package as malicious.
The incident matters beyond one compromised library. Memory systems sit unusually close to the most sensitive parts of an agent stack: prompts, recalled context, developer credentials, tool configuration and long-lived state. A malicious build in that layer can inherit trust that teams normally reserve for the agent runtime itself.
What was compromised
The affected packages carried a cross-platform Go implant tracked as sckit. Socket reported that the binaries searched developer home directories for secrets and sent data to infrastructure under skyleen[.]fr. StepSecurity's analysis found credential targets spanning source-control, cloud, registry and developer-tool secrets.
The execution path is particularly important. This was not simply an installer script that a hardened package manager could block. Researchers found that the OpenClaw plugin could launch the payload when the agent gateway starts and during normal memory-recall activity. The Python package could trigger the payload when the memos module was imported. OSV also says the malicious code included machinery intended to copy itself into other repositories or packages reachable with stolen credentials.
That changes the defensive assumption. A dependency may pass installation-time checks and still become dangerous only when ordinary application code loads it.
Why agent memory changes the blast radius
A memory plugin is not an ordinary UI dependency. Its job is to observe conversation state, retrieve prior context and often run automatically before or after an agent turn. In production, that can place it in the same process that holds API keys, model credentials, source-control tokens and cloud access.
The MemTensor incident demonstrates a control-boundary problem: teams may evaluate the security of the model and the agent framework while treating memory as an auxiliary feature. Operationally, memory can be part of the trusted computing base.
The risk is also persistent. An agent memory component is expected to survive across sessions and to participate repeatedly in execution. If compromised, it can receive many opportunities to observe prompts or environment state rather than relying on one initial install event. StepSecurity specifically documented prompt text being passed to the malicious launcher during memory recall.
For Aipolix, the practical conclusion is that agent memory should be classified like a privileged runtime integration, not like a passive storage adapter.
The release pipeline is the real security boundary
Researchers did not describe a simple typosquatting campaign. The malicious releases appeared under the legitimate MemTensor package identities. Socket noted that the npm releases were associated with an account that had previously published legitimate versions, while the suspicious releases did not match the project's normal release metadata.
That distinction matters because package-name allowlists would not have stopped the incident. When a trusted package identity is compromised, provenance becomes more important than name recognition.
Teams need to know which source commit produced a package, which workflow was allowed to publish it, whether the registry artifact has verifiable provenance, and whether publishing credentials can be reused outside the expected build path. A dependency policy that asks only “is this the approved package?” is weaker than one that asks “is this the approved artifact from the approved release path?”
Current registry state also shows why incident response cannot stop at checking the latest tag. The npm page currently lists 0.1.24 as latest, while the malicious versions identified by researchers were separate point releases. PyPI still exposes metadata for the 2.0.34 release. Teams therefore need inventory by exact installed version, not by package name alone.
What affected teams should verify now
Organizations that installed or executed one of the identified releases should treat the host as potentially exposed rather than merely downgrade the package. The published analyses recommend investigating credentials available to the process, reviewing package-registry and source-control activity, and checking whether stolen publishing credentials could have been used downstream.
The affected versions identified across the reports are:
- npm: `@memtensor/memos-cloud-openclaw-plugin` 0.1.21, 0.1.23 and 0.1.25
- PyPI: `MemoryOS` 2.0.34
Researchers identify 0.1.20 and 2.0.33 as last-known-good baselines from before the malicious releases, while npm currently points its latest tag at 0.1.24. That does not replace an incident investigation: a clean package version cannot revoke secrets already copied from a machine that executed a malicious one.
The useful response is therefore broader than dependency rollback: isolate affected systems, rotate exposed credentials from a clean environment, inspect CI and registry activity, and verify downstream artifacts.
What this incident changes for agent engineering
The most important lesson is architectural. Agent systems are assembling a growing supply chain of memory plugins, MCP servers, tool adapters, model routers and autonomous workflow components. Many of them execute with the same ambient authority as the agent.
Traditional dependency scanning remains necessary, but agent infrastructure adds another question: what can this dependency see every time the agent runs?
MemTensor's compromise makes that question concrete. A long-term-memory integration can become a bridge between conversational data, developer secrets and software-release authority. The safer design is to minimize ambient credentials, isolate agent extensions, pin and verify artifacts, and make provenance part of deployment policy.