Wazuh CVE-2026-44255

The Wazuh REST API authentication endpoint must be reachable by the attacker - this is its intended network-accessible deployment mode, so no non-default configuration is required. The vulnerability triggers on any authentication attempt regardless of the password supplied; no account, session token, or special credential is needed. What limits exploitation is the quality of the attacker's username wordlist (only existing Wazuh-local user accounts are detectable; external LDAP or SSO identities may not be affected depending on the integration path) and network conditions (high-jitter or high-latency paths increase measurement noise, though the bcrypt signal remains dominant in most network environments). Deployments that restrict API access to internal or VPN-only networks reduce exposure significantly by eliminating unauthenticated remote reach.

The NVD CVSS 3.1 score of 5.3 Medium (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) accurately reflects the isolated impact of username enumeration - confidentiality is partially compromised, but integrity and availability are unaffected. The attack complexity is genuinely low because bcrypt's intentional slowness produces a signal roughly two to three orders of magnitude above typical network jitter, making the timing side-channel reliable even over the public internet. No CISA KEV entry exists, and no public proof-of-concept has been identified, keeping near-term exploitation risk moderate. However, this vulnerability serves as a force-multiplier for credential attacks: an adversary who maps all valid Wazuh operator accounts can tightly focus brute-force or password-spray attempts, dramatically reducing lockout risk and increasing attack efficiency. Wazuh deployments that expose the API to the internet or to untrusted internal segments carry measurably higher real-world risk than air-gapped or VPN-restricted deployments. The EPSS signal is not provided, so exploitation probability cannot be quantified from available data.

An attacker with network access to the Wazuh API sends a series of POST authentication requests - first with known-invalid random strings as usernames, establishing a baseline response-time distribution, then with common admin usernames ('admin', 'wazuh', 'wazuh-wui', operator names from LinkedIn or job postings). Requests for valid usernames consistently return 100-300 ms later due to bcrypt computation, while invalid usernames return in under 5 ms. After identifying valid accounts, the attacker launches a targeted password-spray campaign using common or breached credentials against only the confirmed usernames. No exploit code is required - standard HTTP timing tooling such as curl with response-time measurement or dedicated timing-attack frameworks suffices.