Omniroute
Monthly
OmniRoute 3.8.0 through 3.8.51 lets a caller who already holds a manage- or admin-scoped API key, or an oma_ access token, replace the instance management password or toggle the login requirement via POST /api/settings/require-login without supplying the current password, and the same machine credentials could also weaken security-policy keys such as requireLogin, newPassword, oidc*, corsOrigins and bruteForceProtection on PATCH /api/settings. The practical outcomes are dashboard login takeover, operator lockout, or disabling the login requirement altogether, but the flaw sits behind an already-elevated machine credential (CVSS 4.0 PR:H, assessed as CVSS 3.1 PR:H), so it is an authorization-enforcement failure rather than anonymous remote takeover. No public exploit code and no CISA KEV entry were identified at time of analysis; the vendor addressed it in release 3.8.52 with an operator-only enforcement path, and the vuln.today decision label places remediation in this week's window.
Missing authentication in OmniRoute 3.8.50 through 3.8.51 lets an unauthenticated remote caller POST to /api/sync/tokens and mint a sync token whenever the instance runs in open mode (requireLogin=false), then spend that token against GET /api/sync/bundle to pull decrypted provider credentials and plaintext API keys - the same material /api/settings/export-json already denies to anonymous callers. The flaw is conditional: when login is enabled (the default), token issuance already required a dashboard session or the local CLI, so only open-mode deployments are reachable, which is why the assessed CVSS:3.1 vector is AV:N/AC:H/PR:N/UI:N with confidentiality-only impact (C:H/I:N/A:N) even though the vendor's CVSS:4.0 score is 8.2. Tokens minted this way were recorded as issuedBy:"open" and kept opening the bundle after login was re-enabled; version 3.8.52 fixes issuance, routing /api/sync/tokens into the always-protected tier and refusing the legacy "open" tokens. No public exploit code was identified at time of analysis and the CVE is not in CISA KEV; priority is this_week.
Remote code execution in OmniRoute AI gateway 3.8.49 and earlier lets attackers run arbitrary commands in the server container via the POST /api/acp/agents custom ACP agent endpoint. The endpoint accepts attacker-controlled 'binary' and 'versionCommand' values and passes them to execFileSync after only a self-consistency (binary-match) check, so a matching interpreter carrying an eval-style argument (e.g. node -e, python -c) executes as code without any shell metacharacter. Because api/acp/ is excluded from the authentication-required prefixes, exploitation is remote and anonymous whenever requireLogin=false or during the fresh-instance bootstrap window; no fixed version exists and no public exploit is identified, though the GitHub advisory documents the PoC shape.
OmniRoute 3.8.0 through 3.8.51 lets a caller who already holds a manage- or admin-scoped API key, or an oma_ access token, replace the instance management password or toggle the login requirement via POST /api/settings/require-login without supplying the current password, and the same machine credentials could also weaken security-policy keys such as requireLogin, newPassword, oidc*, corsOrigins and bruteForceProtection on PATCH /api/settings. The practical outcomes are dashboard login takeover, operator lockout, or disabling the login requirement altogether, but the flaw sits behind an already-elevated machine credential (CVSS 4.0 PR:H, assessed as CVSS 3.1 PR:H), so it is an authorization-enforcement failure rather than anonymous remote takeover. No public exploit code and no CISA KEV entry were identified at time of analysis; the vendor addressed it in release 3.8.52 with an operator-only enforcement path, and the vuln.today decision label places remediation in this week's window.
Missing authentication in OmniRoute 3.8.50 through 3.8.51 lets an unauthenticated remote caller POST to /api/sync/tokens and mint a sync token whenever the instance runs in open mode (requireLogin=false), then spend that token against GET /api/sync/bundle to pull decrypted provider credentials and plaintext API keys - the same material /api/settings/export-json already denies to anonymous callers. The flaw is conditional: when login is enabled (the default), token issuance already required a dashboard session or the local CLI, so only open-mode deployments are reachable, which is why the assessed CVSS:3.1 vector is AV:N/AC:H/PR:N/UI:N with confidentiality-only impact (C:H/I:N/A:N) even though the vendor's CVSS:4.0 score is 8.2. Tokens minted this way were recorded as issuedBy:"open" and kept opening the bundle after login was re-enabled; version 3.8.52 fixes issuance, routing /api/sync/tokens into the always-protected tier and refusing the legacy "open" tokens. No public exploit code was identified at time of analysis and the CVE is not in CISA KEV; priority is this_week.
Remote code execution in OmniRoute AI gateway 3.8.49 and earlier lets attackers run arbitrary commands in the server container via the POST /api/acp/agents custom ACP agent endpoint. The endpoint accepts attacker-controlled 'binary' and 'versionCommand' values and passes them to execFileSync after only a self-consistency (binary-match) check, so a matching interpreter carrying an eval-style argument (e.g. node -e, python -c) executes as code without any shell metacharacter. Because api/acp/ is excluded from the authentication-required prefixes, exploitation is remote and anonymous whenever requireLogin=false or during the fresh-instance bootstrap window; no fixed version exists and no public exploit is identified, though the GitHub advisory documents the PoC shape.