Critical RCE in OmniRoute's ACP Agent Registration (CVE-2026-88062)

A critical RCE just landed on an MCP router — and the fix is on you

If you're running OmniRoute as your ACP agent router, stop and read this before your next deploy. A newly disclosed vulnerability lets an attacker execute arbitrary commands on your server through a feature that's supposed to just register a custom agent.

What's broken

The vulnerable path runs through POST /api/acp/agents, the endpoint OmniRoute uses to register a custom ACP agent. It accepts two user-controlled fields: binary and versionCommand.

Here's the problem. After a custom agent is saved, that same request triggers refreshAgentCache(), which kicks off version detection for the newly registered agent. That detection step runs:

execFileSync(probe.command, probe.args, ...)

directly against attacker-supplied input. The only gate in front of it is resolveVersionProbe(binary, versionCommand, true), which checks that the first token of versionCommand matches the requested binary — a check that verifies naming, not safety.

That gap is enough. An attacker with access to agent registration can craft a versionCommand whose first token matches the expected binary while the rest of the arguments do something else entirely — and execFileSync runs it server-side, no sandboxing, no allowlist beyond that single token check.

Why this is critical, not just "high"

Remote code execution on the machine running your agent router is about as bad as it gets for a self-hosted MCP tool — it's not a data leak, it's full control of the process, and by extension whatever that process can reach: file system, network, credentials, downstream MCP servers it's configured to talk to.

What to do right now

If you run OmniRoute:

• Restrict who can hit POST /api/acp/agents. If custom-agent registration isn't exposed to untrusted users today, keep it that way — and audit whether it currently is.
• Check your OmniRoute version against the maintainers' advisory and patch as soon as a fix is available. This report doesn't specify a patched release, so track the project's own advisory for the exact fixed version.
• Audit existing custom agents. If registration has ever been open to less-trusted users, review what's already stored in binary and versionCommand for any agent — the exploit only needs one malicious entry to have been saved.
• Don't rely on the first-token check as a mitigation. It's the exact mechanism that failed here.

If you're evaluating ACP routers and haven't deployed one yet, this is the moment to ask vendors directly how they validate anything that ends up in execFileSync or its cousins. "We check the first token" is not an answer you should accept.