Unauthenticated RCE in OmniRoute via ACP Custom-Agent Registration (CVE-2026-88062)

What Happened

A GitHub Security Advisory (GHSA-hf57-cqmx-p4gr) discloses a critical remote code execution vulnerability in OmniRoute, tracked as CVE-2026-88062. According to the advisory, the POST /api/acp/agents endpoint — used to register a custom ACP agent — accepts attacker-controlled binary and versionCommand fields. After the agent is saved, the same request triggers refreshAgentCache(), which runs a version-detection probe via execFileSync(). The only validation, resolveVersionProbe(), merely checks that the first token of versionCommand matches the supplied binary — which is also attacker-controlled, so an attacker can submit binary: "node" with a versionCommand like node -e "...arbitrary JavaScript..." to execute code inside the server container.

The advisory further reports that when the instance setting requireLogin=false is set, isAuthenticated() treats anonymous requests as authenticated, and /api/acp/ is absent from both the LOCAL_ONLY_API_PREFIXES and SPAWN_CAPABLE_PREFIXES guard lists — so the endpoint is never intercepted by the local-only policy before hitting the anonymous allow branch. The advisory states this yields unauthenticated RCE with a single HTTP request against instances in that state (including a bootstrap window on fresh instances before a management password is set). A reproduction using the public Docker image is documented, along with a working proof-of-concept. Exploit status is listed as PoC public; CVSS was not provided in the advisory.

Why It Matters

OmniRoute is an npm-distributed package; deployments frequently run self-hosted, containerized, and potentially internet-exposed. Any instance running with requireLogin=false — a supported configuration per the advisory, not a misconfiguration outside the app's design — is reportedly exploitable by any remote, unauthenticated party for full code execution in the container context. Instances still in their initial setup window (no management password configured yet) may also be exposed, since the advisory notes the require-login setting itself can be toggled anonymously during that bootstrap phase. Given a public PoC exists, opportunistic scanning and exploitation should be expected quickly.

What Defenders Should Do Now

• Identify any OmniRoute instances in your environment and check whether requireLogin is set to false, or whether a management password has been configured on newly deployed instances.
• Update to a patched OmniRoute release as soon as one is available, and monitor the advisory for a fix version.
• Until patched, avoid exposing OmniRoute's /api/acp/ endpoints to untrusted networks; restrict access to trusted/internal sources only.
• Hunt for suspicious custom-agent registrations via POST /api/acp/agents, particularly requests where binary and the leading token of versionCommand are interpreters (e.g., node, python) paired with inline execution flags (-e, -c) rather than simple version-check arguments.
• Review container/host logs for anomalous child-process execution originating from the OmniRoute process, and for unexpected file writes (the advisory's PoC writes to a file under the app's data directory as an execution artifact).

Developing Intel

This is fresh, same-day advisory intel and details may evolve as vendor response and patch availability are confirmed. Organizations running OmniRoute should treat this as high priority pending official remediation guidance. Full technical detail and reproduction steps are available in the original advisory: GHSA-hf57-cqmx-p4gr.