CVE-2026-32983: 
Wazuh Server vulnerability analysis and mitigation

CVE-2026-32983 is a denial-of-service vulnerability in the Wazuh Manager authd service caused by improper restriction of client-initiated SSL/TLS renegotiation. Remote, unauthenticated attackers can send excessive renegotiation requests over a single TLS connection to exhaust CPU resources and render the authd service unavailable. The vulnerability affects wazuh-manager packages (both .deb and .rpm) through version 4.7.3; version 4.8.0 and later are patched (GitHub Advisory). It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 6.9 (Medium) (Feedly).

The root cause is the absence of renegotiation limits in the OpenSSL-backed authd service, which listens on TCP port 1515 for agent registration. This maps to CWE-276 (Incorrect Default Permissions) as classified by the assigner, though the functional weakness is more precisely an unrestricted client-initiated TLS renegotiation. An attacker establishes a TLS connection to port 1515 and repeatedly triggers renegotiation (e.g., by sending the R command via openssl s_client), forcing the server to perform expensive cryptographic operations for each request without any rate limiting or count cap. A proof-of-concept demonstrating the issue was included in the GitHub Security Advisory: echo R | openssl s_client -connect <host>:1515 confirms that "Secure Renegotiation IS supported" with no server-side restriction (GitHub Advisory).

Successful exploitation causes a denial of service against the Wazuh Manager authd service, which handles agent registration on port 1515. By consuming excessive CPU resources, an attacker can make the service unresponsive, preventing new Wazuh agents from registering and potentially disrupting security monitoring coverage across the environment. There is no impact on confidentiality or integrity — the attack is limited to availability (GitHub Advisory, Feedly).

1. Reconnaissance: Identify internet-facing or network-accessible Wazuh Manager instances running version 4.7.3 or earlier. Scan for TCP port 1515 using tools like Nmap (nmap -p 1515 <target>).
2. Verify TLS renegotiation support: Connect to the authd service and confirm renegotiation is enabled: openssl s_client -connect <target>:1515. Look for "Secure Renegotiation IS supported" in the output.
3. Trigger repeated renegotiation: Send the renegotiation command repeatedly within a single connection. The PoC uses: echo R | openssl s_client -connect <target>:1515. Automate this in a loop or script to send hundreds or thousands of renegotiation requests.
4. Exhaust CPU resources: The server performs expensive cryptographic handshake operations for each renegotiation without any rate limit, causing CPU saturation and rendering the authd service unresponsive to legitimate agent registration requests (GitHub Advisory).

• Network: High volume of TLS connections or sustained connections to TCP port 1515 from a single or small set of source IPs; repeated TLS handshake/renegotiation traffic patterns on port 1515 without completing agent registration.
• System: Sustained high CPU utilization on the Wazuh Manager host, particularly in processes associated with wazuh-authd.
• Logs: Wazuh Manager logs (/var/ossec/logs/ossec.log) showing repeated or failed agent registration attempts from the same source; OpenSSL or TLS renegotiation events logged in connection with port 1515 activity.
• Process: wazuh-authd process consuming abnormally high CPU as observed via top or ps; service becoming unresponsive to legitimate agent enrollment requests (GitHub Advisory).

Upgrade wazuh-manager to version 4.8.0 or later, which includes a fix for this vulnerability (GitHub Advisory). As a network-level workaround, restrict access to TCP port 1515 using firewall rules to allow only trusted agent IP ranges, reducing the attack surface for unauthenticated remote exploitation. Organizations unable to upgrade immediately should monitor CPU utilization on the Wazuh Manager and consider rate-limiting connections to port 1515 at the network perimeter.

The vulnerability was originally discovered through a Greenbone OpenVAS scan and reported via the Wazuh GitHub Security Advisory program, published on January 13, 2025 (GitHub Advisory). The CVE was formally assigned and published by VulnCheck in March 2026. No significant broader media coverage or notable researcher commentary beyond the official advisory has been identified.