AI gateway OmniRoute exposes remote code execution flaw

A remote code execution flaw in OmniRoute, an open-source AI gateway that gives applications a single endpoint for multiple model providers, was published in the US National Vulnerability Database on 10 September 2026. The advisory, tracked as CVE-2026-88062, covers OmniRoute version 3.8.49 and all earlier releases. In some configurations an unauthenticated attacker on the network could run arbitrary code inside the server container. No fixed version was available as of the review, according to the NVD entry.

The problem sits in the POST /api/acp/agents endpoint, which registers custom ACP agents. According to the advisory, the endpoint accepted attacker-controlled values for the agent binary and its versionCommand, the command used to check which version of the agent is installed. Before running anything, the code performed only a self-consistency check. The same request also called refreshAgentCache, and a function named resolveVersionProbe accepted the matched command before execFileSync, the function that actually spawns a process, ran the chosen interpreter and its arguments.

OmniRoute did try to filter the input. The advisory says a tokenizeVersionCommand function and a DISALLOWED_VERSION_COMMAND_CHARS list rejected a limited set of shell metacharacters, the punctuation commonly used to chain extra commands together. But the filter still allowed interpreter evaluation arguments, meaning the flags that tell a language runtime to execute a string of code supplied on the command line. That was enough to turn a version check into arbitrary code execution.

Authentication offered no reliable barrier. According to the NVD record, the isAuthenticated function relied on isAuthRequired, which accepted anonymous requests when the requireLogin setting was false. The api/acp/ path was also missing from two allow-list constants, LOCAL_ONLY_API_PREFIXES and SPAWN_CAPABLE_PREFIXES, so the endpoint was neither restricted to local callers nor flagged as capable of spawning processes.

The practical result is two exposure paths. Where requireLogin was set to false, a remote anonymous request could reach the endpoint directly. The advisory also describes a fresh-instance bootstrap window, the period after a new instance starts and before login is enforced, during which the same unauthenticated request would work. Operators who had set requireLogin to true and configured a management password were better protected: in that case, the advisory says, exploitation required a management session or a management-scoped API key.

The NVD entry links to a GitHub security advisory for the project, GHSA-hf57-cqmx-p4gr, along with a pull request and a commit in the OmniRoute repository. The advisory does not state that any real-world exploitation has been observed, and the record lists the issue as reported rather than fixed.

The pattern is a familiar one for agent infrastructure. Features that let operators register and probe external agent binaries hand a web endpoint the ability to start processes. When the authentication check depends on a configuration flag that can be switched off, and the command filter blocks punctuation rather than capability, the gap between a version probe and a shell becomes very small. Administrators running affected versions should check whether requireLogin is enabled and whether the endpoint is reachable from outside their network.