Any caller holding a valid Agent API key against @paperclipai/server1 before 2026.416.0 can overwrite workspaceStrategy.provisionCommand in their own agent configuration, then wait while the server executes that string verbatim during workspace provisioning. CVE-2026-412082 rates this CVSS 3.1 8.8. No administrator access required; the agent credential is sufficient.
The Advisory in 60 Seconds
GHSA-265w-rf2w-cjh4, privately reported by lilmingwa13 and published to the GitHub Advisory Database on April 16, 2026, targets Paperclip: an open-source Node.js server and React UI that orchestrates AI agents for automated business workflows. NVD picked it up April 22, with CISA-ADP enrichment continuing through at least April 27.
The PATCH endpoint at /api/agents/:id accepts adapterConfig typed as z.record(z.unknown()), a Zod catch-all that permits any key with any value. An agent can write workspaceStrategy.provisionCommand to an arbitrary string. Later, when the server provisions a workspace, it reads that stored value and calls spawn('/bin/sh', ['-c', command]). The payload runs on the host.
Confirmed impact per the advisory: reading environment variables, exfiltrating secrets, modifying repositories, and host persistence.
From Agent Config to Shell Command: How the Boundary Collapses
The schema validation failure is the proximate cause, not the root one. z.record(z.unknown()) at the PATCH handler means the server stores whatever arrives without checking field names. There is no allowlist at write time, no sanitization at read time.
The runtime trusts the stored value completely. provisionCommand lives in the adapterConfig namespace, which an agent owns. The agent API key is supposed to scope the agent to workflow operations. Instead, it authorizes writes to a field the host treats as a shell string during provisioning. The server is a confused deputy: it acts on the agent’s behalf using the agent’s own configuration, but at the server’s execution privilege level.
The attack path:
- Authenticate with a valid Agent API key.
- PATCH
/api/agents/:idwith{"adapterConfig": {"workspaceStrategy": {"provisionCommand": "<payload>"}}}. - Trigger or wait for workspace provisioning.
- Payload executes on the host.
No second vulnerability, no race condition, no escalation step.
The Trust-Model Mistake: Why Agent-Scoped Keys Aren’t Low-Trust
Multi-tenant orchestration platforms typically model agent credentials as workflow-scoped: the key authorizes calls to the agent’s own tools and access to the agent’s own state, nothing more. CVE-2026-412082 demonstrates what happens when that model is assumed rather than enforced at the data layer.
The PATCH endpoint does not distinguish between inert configuration values (display names, timeout preferences, metadata flags) and execution parameters. Both categories live under adapterConfig. Both are writable with the same credential. Only some of them get executed. The agent API key does not know this distinction; the server does, but only at provisioning time, not at write time.
The credential boundary is not defined by who holds the key. It is defined by what the host does with the values that key can write. If the host later runs those values as shell commands, the key is effectively a root credential wearing workflow-scoped documentation.
Paperclip describes itself as providing “identity/access, workspaces/runtime, governance/approvals, and company portability.” The workspace runtime is the exact layer that calls spawn('/bin/sh', ...). When agents can write into that layer through a PATCH endpoint, the governance abstraction becomes circular: the layer that enforces policy and the layer that executes commands share a mutable namespace.
The Patch Gap: What 2026.416.0 Fixed (and Didn’t Advertise)
The fix landed in v2026.416.04. All @paperclipai/server versions before that release are affected. CVE-2026-412082 is not identified by CVE number in the release notes, which makes automated changelog auditing unreliable, so operators need to check the advisory directly or diff the commit.
The advisory does not specify whether the fix is input validation at the PATCH handler, architectural separation of execution fields, or both. That distinction matters. Validating adapterConfig against a strict field allowlist closes this specific injection path; it leaves open any other field the platform interprets at runtime. Structural separation, isolating execution parameters from agent-writable configuration entirely, closes the class. Without reading the diff, the scope of the fix is unclear.
For teams that cannot update immediately: audit which principals can call PATCH /api/agents/:id with an Agent API key. In deployments where agents are provisioned programmatically or where end users can trigger agent configuration changes, every agent is a potential injection vector. Treat any pre-2026.416.0 installation as host-shell-accessible from any principal holding an agent key.
Generalizing the Bug Class: Other Platforms with Agent-Writable Execution Fields
Three conditions define this vulnerability class:
- Agents can write to their own configuration through an API.
- The platform stores that configuration server-side.
- One or more stored fields is later interpreted by the host as executable content.
The third condition is typically not documented. Platforms that orchestrate agents expose configuration APIs that look like data, workspace settings, adapter preferences, runtime parameters. Whether any of those fields feeds a spawn call, a template interpolation, or a script loader is an internal implementation detail that defenders have to audit at the platform level, not infer from the API schema.
LangChain, Flowise, and MCP hosts all have surfaces where tools or agents influence configuration state. The relevant audit question for those systems is not “can an agent call privileged tools?” but “can an agent write a value that the host will later execute without re-validating its origin?”
z.record(z.unknown()) is a common shortcut in early-stage Node.js platforms: accept flexible schemas to ship fast, tighten later. The provisionCommand field is what “tighten later” looks like when it doesn’t arrive on schedule. Input validation at the write endpoint is the minimum fix. Architectural isolation between agent-writable storage and host execution parameters is the durable one, and the only approach that would prevent the next field in adapterConfig from turning into the same bug.
Frequently Asked Questions
Does CVE-2026-41208 require a multi-tenant Paperclip deployment to be exploitable?
No. Any deployment with at least one agent holding a valid API key is vulnerable. The bug is per-agent, not per-tenant — single-tenant setups with programmatically provisioned agents are equally exposed. The multi-tenant framing in the advisory reflects scaling of the attack surface, not a prerequisite.
How does CVE-2026-41208 differ from CVE-2026-41679, the other Paperclip RCE patched in v2026.416.0?
CVE-2026-41679 (GHSA-68qg-g8mg-6pr7), reported by researcher sagilayani, is an unauthenticated RCE requiring zero credentials. CVE-2026-41208 requires a valid Agent API key but represents a deeper authorization design flaw — the credential works exactly as designed, its effective scope just exceeds what the documentation implies. Different reporter, different advisory, different bug class, and a fundamentally different remediation depth.
What log indicators indicate pre-patch exploitation attempts?
Audit PATCH /api/agents/
request bodies for writes to adapterConfig.workspaceStrategy. The advisory documents no server-side mitigation short of upgrading, so any pre-2026.416.0 instance that has processed such a PATCH should be treated as potentially compromised — with environment variable and secret rotation as the immediate follow-up, since the confirmed impact includes exfiltrating secrets and reading environment variables.Has CVE-2026-41208 been covered by security vendors or major outlets?
At research time, no dedicated coverage was found in major security publications. Press attention has focused on the companion unauthenticated RCE (CVE-2026-41679), likely because its zero-auth barrier makes for a more dramatic headline. Organizations relying on mainstream security monitoring channels may have missed this advisory entirely, which compounds the risk from the release notes not naming the CVE by number.