CVE-2026-88062: OmniRoute's Unauthenticated RCE

OmniRoute is not an obscure project. It’s a free, MIT-licensed AI gateway with more than 58,000 GitHub stars and 550+ contributors, built to give you one endpoint in front of 350-plus model providers so tools like Claude Code, Cursor, and GitHub Copilot can fail over between them automatically. A lot of teams self-host it exactly because it sits in front of every model API call they make. That’s also exactly why CVE-2026-88062, a critical unauthenticated remote code execution bug disclosed on September 10, 2026, is worth stopping for.

Here’s the direct answer: if your OmniRoute instance has requireLogin set to false, or hasn’t finished its initial setup yet, a single HTTP request with no credentials can run arbitrary code inside the container. No phishing, no stolen session, no chained exploit. One request.

Where the bug actually lives

OmniRoute’s /api/acp/agents endpoint lets you register a custom coding agent, which the project models as a binary (the interpreter to run) and a versionCommand (how to check that interpreter’s version). Both fields are attacker-controlled in the request body, and the validation logic only checks one thing: that the first word of versionCommand matches binary.

That’s a check you can satisfy while still doing whatever you want. Set binary to node, then set versionCommand to node -e "<any JavaScript you want>". The first token still matches. The rest of the string is yours. The server hands that straight to execFileSync, and now your code is running inside the same container as OmniRoute’s stored provider API keys, request logs, and whatever else lives in that filesystem.

The part that makes this worse than a typical auth-gated bug: it doesn’t need auth at all. The endpoint isn’t covered by OmniRoute’s LOCAL_ONLY_API_PREFIXES or SPAWN_CAPABLE_PREFIXES protections, and isAuthenticated() treats an anonymous request as authenticated whenever requireLogin=false. A lot of self-hosted deployments run exactly that way, because it’s the path of least resistance for a tool you think of as “internal.”

Nobody agrees on whether it’s patched

Normally a post like this would tell you the fixed version and stop there. This one can’t, honestly, because the public record contradicts itself. GitLab’s advisory database lists “no solution available” for every version up through 3.8.50, published September 10. OSV.dev’s entry points at a specific fix commit. And GitHub shows pull request #11028, merged before the CVE was even published, that does exactly what you’d want: it restricts version-probe arguments specifically to block eval-style execution like node -e and python -c, the precise pattern this bug abuses.

Three sources, three different pictures. That’s not unusual for a fast-moving open-source security disclosure, where automated CVE tooling, the maintainer’s own commit history, and third-party trackers update on different clocks and don’t always reconcile cleanly. What it means for you is simple: don’t trust a version number here, from us or anyone else. Test the actual behavior.

Send a request to your own instance’s /api/acp/agents endpoint with a versionCommand like node -e "1" and confirm it’s rejected rather than executed, or check your codebase directly for whether the argument-restriction logic from PR #11028 is present. That takes ten minutes and tells you something a changelog entry can’t guarantee.

What to do regardless of your version

Because the patch status is genuinely unclear, treat this as a configuration problem you can fix today, independent of whatever version number you’re running:

1. Set requireLogin=true if it isn’t already, and confirm any fresh or test instances have completed setup rather than sitting in the open bootstrap window.
2. Don’t expose the management API to the open internet. If your OmniRoute instance needs to be reachable at all, put it behind a VPN, an internal network boundary, or at minimum an IP allowlist. A self-hosted AI gateway has no business accepting anonymous requests from anywhere on the internet.
3. Rotate the provider API keys stored in it if you have any reason to think the instance was exposed before you locked it down. A leaked OpenAI or Anthropic key is a billing and data problem on top of everything else.
4. Verify the fix directly, per above, rather than assuming an upgrade solved it. If you can’t confirm it, restrict access first and chase the version question second.

The pattern this fits

This isn’t the first time a self-hosted AI gateway has turned into the soft spot in an otherwise reasonable security setup. LiteLLM, a similar gateway project, had its own critical auth-bypass CVE earlier this year, and the underlying lesson was the same one this bug teaches: a gateway that sits in front of every model provider you use inherits the trust of everything behind it, which makes it a much higher-value target than the “just an internal routing tool” mental model most teams apply to it.

If you’re choosing between AI gateway options for your stack, security posture and authentication defaults deserve the same weight as feature comparison and pricing, because the tool you pick to save money on model calls is also the tool that, misconfigured, hands an attacker every API key you’ve connected to it. For teams we work with on AI infrastructure, that exposure check, what’s reachable, what’s authenticated by default, what a fresh install leaves open, is part of the same security review process we’d run on any other internet-facing service. A tool that routes your AI traffic deserves the same scrutiny as the database behind it, not less.