CVE-2026-48024: Wazuh: merged-file header path traversal in cluster sync allows arbitrary file write under WAZUH_PATH in Wazuh manager
Wazuh is a free and open source platform used for threat prevention, detection, and response. From 4.0.0 until 4.14.6 and 5.0.0-beta3, cluster.unmergeinfo() in framework/wazuh/core/cluster/cluster.py constructs paths from peer-controlled mergetype and name values in a merged synchronization archive. processfilesfromworker() in framework/wazuh/core/cluster/master.py does not adequately confine the resulting path to the declared cluster item directory. A cluster peer holding the shared Fernet key can use traversal in filesmetadata.json or a merged-file header to write files such as /var/ossec/etc/ossec.conf. Replacing ossec.conf can configure root-executed commands and lead to code execution when Wazuh services reload. This issue is fixed in versions 4.14.6 and 5.0.0-beta3.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 4.14.6 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 5.0.0-beta3
Event History
Frequently Asked Questions
Who can exploit this vulnerability?
An attacker needs to act as a Wazuh cluster peer and possess the shared Fernet key. The issue is therefore relevant to deployments using cluster synchronization where a peer or the shared key has been compromised.
What is the practical impact of successful exploitation?
A malicious cluster peer can use traversal values in synchronization metadata or merged-file headers to write files under WAZUH_PATH, including /var/ossec/etc/ossec.conf. Replacing that configuration can configure commands that execute as root when Wazuh services reload.
Which versions need remediation?
Affected versions are Wazuh 4.0.0 through versions before 4.14.6, and 5.0.0-beta versions before 5.0.0-beta3. The issue is fixed in 4.14.6 and 5.0.0-beta3.
What should be investigated if compromise is suspected?
Investigate whether any cluster peer or the shared Fernet key may have been compromised, and inspect synchronization archives and metadata for traversal-style merge_type or name values. Also review /var/ossec/etc/ossec.conf for unauthorized changes, especially command configurations that could run during service reload.