When an agent extension inherits your secrets

Free or open-source is not the security mechanism. The risk begins when a workflow node, agent skill, MCP server or memory plugin inherits credentials, files, prompts or execution — and malicious or compromised code can exercise that authority as if it were legitimate integration work.

Five 2026 records show four different ways that trust can fail, plus one important counterexample. Some demonstrate live malicious packages or services; another demonstrates a product authorization flaw without established exploitation. There is no defensible single victim count or loss figure across them.

The common sequence is simple: a useful extension is installed or connected, the host gives it authority needed for legitimate work, and then malicious code, malicious instructions or mutable remote metadata uses that same authority for another purpose.

The table matters because these are not one incident type. A fake extension, a malicious skill, a mutable remote service, a compromised legitimate package and a product authorization bug need different controls.

The n8mare campaign is the cleanest business-automation example. Endor Labs documented npm packages masquerading as useful n8n community nodes. One Google Ads-themed node requested the configured OAuth credential through n8n during ordinary workflow execution and sent it, together with host identifiers, to attacker-controlled infrastructure.

Nothing in that path required the package to crack n8n's credential storage. Once installed, the node was running where legitimate integrations are expected to receive decrypted credentials and make outbound requests. The security boundary had already moved from “is the credential encrypted at rest?” to “which code is allowed to receive it at runtime?”

Registry download numbers do not answer how many people were compromised. A download is not a unique installation, an installation is not necessarily an execution, and an execution is not automatically a successful theft. The canonical record therefore keeps the malicious behavior separate from any unsupported victim denominator.

OpenClaw skills show a different route. A skill can be mostly instructions rather than a conventional binary, but that does not make it low-authority. Unit 42 describes malicious skills that used the agent's own filesystem, shell, credential-manager or authenticated-session capabilities; Snyk separately found human-confirmed malicious payloads designed for credential theft, backdoors or exfiltration.

The denominators need care. Snyk scanned 3,984 skills and found 1,467 with at least one security issue, while its intentionally malicious subset was a separate 76 human-confirmed payloads. Unit 42 later reported five malicious skills that remained unblocked during its February-May study window. Those numbers describe different populations. None is a victim count.

Marketplace scanning and takedowns helped: Unit 42 says the five skills it reported were removed and associated accounts were banned. But the same study documents scanner-evasion behavior, including padding intended to exceed or confuse scanning.

Deadbugz is important because the attacker did not need to swap a local package after installation. Pillar observed a remote MCP service called productivity-suite behave like an ordinary text tool for three calls and then change the tool and prompt metadata presented to the connected agent. The later metadata directed the agent toward SSH keys, AWS credentials, shell history and Kubernetes configuration while also trying to conceal the activity.

This is a post-approval problem. If a user approves only the server's identity once, but the server can later change the semantics the model sees, identity approval does not bind future behavior.

The evidence boundary is unusually important here. Pillar documented the malicious service and a public delivery campaign, but all 23 reviewed campaign pull requests were unmerged at review time. The record does not establish that a victim installed one through those pull requests or that credentials were successfully stolen from a victim.

MemTensor removes another comforting shortcut: “I checked the publisher, so the package is trusted.” On September 23, malicious releases of the legitimate @memtensor/memos-cloud-openclaw-plugin and MemoryOS packages carried the sckit implant.

The OpenClaw plugin was valuable precisely because of where it lived. StepSecurity's reproduction shows the compromised plugin launching the payload from ordinary gateway and memory-recall paths. The child process inherited the host process environment, and the recall path additionally supplied the current user prompt. OSV documents home-directory credential collection and communication with infrastructure under skyleen.fr.

That still needs a hard distinction. The launcher code establishes that prompt text reached the malicious child process; it does not by itself prove that every supplied prompt was successfully transmitted off-host. Likewise, replacing the affected package stops future execution of that artifact but does not revoke credentials that may already have been reachable. Package cleanup and credential response are separate jobs.

The n8n inline Agent advisory belongs in the same article because it prevents the wrong conclusion. Here the problem was not a malicious community node at all.

n8n reported that inline Agent tool-schema introspection could decrypt a caller-selected credential before the language model was consulted. The project-ownership check used on the normal invocation path was missing from this earlier path, so an authenticated member who knew a credential ID could cause another instance credential's plaintext secret to be sent to a chosen host. Credential IDs themselves were not treated as secrets and could appear in workflow JSON, exports or editor URLs.

Versions 2.39.6 and 2.40.1 patched the flaw, and NVD later assigned CVE-2026-103246. The cited records do not establish exploitation in the wild. This is a product authorization defect, not evidence that n8n intentionally steals user data.

The repeated pattern is not “open source is unsafe.” It is that extensions sit inside the effective security boundary once the host gives them useful authority.

For business automation, four questions are more useful than the license badge:

1. What can this component read? Credentials, prompts, files, browser state, local environment variables and connected SaaS data are different authority classes.
2. Where can it send data? Outbound network access turns a read capability into a potential exfiltration path.
3. Can its code or semantics change after review? Package updates, compromised publishers and mutable MCP definitions all break one-time trust decisions in different ways.
4. Which controls live outside the extension? Least-privilege credentials, egress policy, package/version verification, renewed approval for semantic changes and host-side authorization checks remain meaningful even when the extension's own instructions are hostile.

These cases do not support calling free software, open-source software, n8n, OpenClaw or MCP implementations spyware as a class. They also do not support adding package downloads, marketplace listings or scanner findings into one victim number.

The stronger conclusion is narrower and more operational: an extension becomes security-critical when useful work requires privileged context. At that point, the important questions are what authority it inherits, whether that authority is independently constrained, and whether code or semantics can change without a new trust decision.

That is why a “free module” can become expensive without the word free being the cause.