CVE-2026-74032

Executive Summary

CVE-2026-74032 is an authorization bypass (CWE-863, Incorrect Authorization) in Wazuh affecting versions from 4.0.0 before 4.14.8. A low-privileged authenticated user can query unprotected security endpoints — specifically GET /security/actions and GET /security/resources — which respond without applying the caller's RBAC policies, exposing the full RBAC catalog of privileged actions and endpoints. The impact is limited-confidentiality information disclosure (CVSS 4.3) that materially aids an attacker in mapping a privileged escalation path within the Wazuh environment.

Technical Analysis

Wazuh is an open-source security platform combining a SIEM (Wazuh manager/indexer/dashboard) with a Host-based Intrusion Detection System (HIDS) agent. Its management API historically exposes role-based access control (RBAC) primitives that govern which users may invoke which API actions against which protected resources. In a correctly functioning RBAC implementation, every authenticated request should be evaluated against the caller's assigned policies, and enumeration endpoints should return only data the caller is entitled to see.

This vulnerability violates that contract. According to the NVD description, the endpoints GET /security/actions and GET /security/resources "omit the caller's RBAC policies" — i.e., the authorization filter that normally constrains responses by the caller's role is not applied on these two routes. As a result, any authenticated principal — including one with the lowest privilege tier — receives the complete catalog of enumerated actions and resources rather than a filtered subset.

The core weakness is an authorization-bypass via inconsistent enforcement. The endpoint logic returns the global catalog of security objects (action identifiers and resource identifiers) without consulting the caller's policy set. Because authorization is missing rather than malformed, there is no signature to detect in the request itself: a well-formed, properly authenticated GET request to a legitimate API path triggers the disclosure. This places the flaw squarely in CWE-863 (Incorrect Authorization), a child of CWE-284 (Improper Access Control).

There is no memory-safety issue, no injection token, and no malformed input required. From an exploitability standpoint the attack is trivially repeatable and requires only a valid low-privileged credential. The confidentiality-only scope (S:U, C:L, I:N, A:N) reflects that the immediate damage is leakage of metadata — an internal map of the security model — rather than direct access to monitored data or administrative functionality. The elevated utility of that metadata for an adversary planning lateral movement or escalation is what drives the intelligence value of this CVE, despite the modest numeric score.

No specific function names, source files, or internal API parameters beyond the two documented routes (GET /security/actions and GET /security/resources) are disclosed in the provided data, and none are inferred here.

Exploitation Scenarios

No public proof-of-concept exists, and no exploit code or Nuclei template is available. The chain below is inferred strictly from the vulnerability class (broken/absent authorization) and the endpoints named in the NVD description.

1. Reconnaissance / target identification. The attacker identifies a reachable Wazuh management API (commonly exposed on the API service port for management deployments) and obtains low-privileged credentials. This could be a legitimate but minimal account, a service account, or credentials obtained through unrelated phishing or credential-stuffing activity. Because the CVSS vector is AV:N with PR:L, no local access and no special position are required — only valid low-tier authentication.

2. Triggering the flaw. The attacker issues an authenticated HTTP GET request to /security/actions and a second authenticated GET request to /security/resources. The endpoints process the request normally and return the catalog of security actions and resources. Per the NVD description, the response "omit[s] the caller's RBAC policies" — meaning the authorization filter is not applied, so the low-privileged caller sees the full, unfiltered enumerations rather than a scoped subset. No malformed payload, injection string, or race condition is involved; the request is well-formed and legitimate-looking.

3. Extraction of the RBAC catalog. The attacker receives the list of privileged actions and the list of protected resources. This constitutes an internal map of what operations the platform supports and what objects those operations target. It does not, by itself, grant new access — but it converts a blind environment into a fully enumerated attack surface.

4. Post-exploitation impact. Armed with the action/resource catalog, the attacker maps the gap between their own entitlements and the privileged operations that exist, then plans privilege escalation by targeting the enumerated privileged actions and their associated endpoints using any subsequent weakness (misconfigurations, weak credentials, chained flaws). The disclosure is therefore a precursor capability: it enables reconnaissance for privilege-escalation planning rather than delivering escalation directly. Because the request leaves no malformed artifacts, detection relies on endpoint access telemetry (see Detection Guidance) rather than signature-style payload matching.

Impact Assessment

CVSS 3.1 base score 4.3 (Medium), vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N. The subscores define a tightly bounded impact:

• Attack Vector (Network, AV:N): the flaw is reachable remotely over the network via the Wazuh management API; no physical or adjacent positioning is needed.
• Attack Complexity (Low, AC:L): no environmental preconditions, race conditions, or specialized knowledge beyond the documented endpoints.
• Privileges Required (Low, PR:L): the attacker must be authenticated, but only at the lowest privilege tier.
• User Interaction (None, UI:N): no victim action is required.
• Scope (Unchanged, S:U): the vulnerable authorization component and the impacted security model reside in the same authority; no trust boundary crossing to a separate component is assessed by NVD.
• Confidentiality (Low, C:L): disclosure is limited to the RBAC catalog (action and resource metadata), not monitored security telemetry or secrets.
• Integrity (None, I:N) and Availability (None, A:N): no data modification or service disruption.

Business impact hinges on what the leaked catalog enables. For enterprises running Wazuh as a core SIEM/HIDS, the RBAC action/resource catalog reveals the shape of the security management plane: which privileged operations exist and which protected resources they govern. That intelligence shortens the reconnaissance phase of an intrusion and improves the reliability of a follow-on privilege-escalation attempt. Blast radius is bounded to the confidentiality of the security model itself, but in a defense platform, exposing the defender's control-plane map carries outsized risk relative to the raw score. The CVSS assessment caps impact at Low confidentiality, so this should be prioritized as a medium-severity hardening item rather than an emergency response — with the caveat that urgency rises sharply if the same environment permits unrestricted API exposure or if low-tier accounts are widely distributed.

Affected systems: Wazuh deployments running versions 4.0.0 through 4.14.7 (fixed in 4.14.8 per the NVD version range). The provided data lists no OSV packages, no explicit affected-version array, and no vendor fix or workaround; version boundaries are taken verbatim from the NVD description. EPSS has not been scored by FIRST.org and no value is fabricated here. This CVE is not listed in CISA KEV.

Detection Guidance

Sigma Rule

title: Wazuh RBAC Catalog Disclosure via Unprotected Security Endpoints (CVE-2026-74032)
id: 8f2c1d7e-4a3b-4e9a-9c1d-74032cve0001
status: experimental
description: Detects authenticated requests to Wazuh management API endpoints GET /security/actions and GET /security/resources, which omit caller RBAC policies and disclose the RBAC catalog to low-privileged users.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-74032
author: valtersit.com
date: 2026/01/01
tags:
  - attack.discovery
  - attack.t1087
  - cve.2026.74032
logsource:
  category: webserver
  product: wazuh
detection:
  selection_method:
    cs-method: 'GET'
  selection_endpoint:
    cs-uri-stem|endswith:
      - '/security/actions'
      - '/security/resources'
  selection_status:
    sc-status: 200
  condition: selection_method and selection_endpoint and selection_status
falsepositives:
  - Legitimate administrative dashboards that enumerate RBAC actions and resources for authorized users.
  - Automated configuration management or compliance tooling that inventories Wazuh security objects.
level: medium

YARA Rule

rule CVE_2026_74032_Wazuh_RBAC_Disclosure
{
    meta:
        description = "Detects HTTP request/log artifacts referencing the unprotected Wazuh security endpoints associated with CVE-2026-74032"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-74032"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $ep1 = "/security/actions" ascii wide nocase
        $ep2 = "/security/resources" ascii wide nocase
        $api = "GET" ascii wide
        $rbac = "rbac" ascii wide nocase
        $sec = "/security/" ascii wide nocase

    condition:
        (any of ($ep1, $ep2)) and ($sec) and filesize < 5MB
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-74032 Wazuh RBAC Catalog Disclosure Attempt (GET /security/actions|/security/resources)"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"/security/actions"; nocase; http.uri; content:"/security/resources"; nocase; classtype:attempted-recon; reference:cve,2026-74032; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-74032; metadata:created_at 2026_01_01, updated_at 2026_01_01, confidence Medium; sid:202674032; rev:1;)

Elastic Detection

sequence by source.ip, user.name with maxspan=60s
  [ network where network.protocol == "http" and http.request.method == "GET" and endsWith(http.request.path, "/security/actions") ]
  [ network where network.protocol == "http" and http.request.method == "GET" and endsWith(http.request.path, "/security/resources") ]

Splunk SPL Query

index=wazuh OR index=proxy OR index=web
(http.url="*/security/actions" OR http.url="*/security/resources")
http_method=GET status=200
| stats count min(_time) as first_seen max(_time) as last_seen values(http.url) as requested_endpoints by src_ip user
| where count >= 2
| convert ctime(first_seen) ctime(last_seen)
| sort - count

Wazuh OSSEC Rule

<group name="wazuh,api,rbac,cve-2026-74032,">
  <rule id="100740" level="8">
    <decoded_as>json</decoded_as>
    <field name="url">/security/actions|/security/resources</field>
    <field name="method">GET</field>
    <description>CVE-2026-74032: Possible Wazuh RBAC catalog disclosure - GET request to unprotected security endpoint by low-privileged user.</description>
    <mitre>
      <id>T1087</id>
    </mitre>
    <group>access_control,cve-2026-74032,</group>
  </rule>

  <rule id="100741" level="10" frequency="2" timeframe="60">
    <if_matched_sid>100740</if_matched_sid>
    <same_source_ip />
    <description>CVE-2026-74032: Repeated enumeration of Wazuh RBAC action/resource catalog from the same source - possible privilege escalation reconnaissance.</description>
    <group>access_control,cve-2026-74032,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The NVD description frames the fixed boundary as "before 4.14.8," which identifies 4.14.8 as the remediation target version, but the provided intelligence contains no vendor advisory, commit hash, release note, or workaround. Do not treat 4.14.8 as confirmed-patched in absence of vendor confirmation; validate against the official Wazuh release channel.

Immediate mitigations (interim, while patch availability is confirmed):

1. Restrict network access to the Wazuh management API. Place the API behind firewall rules, VPN, or a zero-trust gateway so that only trusted administrative source IPs can reach it. This directly neutralizes AV:N exposure.
2. Reduce the population of low-privileged authenticated accounts. Since PR:L is the only precondition, eliminating broadly distributed minimal-tier credentials removes the attacker's foothold. Enforce least privilege and rotate credentials.
3. Do not rely on per-role filtering of these two endpoints as a control. Because the flaw is that RBAC policies are omitted on these routes, any compensating control must operate at the network/proxy layer (ingress filtering, authentication gateway), where the vulnerable endpoint logic cannot be bypassed.
4. Increase telemetry on /security/actions and /security/resources access and alert on requests from non-administrative principals (see Detection Guidance). Treat any successful GET to these endpoints by a low-privileged user as a potential reconnaissance event.
5. Audit existing low-tier accounts and service principals for signs of credential compromise, since valid authentication is the entire prerequisite for the disclosure.

Patch/upgrade steps:

1. Monitor the official Wazuh release channel and security advisories for the 4.14.8 release and an accompanying CVE reference.
2. When the fixed version is published, stage the upgrade in a non-production environment and verify that GET /security/actions and GET /security/resources now apply the caller's RBAC policies and return filtered results for low-privileged callers.
3. After verification, upgrade production manager/API instances to the fixed release, then re-enumerate with a low-privileged test account to confirm the catalog is no longer disclosed.
4. Because no patch evidence exists in tracked sources at the time of this report, treat upgrade timelines as contingent on vendor release and maintain interim mitigations until confirmation.

Long-term hardening:

1. Adopt centralized authorization enforcement so every API route, including enumeration endpoints, passes through mandatory policy evaluation by default (deny-by-default), eliminating the class of "forgotten filter on one route" defects.
2. Add automated authorization regression tests that assert low-privileged callers receive filtered responses on every security endpoint; run these in CI so missing policy checks fail the build.
3. Continuously enumerate and inventory exposed management interfaces; feed discovered API endpoints into attack-surface management so unintended public exposure is caught.
4. Segment security management planes from general corporate networks and require strong, phishing-resistant authentication for all API principals.
5. Track CVE-2026-74032 and related Wazuh advisories in your vulnerability management workflow; because EPSS is unscored and the CVE is not in KEV, prioritize by exposure (internet-reachable APIs) rather than by score alone.

References

• NVD — CVE-2026-74032: https://nvd.nist.gov/vuln/detail/CVE-2026-74032
• CWE-863 — Incorrect Authorization: https://cwe.mitre.org/data/definitions/863.html
• CWE-284 — Improper Access Control: https://cwe.mitre.org/data/definitions/284.html
• MITRE ATT&CK T1087 — Account Discovery: https://attack.mitre.org/techniques/T1087/
• Wazuh project (official site / security advisories): https://wazuh.com/ (vendor release notes for the 4.14.8 boundary referenced in the NVD description should be monitored here)

Threat actor / exploit-in-the-wild status: No public PoC, exploit code, or Nuclei template is available for CVE-2026-74032, and the CVE is not listed in CISA KEV. No threat actor campaigns or in-the-wild exploitation are known at the time of this report. FIRST.org has not yet assigned an EPSS score; no value is fabricated.