CVE-2026-74037 in Wazuh
Summary
by MITRE • 10/13/2026
Wazuh 4.0.0 before 4.14.8 fails to invalidate issued tokens for run_as users with zero static roles, because check_token never consults the blacklist. Attackers with revoked administrator grants can continue authenticating and self-link the administrator role to permanently retain privileged access.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability in Wazuh versions prior to 4.14.8 represents a critical authentication bypass flaw rooted in improper session management for users operating under run_as privileges. Specifically, when an administrator revokes static roles from a user who has been granted temporary elevated permissions via the run_as feature, the system fails to invalidate any previously issued JSON Web Tokens associated with that user. The core technical defect lies within the check_token validation logic, which does not consult a centralized blacklist or session invalidation registry before granting access. Consequently, even after an administrator explicitly removes privileged roles from a specific account, the existing tokens remain valid and functional until their natural expiration time is reached. This design oversight creates a significant window of opportunity for malicious actors to exploit stale credentials that should have been rendered obsolete by administrative action.
From an operational perspective, this flaw allows attackers who possess revoked administrator grants to continue authenticating into the Wazuh dashboard using old tokens. Once authenticated through these lingering sessions, the attacker can leverage the run_as functionality to self-link the administrator role back to their own account. This process effectively restores full privileged access without requiring new credentials or exploiting a separate injection flaw. The ability to permanently retain administrative privileges after revocation undermines the fundamental principle of least privilege and compromises the integrity of the security monitoring infrastructure managed by Wazuh. Attackers can maintain persistent control over the system, potentially exfiltrating sensitive log data, tampering with detection rules, or disabling security alerts, thereby rendering the entire SIEM solution ineffective for threat detection and response activities.
This vulnerability aligns closely with CWE-613, which describes insufficient session expiration, as well as CWE-284 regarding improper access control where authorization checks are bypassed due to flawed state management. In terms of the MITRE ATT&CK framework, this behavior facilitates Initial Access through valid accounts and Persistence via maintaining active sessions despite administrative revocation attempts. The attack path typically involves an insider threat or a compromised account with initial run_as privileges that escalates back to full admin rights by exploiting the token validation gap.
To mitigate this risk, organizations running Wazuh versions earlier than 4.14.8 must upgrade immediately to version 4.14.8 or later where the check_token logic has been corrected to properly invalidate tokens upon role revocation. In environments where immediate patching is not feasible, administrators should enforce shorter token expiration times to limit the window of opportunity for exploitation. Additionally, implementing strict monitoring on run_as usage and auditing administrative role changes can help detect anomalous behavior indicative of this abuse pattern. Regular rotation of API keys and enforcement of multi-factor authentication further reduce the impact if stale tokens are attempted in use by unauthorized parties.