Wazuh Manager EUVD-2026-98670

Requires an authenticated low-privileged user account on the Wazuh Manager API (PR:L) - not a remote-unauthenticated flaw. The attacker must issue GET requests specifically to the /security/actions and /security/resources endpoints, which fail to apply the caller's RBAC policies. No user interaction and no non-default configuration are needed, so any environment with multiple API users of differing privilege levels is affected. Limiting factors: valid credentials are mandatory, the impact is confined to read-only disclosure of the RBAC catalog (no data modification or service disruption), and the leaked information only facilitates - rather than directly achieves - privilege escalation.

This is a medium-severity information-disclosure flaw, not a high-priority emergency. The vendor-provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N) scores 5.3 and is internally consistent with the description: network-reachable, low attack complexity, but requiring an already-authenticated low-privileged account (PR:L), with only low confidentiality impact and zero integrity/availability impact. No EPSS score was provided, the CVE is not listed in CISA KEV, and no public exploit code is referenced, so there is no public exploit identified at time of analysis. The practical danger is reconnaissance rather than direct compromise - it leaks the RBAC catalog (available actions and resources) that aids privilege-escalation planning, but does not itself grant elevated access. The one caveat worth flagging: the v4.14.8 release notes shown do not explicitly itemize this RBAC authorization-bypass fix, so the fix-version linkage rests on the GHSA advisory and VulnCheck report rather than an itemized changelog entry. Net assessment: a real but lower-urgency issue valuable mainly as a stepping stone in a chained attack by an insider or an attacker who already holds valid low-privilege credentials.

An attacker who already holds a valid low-privileged Wazuh Manager API account (for example a limited analyst or a compromised service account) sends GET requests to /security/actions and /security/resources. Because these endpoints omit the caller's RBAC policy enforcement, the attacker receives the full catalog of privileged actions and endpoints, which they use to map targets for a follow-on privilege-escalation attempt. No public exploit code is identified at time of analysis, but exploitation requires only standard authenticated API calls with no special tooling.