CVE-2026-44255: Wazuh Auth Bypass Vulnerability

CVE-2026-44255 Overview

CVE-2026-44255 is a timing-based information disclosure vulnerability in Wazuh, an open source threat prevention, detection, and response platform. The flaw resides in the AuthenticationManager.check_user() function in framework/wazuh/rbac/orm.py. The function calls check_password_hash() only when the supplied username exists in the database. A nonexistent username returns immediately, while a valid username triggers an expensive bcrypt calculation. An unauthenticated remote attacker can measure authentication response times to enumerate valid Wazuh usernames. This information can then fuel credential stuffing, password spraying, and targeted brute-force campaigns. The issue affects versions 4.0.0 through 4.14.5 and 5.0.0-beta1, and is classified under [CWE-208] Observable Timing Discrepancy.

Critical Impact
Unauthenticated remote attackers can enumerate valid Wazuh usernames by comparing authentication response times, enabling targeted follow-on credential attacks.

Affected Products

Wazuh versions 4.0.0 through 4.14.5
Wazuh 5.0.0-beta1
Wazuh RBAC authentication component (framework/wazuh/rbac/orm.py)

Discovery Timeline

2026-08-19 - CVE-2026-44255 published to NVD
2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-44255

Vulnerability Analysis

The vulnerability is an observable timing discrepancy in the Wazuh role-based access control (RBAC) authentication path. When a client submits credentials, AuthenticationManager.check_user() first queries the database for the supplied username. If the record does not exist, the function returns immediately without performing any hashing work. If the record exists, the function invokes check_password_hash(), which executes a computationally expensive bcrypt verification.

This conditional workload creates a measurable side channel. An unauthenticated attacker on the network can submit authentication attempts against a candidate username list and record the server response time for each attempt. Requests for existing accounts take significantly longer than those for nonexistent accounts. The attacker can then compile a list of valid usernames without any credentials or prior access.

Valid usernames narrow the attack surface for follow-on credential attacks. Attackers can use the enumerated list for password spraying, credential stuffing with breach corpora, or targeted phishing against administrators of the Wazuh security platform.

Root Cause

The root cause is a non-constant-time authentication code path. The design executes password verification only when the username is known, so the presence or absence of the record leaks through the response latency. Constant-time authentication requires performing an equivalent bcrypt calculation regardless of whether the username exists.

Attack Vector

Exploitation requires only network access to the Wazuh API. The attacker sends a series of authentication requests with candidate usernames and measures the elapsed time for each response. Requests that trigger bcrypt verification take substantially longer than requests that short-circuit. No credentials, prior authentication, or user interaction are required.

python

# Security patch in framework/wazuh/rbac/orm.py
 MAX_ID_RESERVED = 99
 CLOUD_RESERVED_RANGE = 89
 
+# Dummy hash for constant-time username enumeration protection
+_DUMMY_HASH = generate_password_hash("wazuh-dummy-constant-never-matches-any-real-password")
+
 # Start a session and set the default security elements
 DB_FILE = os.path.join(SECURITY_PATH, "rbac.db")
 DB_FILE_TMP = f"{DB_FILE}.tmp"
# Source: https://github.com/wazuh/wazuh/commit/5ecea7b38b998407cb0d205467dd247140a0f981

The patch introduces a precomputed _DUMMY_HASH value. When a submitted username does not exist, the code now runs check_password_hash() against the dummy hash to equalize execution time with the valid-user path.

Detection Methods for CVE-2026-44255

Indicators of Compromise

High volumes of failed authentication attempts against the Wazuh API originating from a single source or narrow IP range.
Sequential authentication requests iterating through common username patterns such as admin, wazuh, root, or organizational naming conventions.
Repeated login attempts with consistent inter-request timing suggestive of automated timing measurement.

Detection Strategies

Monitor Wazuh API authentication logs for enumeration patterns, including bursts of requests with unique usernames and no successful authentications.
Correlate response-time anomalies with source IP behavior to identify timing-analysis probes.
Alert on authentication attempts against nonexistent user accounts that exceed baseline thresholds.

Monitoring Recommendations

Enable verbose logging on the Wazuh RBAC and API subsystems to capture authentication attempts with usernames and outcomes.
Forward Wazuh API logs to a central SIEM for cross-source correlation and long-window baselining.
Track authentication failure rates per source IP and alert when they exceed operational norms.

How to Mitigate CVE-2026-44255

Immediate Actions Required

Upgrade Wazuh to version 4.14.6 or 5.0.0-beta2, which introduce constant-time authentication handling.
Restrict network access to the Wazuh API to trusted management networks and administrative bastions.
Review authentication logs for prior enumeration activity and rotate credentials for exposed accounts.

Patch Information

The fix is available in Wazuh Release v4.14.6 and Wazuh Release v5.0.0-beta2. The code change is documented in the GitHub commit, the pull request discussion, and GitHub Security Advisory GHSA-3978-44q9-9px9.

Workarounds

Place the Wazuh API behind a reverse proxy or VPN that enforces authentication and rate limiting before requests reach the backend.
Apply strict rate limiting and IP-based throttling on authentication endpoints to slow timing analysis.
Use non-obvious administrative usernames to reduce the effectiveness of dictionary-based enumeration.

bash

# Upgrade Wazuh manager to a patched release
sudo apt-get update
sudo apt-get install wazuh-manager=4.14.6-1
sudo systemctl restart wazuh-manager

# Verify the installed version
/var/ossec/bin/wazuh-control info | grep WAZUH_VERSION