Wazuh Manager CVE-2026-74037

Requires that the targeted account be a run_as user with zero static roles and that the attacker already possesses a previously issued, still-cryptographically-valid JWT whose administrator grant has since been revoked - the flaw is that check_token never consults the revocation blacklist, so the stale token keeps working. Exploitation is strictly limited to actors who previously held high Wazuh privileges (PR:H); it cannot be triggered by an unauthenticated external attacker, requires no user interaction (UI:N), and is relevant only on Wazuh manager 4.0.0 through 4.14.7 where run_as/RBAC with revocation is actually in use. The practical threat model is insider or post-offboarding retention rather than opportunistic remote compromise.

This is a genuine privilege-persistence flaw worth prioritizing in environments that use Wazuh's run_as RBAC, though it is not a mass-exploitation 'drop everything' issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N, VC:H/VI:H/VA:H) scores 8.6 HIGH and correctly reflects that exploitation requires an attacker who already held high privileges (PR:H) - specifically a run_as user with zero static roles whose administrator grant was revoked. The impact is severe once conditions are met: full confidentiality, integrity, and availability loss over the Wazuh manager via permanent admin retention. No EPSS score, no CISA KEV listing, and no public POC were provided, so this is best characterized as no public exploit identified at time of analysis - meaning real-world risk is currently driven by the insider/post-revocation threat model rather than opportunistic internet-wide scanning. The PR:H requirement is the key risk-limiter: an external attacker with no prior foothold cannot trigger this, so it is most relevant to organizations that rotate/revoke Wazuh admin access and need that revocation to actually hold (e.g. offboarding, incident containment). The CWE-613 classification (Insufficient Session Expiration) is consistent with the description that check_token never consults the blacklist. Note a tagging inconsistency: the input tags this as 'Information Disclosure', but the described impact is privilege retention / authorization bypass with full C/I/A impact, not disclosure.

An administrator's access to the Wazuh manager is revoked (e.g. after offboarding or during incident response), but the attacker still holds a previously issued JWT for a run_as user with zero static roles. Because check_token never checks the revocation blacklist, the stale token continues to authenticate, and the attacker self-links the administrator role to permanently regain privileged control of the manager. No public exploit was identified in the provided data; exploitation requires prior high-privilege access (PR:H).