CVE-2025-24016

What it actually does

This is an unsafe deserialization vulnerability in Wazuh server-side components that can allow remote code execution when a crafted serialized object is processed. Exploitation requires a path to submit data to the Wazuh API or trusted Wazuh server/cluster communication channel; in some deployments, a compromised Wazuh agent may also be able to trigger the vulnerable code path. Successful exploitation can execute attacker-controlled commands with the privileges of the affected Wazuh service process, enabling full compromise of the Wazuh manager or cluster node and potential tampering with security monitoring data.

Why it matters to the business

A compromised Wazuh server can undermine a core security monitoring platform: attackers may disable or manipulate detections, hide activity, access sensitive telemetry, pivot to connected systems, or use the server as an internal execution point. The CVSS score is critical, EPSS is very high, exploitation is active in the wild, and the issue is listed in CISA KEV with a remediation due date of 2025-07-01, making remediation urgent for internet-exposed, API-accessible, clustered, or agent-connected Wazuh deployments.

How an attack unfolds

An attacker first obtains a viable route to the vulnerable Wazuh server component, commonly through stolen or compromised Wazuh API credentials, compromise of the Wazuh dashboard, compromise of another Wazuh server in the cluster, or, in certain configurations, compromise of a connected agent. The attacker then sends a crafted serialized payload through the trusted API or cluster/agent communication path. When the Wazuh server deserializes the untrusted object, embedded execution logic is invoked, causing arbitrary commands to run under the Wazuh service account. The attacker can then establish persistence, collect credentials or security telemetry, alter Wazuh configuration or rules, suppress alerts, deploy additional tooling, and pivot to systems reachable from the Wazuh server. Public exploitation has been observed, so exposed systems should be treated as high-priority incident-response candidates until patched and reviewed.

How to fix it

Upgrade Wazuh to a version or build containing the upstream fix, specifically including commit 030da3527b7031348ae3f686aae663621d981c26 for wazuh/wazuh source-based deployments. For Red Hat Enterprise Linux 8 AppStream packages listed in the advisory, update NetworkManager-related packages to 1:1.40.16-18.el8_10 or later where applicable. Because this vulnerability is actively exploited and listed in CISA KEV, prioritize patching immediately rather than waiting for a normal maintenance cycle. If immediate upgrade is not possible, restrict Wazuh API access to trusted administrative networks only, rotate Wazuh API credentials and integration tokens, review dashboard access, isolate Wazuh cluster communication to known nodes, limit agent enrollment and agent-to-manager trust where possible, and monitor or temporarily disable nonessential API exposure. After patching, restart affected Wazuh services and verify all cluster nodes are running fixed code; mixed-version clusters should not be considered fully remediated.

How to confirm the fix worked

Confirm the installed Wazuh build includes commit 030da3527b7031348ae3f686aae663621d981c26 or a vendor release that incorporates it. On package-managed systems, verify the relevant fixed package versions are installed, including Red Hat Enterprise Linux 8 AppStream NetworkManager packages at 1:1.40.16-18.el8_10 or later where applicable. Validate that every Wazuh manager and cluster node has been upgraded, restarted, and rejoined the cluster cleanly. Confirm Wazuh API exposure is limited to approved administrative sources and that authentication is enforced. Review Wazuh API, cluster, manager, operating system, and EDR logs for evidence of unexpected requests, deserialization errors, abnormal child processes, or command execution from Wazuh service processes before declaring remediation complete.

Typical attack path

1. Identify a Wazuh manager, dashboard, API endpoint, cluster node, or agent communication path that can reach the vulnerable server-side component.
2. Obtain access to a trusted channel, such as Wazuh API credentials, a compromised dashboard, a compromised cluster node, or in some configurations a compromised agent.
3. Submit a malicious serialized payload to the vulnerable Wazuh server component.
4. Trigger unsafe deserialization on the Wazuh server, resulting in command execution under the Wazuh service context.
5. Run post-exploitation commands to enumerate the host, collect secrets, or download additional payloads.
6. Modify Wazuh configuration, rules, logs, or agent management settings to evade detection or maintain control.
7. Use the compromised Wazuh server as a trusted internal pivot point to access additional infrastructure.

How to detect it

Investigate whether the vulnerability was already exploited by correlating Wazuh API logs, Wazuh manager logs, cluster logs, operating system process telemetry, authentication logs, and EDR events. Focus on the period before patching and any time since 2025-04-22, with special priority for systems exposed to dashboards, API users, cluster peers, or agents. Look for unusual Wazuh API requests from unexpected sources, failed or anomalous authentication followed by successful API activity, cluster messages from unrecognized nodes, deserialization or exception traces in Wazuh logs, and Wazuh service processes spawning command shells or download utilities. On Linux hosts, review auditd, syslog, process accounting, shell history where available, cron/systemd persistence locations, new files in temporary directories, and outbound network connections initiated by Wazuh processes. Also review Wazuh content integrity: unauthorized edits to rules, decoders, integrations, active response scripts, agent enrollment artifacts, API users, and configuration files may indicate post-exploitation tampering. Because exploitation may originate from a compromised dashboard, peer Wazuh server, or agent, detections should not rely only on internet-facing source IPs.

• /var/ossec/logs/api.log
• /var/ossec/logs/ossec.log
• /var/ossec/logs/cluster.log
• /var/ossec/etc/ossec.conf
• /var/ossec/etc/shared/
• /var/ossec/active-response/bin/
• /var/ossec/integrations/
• /var/ossec/ruleset/
• /tmp/
• /var/tmp/
• /dev/shm/
• wazuh-apid
• wazuh-manager
• wazuh-clusterd
• wazuh-execd
• ossec-execd
• wazuh-modulesd
• wazuh-db
• /bin/sh
• /bin/bash
• python -c
• python3 -c
• perl -e
• curl http
• curl -k
• wget http
• nc -e
• ncat -e
• bash -i
• /etc/cron.d/
• /var/spool/cron/
• /etc/systemd/system/
• authorized_keys

What your security team should do

• Patch or upgrade all Wazuh managers and cluster nodes immediately; this issue is KEV-listed, actively exploited, and has a very high EPSS score.
• Treat any unpatched Wazuh server with API, dashboard, cluster, or agent reachability as potentially exposed and perform compromise assessment before and after upgrading.
• Restrict Wazuh API and cluster communication to known trusted hosts using firewalls, security groups, VPN controls, or equivalent network policy.
• Rotate Wazuh API credentials, dashboard credentials, service tokens, and integration secrets, especially where exposure or compromise is suspected.
• Hunt for Wazuh service processes spawning shells, scripting engines, network download tools, or other unusual child processes.
• Review Wazuh configuration, rules, decoders, integrations, agent enrollment settings, and alerting pipelines for unauthorized changes.
• Verify all Wazuh cluster members are fixed; do not rely on patching only the primary node in clustered deployments.
• Increase monitoring for suspicious activity from Wazuh server IP addresses because the platform may be used as a trusted pivot point after exploitation.