CVE-2026-118984 in OmniRoute
Summary
by MITRE • 10/29/2026
OmniRoute 3.8.0 before 3.8.52 contains an unverified password change vulnerability that allows holders of manage- or admin-scoped API keys or oma_ access tokens to change the management password without the current password. Attackers can send POST requests to /api/settings/require-login to lock out the operator, take over dashboard login, or disable the login requirement entirely.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in OmniRoute versions prior to 3.8.52 represents a critical authentication bypass flaw within the application's administrative interface. Specifically, this issue stems from an unverified password change mechanism located at the /api/settings/require-login endpoint. The core technical deficiency lies in the server-side validation logic, which fails to require the current password when processing requests intended to modify user credentials or alter login requirements. This design oversight allows any authenticated entity possessing either a manage-scoped API key, an admin-scoped API key, or an oma_ access token to execute state-changing operations without proving ownership of the existing administrative account. In standard secure implementations, changing a privileged password typically requires verification of the current credential to prevent unauthorized takeover by compromised tokens that may have been issued under different contexts or scopes.
From an operational perspective, this vulnerability enables several severe attack vectors for adversaries who have obtained valid API credentials through phishing, token leakage, or other means of initial access. An attacker can leverage these privileges to send POST requests to the specified endpoint with a new password payload, effectively seizing control of the management dashboard without needing the original administrator's secret. This capability directly facilitates account takeover attacks, allowing the adversary to assume full administrative rights over the OmniRoute instance. Furthermore, the vulnerability extends beyond simple credential theft; it permits the modification of login settings themselves. By altering these configurations, an attacker can disable the requirement for login entirely or lock out legitimate operators by changing their passwords without authorization. This dual capability not only compromises confidentiality and integrity but also severely impacts availability by potentially denying service to authorized personnel while granting unrestricted access to malicious actors.
The classification of this flaw aligns with CWE-287, which describes Improper Authentication, as the system fails to adequately verify identity before performing a sensitive action. Additionally, it relates closely to CWE-640, Weak Password Change Procedure, because the process does not enforce sufficient checks such as current password verification or multi-factor confirmation for privilege escalation scenarios. In terms of offensive security frameworks, this vulnerability maps to MITRE ATT&CK technique T1078, Valid Accounts, where attackers use legitimate credentials to maintain persistence and escalate privileges within a network environment. The ability to disable login requirements further correlates with techniques aimed at establishing persistent access while evading detection mechanisms that rely on standard authentication logs.
Mitigation strategies must prioritize immediate patching of the OmniRoute software to version 3.8.52 or later, where this validation logic has been corrected to enforce strict password verification for all administrative changes. Until patches are applied, organizations should implement network-level controls such as Web Application Firewalls (WAF) rules that restrict access to the /api/settings/require-login endpoint exclusively from trusted IP addresses associated with internal management networks. It is also critical to audit existing API keys and tokens; any credentials identified as having manage or admin scopes should be rotated immediately, especially if there is suspicion of compromise. Implementing strict role-based access control (RBAC) policies that limit the number of high-privilege accounts can further reduce the attack surface by minimizing the value of stolen credentials. Regular monitoring for anomalous POST requests to administrative endpoints and reviewing authentication logs for unexpected password changes or login requirement modifications are essential steps in detecting potential exploitation attempts before significant damage occurs.