CVE-2026-74037 is an insufficient session expiration flaw (CWE-613) in the Wazuh API. Tokens issued to run_as users with zero static roles are not checked against the blacklist. The record rates it High at 7.2. Version 4.14.8 fixes it, so upgrade.
What's affected
The record says Wazuh 4.0.0 before 4.14.8 is affected, and the advisory (GHSA-3xm6-wp5v-2fm9) lists 4.14.8 as patched.
The advisory frames it for deployments that use single sign on or an authorization context. Revoking a run_as user's privileged role does not invalidate a token that user already holds, and logging out reports success while the token still works. The advisory contrasts this with ordinary role linked users, whose sessions are correctly invalidated, which is how the defect was isolated. It adds that the user can link the administrator role to their own account during that window, which makes the access permanent.
Severity, as two sources state it. The record gives 7.2 (High) under CVSS 3.1. VulnCheck lists it at 8.6 (High) under CVSS 4.0.
How to check if you're exposed
Find the version on each manager and, where relevant, each agent.
/var/ossec/bin/wazuh-control info
The output includes the version. Packages installed from repositories can also be checked with your package manager, for example rpm -q wazuh-manager or dpkg -l wazuh-manager. Compare with 4.14.8, the fixed version the advisory lists.
Then review which accounts use run_as and which roles they hold or recently held. Look at the audit trail for role link changes made by those accounts after a revocation.
What to do now
- Upgrade the Wazuh manager and API to 4.14.8 or later.
- Review every run_as user and the roles currently linked to them.
- Check for administrator role links that were created by accounts whose privileges had been revoked.
- After upgrading, rotate or expire existing API tokens so that old ones stop working.
- Add a step to your offboarding and demotion process to confirm the access really ended, not only that the grant was removed.
Why it matters
The weakness is insufficient session expiration, CWE-613. In the advisory's words the check_token function never consults the blacklist for these users. The result is the gap that every access review fears: someone removes a grant and believes the access is gone, but a token issued earlier still carries the old privileges.
It is worth thinking beyond Wazuh. Revocation is often the least tested part of an authentication system. Short token lifetimes limit the damage, and so does testing that a revoked identity really fails on the next request. The advisory says the attacker could turn temporary privilege into permanent administrator access, which is the more serious part. KEV status is false.
Quick check
Who is affected?
Deployments using run_as users with no static roles, which the advisory ties to single sign on or authorization context setups.
Is removing the role enough after the upgrade?
Also expire existing tokens and check whether anyone linked the administrator role to their own account during the gap.
Sources
Last reviewed: 18 October 2026.
