OmniRoute EUVD-2026-112722

The attacker must already possess a valid manage- or admin-scoped OmniRoute API key or an oma_ access token for the target instance, and the instance must have a management password already configured (the first-run bootstrap window, with no password set yet, is a separate intended path and unchanged by the fix). Given such a credential, the attacker reaches the network-accessible POST /api/settings/require-login endpoint and changes the management password or toggles requireLogin without knowing the current password. Limiting factors: the attack is impossible for unauthenticated or anonymous attackers - it strictly requires an elevated machine credential - and the operator can recover via the local CLI, which keeps a host-bound recovery path; the flaw is remediated only by upgrading to 3.8.52, where these routes become operator-only.

The vendor CVSS 4.0 score is 7.0 (HIGH), but the single most important signal is PR:H - exploitation requires the attacker to already hold a manage- or admin-scoped OmniRoute API key or an oma_ access token, so this is a privilege-boundary / authorization-enforcement flaw (CWE-620, unverified password change), not a remote-unauthenticated takeover. The vector is AV:N/AC:L/AT:N/UI:N (network-reachable, low complexity, no user interaction) with impact weighted to integrity (VI:H: change the management password and weaken login/security policy) and low availability (VA:L: operator lockout, recoverable via the local CLI), and explicitly no confidentiality impact (VC:N). Supporting signals temper urgency rather than raise it: there is no EPSS score in the input, the CVE is not listed in CISA KEV, and no public exploit code is present (the references are the fix PR/commit, the vulnerable source lines, and the VulnCheck advisory - not a weaponized PoC). The vuln.today decision label is 'this_week', consistent with a patch-this-cycle item rather than act_now/emergency. Net: a genuine authorization defect worth prompt patching for anyone issuing machine credentials to an OmniRoute instance, but the HIGH score overstates real-world urgency because the PR:H precondition (possession of a valid elevated machine credential) gates the entire attack.

An attacker who has obtained a manage- or admin-scoped OmniRoute API key or an oma_ access token (for example a leaked or over-shared machine credential) sends a POST to /api/settings/require-login and sets a new management password without supplying the current one. This lets them lock the legitimate operator out of the dashboard, hijack dashboard login, or disable the login requirement entirely. No public exploit code was identified; the exact vulnerable route (settings/require-login/route.ts) and the fix are public via the vendor patch.