Oasis Security advisory

Oasis Security researchers discovered three critical vulnerabilities spanning Paperclip's authenticated and local-development modes. Together, they illustrate a pattern that extends beyond this open-source project to any system where configuration and executable code are the same thing.

An unauthenticated attacker browses to a Paperclip deployment, creates an account, and within moments, executes arbitrary commands on the server. A developer imports a malicious agent configuration bundle into their local Paperclip instance, and the specified command executes as the Paperclip process. Neither requires a phishing email, stolen credential, or user interaction, just three distinct authorization failures in how Paperclip treats agent configuration.

Paperclip released fixes in version 2026.416.0. We responsibly disclosed all findings through their security process before publication. Read the full technical report for attack chains, proof-of-concept code, and remediation details.

Paperclip lets operators manage autonomous AI agents at scale. Companies can be imported from portable bundles, YAML files that define agents and specify which commands they should execute. This is a legitimate feature. It's also why the vulnerability matters.

When you import an agent configuration, you're not just uploading data. You're instructing Paperclip to create an executable entity that can run shell commands on the server with the privileges of the Paperclip process. The configuration file is functionally equivalent to a Dockerfile or a Kubernetes manifest; it determines what code runs and in what context.

Paperclip's architecture assumed that whoever controls agent configuration would be authenticated and authorized to do so. Three separate trust boundaries broke.

Paperclip allowed open signup by default with no email verification. An attacker could create an account and immediately approve their own API credential, converting an unauthenticated signup into board-level administrative access. With that credential, they reached the company import endpoint.

Here's the design flaw: Paperclip correctly restricted direct company creation to instance administrators. But importing a new company that performs the same operation required only board-level access. An attacker exploited that mismatch, imported a company containing a malicious agent with a process adapter (Paperclip's built-in command executor), and woke the agent. The configured command executed as the Paperclip server.

Why it worked: Open registration + self-approved credentials + a lower authorization bar on the import path = remote code execution.

Several sensitive API endpoints omitted authentication or company-scoping checks: heartbeat issue retrieval, agent skill documentation, and deployment health information. An unauthenticated caller could access data and reconnaissance details, thereby reducing the barrier to exploitation.

Why it worked: Authorization was opt-in at the route level. A single forgotten check exposed functionality.

In local-development mode, Paperclip binds to 127.0.0.1 and implicitly trusts all requests reaching that address. A developer opens an attacker-controlled webpage. The JavaScript on that page exploits DNS rebinding to redirect requests from an attacker's domain to 127.0.0.1, while the browser still treats them as same-origin. The local Paperclip instance receives the attacker's requests and authenticates them as an administrator.

The JavaScript imports a malicious agent and wakes it. Code executes on the developer's machine.

Why it worked: The system assumed "loopback = local user = trusted." A browser violates that assumption.

Each vulnerability is distinct, but they a pattern. Paperclip made an implicit assumption who could reach certain functionality:

In normal operation, these assumptions hold. They fail when an attacker finds a less obvious path: a lower authorization bar on a semantically equivalent operation, a forgotten route assertion, or a browser relaying remote instructions to a local service.

This pattern (implicit trust at a boundary that turns out to be crossable) is not unique to Paperclip. It recurs across agent platforms, orchestration systems, and any tool where configuration becomes executable.

AI agents are becoming a new class of enterprise identity. They:

Traditional identity and access management wasn't designed for this. It evaluates identity at a single boundary (e.g., login or API key). Agentic workflows are distributed: a user delegates intent to an agent, the agent invokes other agents or tools, and each step may select a new credential. By the time an action reaches the target system, logs show only the final credential, not the originating user, the responsible agent, or the intended task.

This is the second time in recent months that Oasis Security researchers have found how AI agents can be silently compromised, following our disclosure in OpenClaw . The pattern is consistent: agents with broad access can be hijacked by a single manipulated input, and traditional controls were not designed for this.

Governing agents at scale requires a different approach: visibility into agent identities and their access paths, mapping of delegation from user through agent to resource, contextual enforcement of least privilege, and end-to-end attribution from human intent to agent action.

See the full technical report for detailed hunting queries and detection strategies.