OmniRoute CVE-2026-88062: custom agent registration led to code execution

CVE-2026-88062 is a critical OmniRoute vulnerability in which a custom ACP agent definition could become an instruction to execute code inside the server container. Versions of the omniroute package before 3.8.49 are affected.

Exploitation could be anonymous when an operator disabled the login requirement. A similar path existed during the bootstrap window of a fresh instance without a management password. In the default configuration with login required and a password already configured, the flaw still provided RCE but required a valid management session or management-scoped API key.

Where configuration crossed into code

The endpoint for registering a custom agent accepted a binary program name and a versionCommand used to detect its version. The application checked that the first token of the command matched the program declared in the same request.

That check only works when binary comes from a trusted allowlist. In OmniRoute both fields were controlled by the client. A caller could name an available interpreter as the program and supply an argument that caused it to evaluate code. Blocking a small set of shell metacharacters did not help because the application launched a process directly with an argument array; no shell was required.

Execution timing made the issue more direct. After saving the definition, the same request refreshed the agent cache, ran version detection and reached execFileSync. No later administrator action or restart was necessary.

When no account was required

The official advisory documents two anonymous scenarios:

• the instance has requireLogin=false, so the authentication helper treats anonymous requests as allowed;
• a fresh instance has no management password yet, and a bootstrap settings endpoint lets a caller disable the login requirement first.

The /api/acp/ route was also absent from both the local-only endpoint list and the list of spawn-capable operations. The request could therefore reach the anonymous allow branch instead of being stopped by central policy.

This does not mean every OmniRoute installation was exposed to the internet. Impact depends on published ports, reverse-proxy and network rules, login state and installation phase. Inventory must answer the reachability question, not merely whether the package exists.

RCE inside a container is still an incident

The advisory confirms command execution in the OmniRoute container. It does not establish an automatic escape to the host. Blast radius depends on how the container was launched: its user, mounted directories, environment secrets, access to a Docker socket, network reachability and orchestration permissions.

An AI model and agent gateway often holds or relays credentials for several providers. Code in that process may attempt to read configuration, tokens, request history and routing data and then contact connected services. This is Breachroad’s threat-model assessment; the public source does not say that every exploit exposed every key or compromised the host.

Container boundaries still matter. A non-privileged user, read-only filesystem, minimal mounts, no runtime socket and restricted egress do not fix the application flaw, but they constrain its potential consequences.

Action plan for instance owners

First determine the package and image version actually running in every environment. Then:

1. update OmniRoute to 3.8.49 or later;
2. require login and configure a strong management password before exposing the service to a network;
3. restrict the dashboard and management API to a trusted network, VPN or controlled reverse proxy;
4. remove public reachability from the management port when it is not required;
5. review custom agents, login settings and configuration changes;
6. treat secrets reachable from the process as rotation candidates if the instance was vulnerable and accessible to untrusted clients.

Do not rely on requireLogin=true as the permanent fix. It restricts the anonymous path, but before patching a user with valid management privileges could still reach code execution.

How to approach triage

Preserve reverse-proxy, application, container, orchestrator and model-provider logs. Determine whether the custom-agent endpoint received requests, especially while login was disabled or the instance awaited initial configuration.

Compare stored agent definitions against approved configuration. Investigate unknown binaries and version commands, login-setting changes, new API keys, server child processes and unusual outbound connections. If logging is incomplete, absence of a single record is not proof that execution never occurred.

Next, inventory secrets available to the container: model-provider keys, administrative tokens, database credentials, integrations, cloud credentials and observability systems. Rotate keys with the broadest scope and ability to mint further credentials first.

The official advisory does not report exploitation in the wild. Reviewing logs, processes and secrets is Breachroad guidance derived from the documented RCE.

Source facts and the secure-AI lesson

The endpoint, route to execFileSync, anonymous prerequisites, affected range and 3.8.49 fix come from the official OmniRoute advisory for CVE-2026-88062. It classifies the issue as CWE-94 and CWE-306 and demonstrates why agreement between two client-controlled fields is not an executable allowlist.

The broader lesson for agent platforms is that “add a custom tool” is a code-execution boundary even when the interface presents it as configuration. Our AI red teaming guide for LLM agents explains how to test these boundaries. We help teams build a shared risk model through cybersecurity training and examine deployed systems through AI red teaming.