CVE-2025-24016: Wazuh Server Deserialization of Untrusted Data Vulnerability
Wazuh · Wazuh Server · NVD published 2025-02-11 · posted 2025-06-10 · last modified 2026-06-17
What it is
Wazuh is a free and open source platform used for threat prevention, detection, and response. Starting in version 4.4.0 and prior to version 4.9.1, an unsafe deserialization vulnerability allows for remote code execution on Wazuh servers. DistributedAPI parameters are a serialized as JSON and deserialized using `as_wazuh_object` (in `framework/wazuh/core/cluster/common.py`). If an attacker manages to inject an unsanitized dictionary in DAPI request/response, they can forge an unhandled exception (`__unhandled_exc__`) to evaluate arbitrary python code. The vulnerability can be triggered by anybody with API access (compromised dashboard or Wazuh servers in the cluster) or, in certain configurations, even by a compromised agent. Version 4.9.1 contains a fix.
| Weakness | CWE-502 |
|---|---|
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:H (source: [email protected]) |
| CISA due date | 2025-07-01 (for US federal agencies under BOD; a good deadline for everyone) |
| ATT&CK tactics | Initial Access → Persistence → Privilege Escalation → Stealth → Execution |
Exploitation evidence
First exploit evidence seen: 2025-02-10 (earliest date across the sources below).
Exploited in the wild
- CISA KEV: listed since 2025-06-10. Source
Public exploit code
Metasploit
exploit/linux/http/wazuh_auth_rce_cve_2025_24016: Wazuh server remote code execution caused by an unsafe deserialization vulnerability. (disclosure 2025-02-10)
GitHub proof-of-concept repositories
8 public repositories from 8 accounts, first seen 2025-02-13. Most starred: 0xjessie21/CVE-2025-24016 (43 stars), view repository.
Verify before running: public PoCs can be malicious. Read the code and only run it in an isolated lab. A PoC means exploit code is public, not that this CVE is exploited in the wild.
Sources: CISA KEV · Rapid7 Metasploit Framework module metadata · nomi-sec/PoC-in-GitHub.
Defend the Chain
The attack chain for CVE-2025-24016 laid across the MITRE ATT&CK Enterprise tactics. Solid cards come from the MITRE CTID KEV mappings; dashed cards are inferred by CVERadar from the CWE or description. Correct defences are real ATT&CK mitigations for that technique.
Pick a red technique card on the board, then choose the defence that stops it.
Defend against T1078 Valid Accounts CTID: exploitation technique
Attackers with API access have been reported as exploiting this vulnerability through a JSON payload sent to a Wazuh worker server. Requests relayed to the master server can result in arbitrary code execution.
How to fix it
CISA required action
Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable. (source: CISA KEV)
Fixed versions
- wazuh wazuh: upgrade to 4.9.1 or later (affected from 4.4.0)
Derived from the NVD CPE configuration (versionEndExcluding / versionEndIncluding). Always confirm with the vendor advisory.
Vendor advisories and patches
- https://wazuh.com/blog/addressing-the-cve-2025-24016-vulnerability/ (CISA KEV notes)
- https://github.com/wazuh/wazuh/security/advisories/GHSA-hcrc-79hj-m3qh (CISA KEV notes)
MITRE ATT&CK mitigations for this chain
- M1027 Password Policies (for T1078) : Applications and appliances that utilize default username and password should be changed immediately after the installation, and before deployment to a production environment. When possible, applications that use SSH keys should be updated periodically and properly secured. Policies should minimize (if not eliminate)
- M1018 User Account Management (for T1078) : Regularly audit user accounts for activity and deactivate or remove any that are no longer needed.
- M1026 Privileged Account Management (for T1078, T1059) : Audit domain and local accounts as well as their permission levels routinely to look for situations that could allow an adversary to gain wide access by obtaining credentials of a privileged account. These audits should also include if default accounts have been enabled, or if new local accounts are created that have
- M1032 Multi-factor Authentication (for T1078) : Implement multi-factor authentication (MFA) across all account types, including default, local, domain, and cloud accounts, to prevent unauthorized access, even if credentials are compromised. MFA provides a critical layer of security by requiring multiple forms of verification beyond just a password. This measure sign
- M1013 Application Developer Guidance (for T1078) : Ensure that applications do not store sensitive data or credentials insecurely. (e.g. plaintext credentials in code, published credentials in repositories, or credentials in public cloud storage).
- M1017 User Training (for T1078) : Applications may send push notifications to verify a login as a form of multi-factor authentication (MFA). Train users to only accept valid push notifications and to report suspicious push notifications.
- M1015 Active Directory Configuration (for T1078) : Disable legacy authentication, which does not support MFA, and require the use of modern authentication protocols instead.
- M1036 Account Use Policies (for T1078) : Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges.
- M1050 Exploit Protection (for T1203) : Security applications that look for behavior used during exploitation such as Windows Defender Exploit Guard (WDEG) and the Enhanced Mitigation Experience Toolkit (EMET) can be used to mitigate some exploitation behavior. Control flow integrity checking is another way to potentially identify and stop a software exploi
- M1051 Update Software (for T1203) : Perform regular software updates to mitigate exploitation risk. Keeping software up-to-date with the latest security patches helps prevent adversaries from exploiting known vulnerabilities in client software, reducing the risk of successful attacks.
Detection Generic guidance
- Initial Access: Alert on unusual requests to the affected service (odd paths, oversized payloads, exploit strings) in WAF, reverse-proxy and application logs.
- Persistence: Look for new files in web roots, new scheduled tasks/services, and new accounts created after the exposure window.
- Privilege Escalation: Alert on processes gaining SYSTEM/root unexpectedly, and on exploitation crashes of privileged services.
- Execution: Watch for the service process spawning shells or script interpreters (cmd.exe, powershell, sh, bash, python) via EDR process-tree rules.
Response checklist Generic guidance
- Inventory: find every instance of the affected product and version (include internet-facing and forgotten ones).
- Patch or mitigate per the vendor advisory; if you cannot patch, remove internet exposure or apply the vendor workaround.
- Assume compromise if the system was exposed before patching: hunt for the indicators in the advisory and review logs back to the disclosure date.
- Rotate credentials and secrets stored on or used by the affected system if compromise cannot be ruled out.