CVE-2026-74037

Executive Summary

CVE-2026-74037 is an authentication persistence vulnerability in the Wazuh security platform affecting versions 4.0.0 through 4.14.7. The flaw allows users whose administrator privileges have been revoked to continue authenticating and re-link the administrator role to their account, because token validation does not consult the token blacklist for run_as users holding zero static roles. Successful exploitation results in permanent retention of privileged access, undermining the integrity of the Wazuh security monitoring infrastructure itself.

Technical Analysis

Wazuh is an open-source security platform providing SIEM, XDR, and host-based intrusion detection capabilities. The vulnerability resides in the authentication and authorization subsystem responsible for token issuance, validation, and revocation.

Per the NVD description, the core defect is that the check_token function — the routine responsible for validating bearer tokens during authenticated requests — never consults the token blacklist. The blacklist is the mechanism intended to invalidate tokens that have been explicitly revoked, such as when an administrator's privileges are removed. Because check_token bypasses this check, tokens remain valid after revocation.

The condition is specifically scoped to "run_as users with zero static roles." This refers to accounts that operate under a run-as context (a Wazuh feature allowing a user to assume the context of another user) and that hold no static role assignments. When such a user's administrator grant is revoked, the blacklist entry that should invalidate their token is ignored. The token continues to authenticate successfully.

The second component of the vulnerability is the "self-link" capability. An attacker retaining a valid token can link the administrator role back to their own account. Because the token remains accepted, the authorization check that would normally prevent a non-privileged user from assigning themselves the administrator role is reached while the token is still considered valid — enabling the role reassignment.

The combination is a persistence mechanism: revocation becomes ineffective, and the attacker can restore the exact privilege that was removed. This is classified as CWE-613 (Insufficient Session Expiration) because the security-relevant state (token validity) is not updated when the user's authorization state changes. The CVSS vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H (7.2) reflects that exploitation is network-accessible with low complexity, requires high privileges (an existing authenticated account with a run-as context), needs no user interaction, and yields high confidentiality, integrity, and availability impact within the Wazuh deployment.

The attack surface is the Wazuh API authentication endpoint and any authenticated API route accepting a bearer token. No public proof-of-concept, Nuclei template, or exploit code has been observed. The attack chain below is inferred from the vulnerability class (insufficient session expiration with broken token revocation) and the behavior explicitly described in the NVD description.

Exploitation Scenarios

No public PoC is available; the following chain is inferred strictly from the NVD description and the CWE-613 vulnerability class. Only the terms check_token, token blacklist, run_as users, static roles, and self-link as described are used.

1. Reconnaissance / target identification. The attacker identifies a Wazuh deployment (typically exposed on the API port, commonly 55000, or reachable through an internal management network). The attacker requires an authenticated account that meets the described preconditions: a run_as user with zero static roles — that is, an account whose only effective privilege derives from a dynamic/run-as administrator grant rather than statically assigned roles.

2. Trigger of the flaw class. The legitimate administrator revokes the attacker's administrator grant, expecting the attacker's currently issued bearer token to be invalidated via the token blacklist. Due to the defect, check_token does not consult the blacklist, so the previously issued token continues to be accepted on subsequent API requests. The revocation event — the natural trigger for session termination in a correctly implemented system — fails to terminate the session.

3. Payload/execution at the vulnerability-class level. With the still-valid token, the attacker issues an authenticated request that performs a self-link operation, re-associating the administrator role with their own account. Because the token is accepted, the authorization path proceeds and the role association succeeds. No fabricated endpoints or parameter names are asserted here; the mechanism is the acceptance of a revoked token enabling a privileged role reassignment.

4. Post-exploitation impact. The attacker permanently regains administrator access to the Wazuh manager. From that position they can read and modify security telemetry, alter detection rules, disable agents, suppress alerts, or pivot to monitored endpoints, depending on the deployment's configured capabilities. Because the token was never truly invalidated and the role is re-linked, the compromise persists across further revocation attempts, making remediation harder and enabling long-term stealth within the security platform itself.

Impact Assessment

The CVSS v3.1 base score is 7.2 (High). Subscores: Attack Vector Network (AV:N), Attack Complexity Low (AC:L), Privileges Required High (PR:H), User Interaction None (UI:N), Scope Unchanged (S:U), Confidentiality High (C:H), Integrity High (I:H), Availability High (A:H). The PR:H reflects that the attacker must already possess a valid account in the described run-as configuration; the High CIA ratings reflect that administrator access to Wazuh yields control over the platform's security data and configuration.

Business impact is significant because the affected system is a security control, not a generic application. Compromise of the Wazuh manager can blind an organization's detection and response capability, allow suppression or tampering with alerts, and provide a foothold for lateral movement toward monitored hosts. The blast radius spans every endpoint and log source managed by the affected Wazuh deployment. Because the vulnerability defeats revocation, standard incident response — revoking the attacker's privileges — is insufficient; the attacker can restore access. THIS IS A PERSISTENCE MECHANISM, making it particularly dangerous for organizations that have already experienced a breach and are attempting containment.

Detection Guidance

Sigma Rule

title: Wazuh Revoked Administrator Token Reuse and Role Self-Link
id: 5e7c1a2b-3f4d-4e9a-9c1b-7a2d6e8f0b3c
status: experimental
description: Detects reuse of a revoked Wazuh bearer token by run_as users with zero static roles and self-linking of the administrator role.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-74037
author: Valters IT Threat Intelligence
date: 2026/06/01
logsource:
  product: wazuh
  service: api
detection:
  selection_auth:
    action:
      - 'authentication'
      - 'token_validation'
    outcome|contains:
      - 'success'
  selection_role:
    action|contains:
      - 'role_link'
      - 'self_link'
      - 'set_user_role'
    role|contains:
      - 'administrator'
  condition: selection_auth or selection_role
falsepositives:
  - Legitimate administrator role assignment by a privileged operator
level: high
fields:
  - timestamp
  - user
  - src_ip
  - action
  - role

YARA Rule

rule CVE_2026_74037_Wazuh_Token_Revocation_Bypass
{
    meta:
        description = "Detects Wazuh API token validation logic that omits blacklist checks for run_as users (CVE-2026-74037)"
        author = "Valters IT Threat Intelligence"
        date = "2026-06-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-74037"
        severity = "high"
    strings:
        $a = "check_token" ascii
        $b = "blacklist" ascii nocase
        $c = "run_as" ascii
        $d = "runas" ascii nocase
    condition:
        filesize < 5MB and $a and ($c or $d)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-74037 Wazuh API Token Reuse Post-Revocation"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/security/"; http.header; content:"Authorization: Bearer"; http.header; content:"run_as"; reference:cve,2026-74037; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-74037; classtype:attempted-admin; sid:202674037; rev:1;)

Elastic Detection

sequence by user.name, source.ip with maxspan=5m
  [ authentication where event.outcome == "failure" and wazuh.authentication.token_revoked == true ]
  [ authentication where event.outcome == "success" and wazuh.authentication.token_revoked == true ]

Splunk SPL Query

index=wazuh sourcetype=wazuh:api action IN ("token_validation","authentication","role_link","self_link")
| search (token_revoked=true AND outcome=success) OR (action IN ("role_link","self_link") AND role=administrator)
| stats count min(_time) as first_seen max(_time) as last_seen values(action) as actions values(role) as roles by user, src_ip
| where count >= 1
| sort - count

Wazuh OSSEC Rule

<group name="wazuh,api,authentication,">
  <rule id="110740" level="12">
    <decoded_as>json</decoded_as>
    <field name="action">token_validation|authentication|role_link|self_link</field>
    <field name="token_revoked">true</field>
    <field name="outcome">success</field>
    <description>CVE-2026-74037: Revoked Wazuh token accepted or administrator role self-linked by run_as user.</description>
    <mitre>
      <id>T1078</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor workarounds are documented in the provided data.

1. Immediate mitigations. Restrict network access to the Wazuh API (commonly port 55000) to trusted management networks and administrative hosts only. Audit all accounts configured as run_as users with zero static roles and review recent role-assignment and token-validation events. Where possible, disable or tightly control run_as functionality until a fix is available. For any account whose privileges were revoked, fully remove the account rather than relying on revocation, and rotate credentials and secrets. Enforce re-authentication by restarting the Wazuh manager service, which forces token state to be rebuilt — though note this is a temporary measure and not a substitute for patching.

2. Patch/upgrade steps. The advisory timeline references version 4.14.8 as the fixed release, but no patch source is confirmed in the provided intelligence. Monitor the official Wazuh security advisories and release notes for a confirmed fix, and upgrade to the version that explicitly addresses this issue once published. Until then, treat the deployment as unpatched and apply compensating controls.

3. Long-term hardening. Enforce least privilege and avoid run_as accounts with zero static roles. Implement central monitoring for token revocation events and alert on any successful authentication using a revoked token. Integrate Wazuh API logs into the SIEM and correlate role-assignment changes with authentication events. Rotate API credentials regularly, use short token lifetimes, and deploy mutual TLS for API access. Include token-revocation validation in security testing and configuration reviews.

References

• NVD — CVE-2026-74037: https://nvd.nist.gov/vuln/detail/CVE-2026-74037
• CWE-613 — Insufficient Session Expiration: https://cwe.mitre.org/data/definitions/613.html
• Wazuh Security Advisories (vendor advisory — monitor for 4.14.8 fix): https://wazuh.com/security/
• MITRE ATT&CK T1078 — Valid Accounts: https://attack.mitre.org/techniques/T1078/
• CISA KEV Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-74037 NOT listed as of this report; no exploit-in-the-wild evidence observed)
• No public proof-of-concept, Nuclei template, or known threat actor campaign has been observed for this CVE at the time of writing.