The OpenClaw Memory Plugin Compromise: Why a Trusted Skill Needs Its Own Boundary

The Plugin Did Its Job. It Also Ran Something Else.

On September 23, 2026, malicious versions of a legitimate OpenClaw memory plugin were published to npm. According to SafeDep's investigation, the affected @memtensor/memos-cloud-openclaw-plugin releases launched a bundled executable when the gateway loaded and again during memory recall. The plugin still looked like an integration for remembering useful context. In the background, it could reach the environment and home directory of the process running it.

That is the uncomfortable part of the story for a business using AI coworkers: an integration does not need to persuade a Teammate to break its instructions if the integration itself executes code with the Teammate's host privileges. Better prompts cannot isolate a process. A professional-sounding plugin description cannot constrain what that process can read.

The same September 23 campaign affected the Python MemoryOS package at version 2.0.34; the identified malicious npm versions were 0.1.21, 0.1.23, and 0.1.25. The researchers found no evidence that every OpenClaw deployment was compromised, and using OpenClaw alone is not evidence of exposure. The scope is the specific packages and versions that were installed and loaded. But the failure mode reaches far beyond this one package: a useful extension can become a route from ordinary business work into source-control, cloud, messaging, and publication credentials.

This is an OpenClaw plugin supply-chain security problem, not a reason to abandon extensibility. It is a reason to design each extension as though its publisher, build pipeline, or next release could be wrong.

How a Memory Feature Became a Credential Path

A memory integration sits at a privileged seam. It receives content at the beginning of a request, stores or retrieves context, and stays close to the runtime that handles messages and connected services. That placement is precisely why the feature is valuable. It is also why a malicious update there has a larger reach than a document the Teammate merely reads.

StepSecurity's package analysis found that the malicious plugin added a launcher to normal startup and recall paths. It did not rely on an npm install script. Blocking installation scripts would not have stopped code that ran when the installed package was used. The launcher passed the host process environment to a bundled executable; the recall path also passed the current prompt text. The researchers documented credential-hunting patterns for cloud, repository, package-registry, Slack, Stripe, and other secrets. That is evidence of capability and intent, not proof that every potential secret was actually stolen from every host.

SafeDep traced the publication path back to MemTensor's release workflows. Its report describes attacker-controlled commits that caused a release job to expose publishing tokens, followed by compromised packages appearing through legitimate package channels. It also notes that clean and malicious npm versions alternated within the same day. A package name you recognize and a normal registry URL do not establish that the bytes in today's release match yesterday's trusted version.

The timing matters. The suspicious versions were published and loaded through the exact mechanism operators use to get new features and fixes. This was not a user pasting an obviously hostile instruction into a chat. The apparent trust came from the package identity and the release process. Once loaded, the code acted outside the boundary that a prompt can enforce.

What bad looks like

A small business runs an always-on Teammate for customer operations. Its memory plugin is installed on the same agent server as a broadly scoped source-control token, a cloud credential, and messaging credentials in the service account's home directory. Updates are automatic, and nobody records the deployed plugin version. A malicious dependency can inherit the runtime environment and examine reachable files before the Teammate has even answered a customer request. If the operator discovers the advisory days later, they cannot say which version ran or which credentials were present during that window.

The problem is not that the Teammate forgot a rule. The problem is that one integration inherited more authority than its memory job required, and there was no fast way to reconstruct exposure.

What good looks like

The same business pins approved plugin versions and records them alongside deployment changes. Its Teammate runs under a dedicated identity with access only to the systems needed for its role. Secrets are scoped to specific services and, where supported, destination hosts; an integration is not handed a general-purpose shell environment full of reusable keys. Egress is constrained and observable. The operator can identify every host that loaded an affected version, retire the plugin, and rotate only the secrets that were actually reachable on those hosts.

These controls do not make a malicious package harmless. They turn an unbounded incident into an incident with a knowable blast radius. That distinction is the difference between a trust architecture and an instruction sheet.

A Skills Marketplace Is Not a Security Boundary

Skills and plugins make AI coworkers useful because they connect a role to real work. But there is a category error in treating a marketplace listing, a popular repository, or an attractive demo as permission to execute anything the package contains. A registry verifies where an artifact is distributed; it does not guarantee that every future release is benign. A security review at installation does not automatically review tomorrow's update.

There are three boundaries to separate. First, content: a retrieved web page or document may contain malicious instructions, but it should remain data. Second, model behavior: the Teammate can be directed to ask for approval or refuse an unsafe action, but that is a probabilistic control. Third, runtime execution: a loaded extension can execute under the service account without asking the model what it thinks. The MemTensor incident crossed the third boundary. Treating it as only a prompt-injection problem would point the team at the wrong fix.

The OpenClaw project's September 21 Trail of Bits audit recap makes a related but separate point: permission checks must follow a request through subsequent work and be applied to the exact resource used when it acts. The project says it repaired the actionable findings in its stable releases. Those core repairs are important, but an audited core does not make a third-party executable trustworthy. Updating the runtime and controlling extension provenance are complementary duties, not substitutes.

This is why persistent agent servers need explicit roles and identity boundaries. A finance Teammate that drafts invoice notes does not need the engineering Teammate's repository token. A research Teammate should not share a host-level credential pool with one that can publish code. Privilege separation reduces what an extension can do even if its package changes underneath you. It also preserves the ability to change model providers without rebuilding the security model around any particular model's willingness to comply.

The operational question is not simply, “Is this skill safe?” It is, “If this exact skill update were malicious tomorrow, what could its process read, which destinations could it contact, and how quickly would we know?” That question is answerable before an incident. It is much harder to answer afterward.

A Practical OpenClaw Plugin Supply-Chain Checklist

You do not need an enterprise procurement committee to apply this lesson. You need a small inventory, a change gate, a narrow runtime identity, and an incident plan that can be used under pressure.

1. Inventory what runs, not just what is installed. List each Teammate's plugins and Skills, package names, exact versions, source repositories, and the agent servers that load them. Record the responsible human owner. A lockfile on a developer laptop is not proof of the version on a production server.

2. Pin and review updates before deployment. Compare the new artifact and release notes with the previously approved version. Look for new executable files, unexpected size changes, expanded permissions, new network destinations, and changes to release workflows. In this case StepSecurity observed a jump from roughly 272 KB unpacked in the clean baseline to more than 43 MB in a malicious release, largely due to bundled binaries. Size alone does not prove malice, but it is an effective reason to stop and inspect.

3. Separate credentials by role and host. Run a Teammate under an identity limited to its business function. Keep publishing tokens and administrative credentials out of a customer-facing runtime. Scope a secret to the service and destination that actually needs it; the broader OpenClaw credential design begins with that separation. If one package loads in the wrong place, this should not hand it keys to the rest of the company.

4. Constrain and log network access. Where the hosting environment permits, give extension processes only the outbound access their integration requires. Record destination, process, and time so that a newly observed destination can be investigated. An egress rule is not a substitute for vetting code, but it can interrupt an otherwise silent credential path.

5. Test the removal path. Know how to stop an affected Teammate, remove or quarantine a plugin, restore a known-good deployment, and revoke credentials without losing the business workflow. A rollback that restores yesterday's package but leaves exposed keys active is incomplete.

6. Keep a short incident worksheet. For each host: affected version, first and last execution time, credentials accessible to the service account, relevant process and network logs, rotation owner, and business workflows that need a temporary human handoff. If you cannot fill in those fields, improve observability before adding more integrations.

For readers whose systems may have loaded the affected MemTensor releases, the immediate action is not a generic “run a security scan.” Identify exact package versions and affected hosts, preserve relevant logs, stop and remove the affected package, rebuild from a vetted state where practical, and rotate credentials accessible to that process. Review source-control and release activity under those identities. SafeDep and StepSecurity publish package-specific indicators and version guidance; consult their current reports rather than assuming a later latest tag is safe. Because the npm recall path handled prompt text, include sensitive prompts in the exposure assessment. Do not assume that a clean-looking current registry listing proves a host was never exposed on September 23.

There is a useful distinction between containment and certainty here. A team can act on the evidence of an affected version without claiming it knows whether every outbound attempt succeeded. Conversely, absence of a confirmed exfiltration log does not make a loaded credential-hunting binary acceptable to leave running. Preserve evidence, contain access, then investigate the narrower question of what happened.

FAQ

Q: Does this mean OpenClaw itself was compromised?

A: No. The reported incident concerns identified releases of a third-party OpenClaw memory plugin and a related Python library. OpenClaw alone does not establish exposure. Check whether the named package and version actually ran in your environment.

Q: Would disabling npm install scripts have prevented this?

A: Not for the documented runtime path. The malicious plugin launcher ran when the gateway loaded the plugin and during memory recall, according to the package investigations. Review what loaded code can execute and access, not only what installation hooks run.

Q: Should we stop using third-party Skills and plugins?

A: No. Use the ones that provide a clear business function, but give them a versioned approval path and a runtime identity no broader than the role requires. An integration that must read memory does not thereby need repository publishing credentials.

Q: Is a model instruction to ignore malicious content enough protection?

A: No. That instruction addresses model behavior when reading untrusted content. Executable package code runs under operating-system permissions. Isolate privileges, limit credentials, vet artifact changes, and constrain network access at the runtime layer.

Q: What if we cannot tell whether an affected version ever ran?

A: Treat that uncertainty as an incident-response input. Check deployment records, lockfiles, package caches, process logs, and host snapshots; scope credentials that the relevant service account could reach during the exposure window. Then add deployed-version inventory so the next advisory is faster to resolve.

Associates AI builds Teammates on managed agent servers with roles, boundaries, and human review designed around real work. If you are deciding which OpenClaw integrations belong in production and how to contain the ones that fail, view pricing and choose a plan that fits your team.