Breaking the Paperclip: When Agent Configuration Becomes a Vulnerability

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.

‍

What Are the Paperclip Vulnerabilities?

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.

‍

The Core Problem: Agent Configuration Is Code

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.

‍

Three Routes to the Same Outcome: Arbitrary Code Execution

1. Self-Registered User Escalates to Admin (CVE-2026-41679, CVSS 10.0)

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.

2. Forgotten Authorization Checks on API Routes (GHSA-xfqj-r5qw-8g4j, CVSS 8.3)

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.

3. DNS Rebinding Bypasses Loopback Isolation (GHSA-x8hx-rhr2-9rf7, CVSS 9.6)

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.

‍

The Pattern: Implicit Trust Assumptions

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

• "A self-issued credential is safe enough" (it wasn't; self-approval created a boundary failure)
• "Every sensitive route will enforce its own checks" (forgotten checks exposed data)
• "Localhost means the local user" (browsers violate this assumption)

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.

‍

Why This Matters Beyond Paperclip

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

• Act on behalf of employees, developers, and services
• Hold credentials and authenticate to external systems
• Choose tools and targets dynamically
• Make changes across code, cloud, SaaS, and internal systems

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.

‍

How to Mitigate the Paperclip Vulnerabilities

Now:

• Upgrade Paperclip to version 2026.416.0 or later
• Review your deployment mode and registration settings
• If using local_trusted mode, be cautious about opening untrusted repositories

Short-term:

• Audit existing agent configurations for unintended capabilities
• Monitor agent execution logs for anomalies
• Review which credentials agents can access

Ongoing:

• Treat agent configuration as code: apply review, testing, and approval processes
• Inventory all agents in your environment and their access paths
• Consider opening untrusted repositories in isolated environments
• Establish governance for non-human identities using intent analysis, policy enforcement, and just-in-time access

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