Two critical vulnerabilities just dropped in Paperclip, an open-source platform for running teams of AI agents. The worse one — CVE-2026-41679 — carries a CVSS score of 10.0. That's the maximum.
If you're running Paperclip, update to v2026.416.0 now. If you're not, read this anyway, because the actual issue is larger than this one tool.
What Paperclip is
Paperclip is infrastructure for AI agent orchestration. It's not a chatbot — it's the control plane you deploy when you're wiring up multiple agents to work together against your actual systems. An intake agent processes incoming requests. A research agent queries your data sources. A drafting agent sends output somewhere. The project markets itself for "zero-human companies" — workflows that run without a person touching them.
That framing is aspirational for most teams, but the platform is genuinely used by small orgs who've moved past running one-off AI prompts and are building real agent automations. You deploy it self-hosted, give it credentials to your tools and data, and it manages the agents.
Which is exactly why it's now worth attacking.
The attack chain
Oasis Security published the research on August 4. CVE-2026-41679 requires no existing account on your instance and no victim interaction.
Here's how it works:
Step one — sign up. Paperclip's default registration accepts new accounts with no email verification. An attacker creates one.
Step two — approve yourself. The CLI authorization flow is supposed to require a separate administrator to approve access requests. But the flow doesn't actually check that the approver and the requestor are different people. The attacker submits an approval request and approves it themselves — instantly minting a board-level API credential with no one else involved.
Step three — import a malicious agent. Paperclip supports importing agent configurations via .paperclip.yaml files. One of the built-in adapter types is called process. It runs shell commands as child processes on the host server. The attacker crafts a YAML file with a process adapter pointing at whatever command they want — a reverse shell, a credential dump, anything.
Step four — wake it. They import the configuration and trigger the agent. Paperclip executes the command.
Whatever OS account runs Paperclip, the attacker now has. That means every credential the platform holds, every API key your agents use, every service they can reach, and whatever's on the filesystem.
Running it locally doesn't save you
There's a second vulnerability that closes the obvious escape hatch.
A lot of teams run orchestration tools locally or behind a firewall, reasoning that if it's not exposed to the internet, they're fine. DNS rebinding breaks that. An attacker serves you a webpage. Your browser loads it. Mid-session, the attacker's DNS record flips to 127.0.0.1. Your browser now treats requests from that page as same-origin traffic to localhost. Paperclip's server accepts them because they arrive from loopback, which looks like a trusted local request.
Oasis demonstrated the full chain. A Paperclip instance reachable by a browser on the same machine — including a developer's laptop — is reachable by any webpage that person visits. The "it's only local" assumption doesn't hold.
Why this keeps happening
This is the third AI orchestration platform hit with critical unauthenticated or near-unauthenticated RCE in the past two months. LangFlow just made CISA's Known Exploited Vulnerabilities catalog for the third time this year. CoreBreak hit AWS Bedrock AgentCore, Google's ADK, and the Vercel AI SDK harness at Black Hat this week.
The reason isn't that these projects are written carelessly. It's structural.
AI orchestration tools hold the credentials for everything the agents touch. A Paperclip instance for a 15-person org might hold: database credentials, Google Workspace OAuth tokens, CRM API keys, LLM API tokens, cloud service account keys, email sending credentials. Compromising the orchestration layer gets all of those in a single hit — instead of attacking each service individually with its own authentication.
That's a far better target than any one downstream service. Attackers have clearly noticed. As more teams build out agent stacks, the orchestration layer becomes higher-value, not lower. This pattern is going to continue.
What to do
If you run Paperclip: Update to v2026.416.0. If you've had a network-accessible instance running with default registration settings before this patch, treat every credential it held as potentially compromised and rotate them. Check for unexpected accounts in your instance's user list.
If you're building any agent stack: Take 30 minutes and list every credential your orchestration layer holds — not what you intended it to hold, but what's actually wired in right now. Then ask: if an attacker got code execution on that host today, what's the blast radius?
If the answer is "read and write access to our CRM, our email, and our database," the orchestration layer needs its own security model — not just a careful system prompt.
Things that help: scoped credentials (read-only tokens where possible, short-lived where your provider supports it), network isolation for the orchestration host, and authentication on local deployments even when you think nobody outside your machine can reach it.
The system prompt is not your security boundary. Every AI framework that hits critical mass gets scrutinized for critical vulnerabilities. Treat self-hosted AI orchestration tools the way you'd treat a web server with root-level access to your systems — because that's what they are.
We help small teams set up AI agent stacks with the credential architecture and network isolation worked out before the first CVE, not after. If your agents are touching production data and you haven't mapped what the orchestration layer can actually reach, get in touch.