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.unmerge_info() in framework/wazuh/core/cluster/cluster.py constructs paths from peer-controlled merge_type and name values in a merged synchronization archive. process_files_from_worker() 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 files_metadata.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.
Security readout for executives and security teams
Plain-English summary
A trusted or compromised Wazuh cluster peer possessing the shared cluster key can escape intended synchronization directories and overwrite manager files. Overwriting configuration may introduce commands executed as root after services reload, potentially compromising the Wazuh manager and disrupting security monitoring.
Executive priority
Treat as an urgent remediation for affected clustered deployments, especially where peer trust or key custody is uncertain. The access prerequisite reduces broad internet exposure, but compromise could grant root-level control over a central security-management system. Prioritize version verification and upgrade without waiting for exploitation evidence.
Technical view
In affected releases, cluster.unmerge_info() builds paths from peer-controlled merged-archive metadata, while process_files_from_worker() insufficiently confines writes to the declared cluster item directory. Traversal can write beneath WAZUH_PATH, including ossec.conf. Malicious configuration changes may produce root-level code execution upon service reload.
Likely exposure
Exposure applies to Wazuh clusters running 4.0.0 through 4.14.5 or 5.0.0-beta1 through beta2. Exploitation requires a cluster peer with the shared Fernet key. The supplied sources do not describe standalone deployments as affected through another path.
Exploitation context
No active exploitation is established by the supplied sources, and the CVE is not identified as being in KEV. The prerequisite is significant but realistic after compromise of a trusted cluster peer or disclosure of the shared Fernet key. Successful exploitation could escalate to root-level execution.
Researcher notes
The critical boundary failure spans merged-file path construction and master-side write confinement. Relevant inputs are merge_type, name, files_metadata.json, and merged-file headers. Analysis should focus on canonical path validation and enforcement at the final write boundary. The supplied evidence establishes impact and fixes, but not active exploitation.
Mitigation direction
Upgrade affected 4.x deployments to Wazuh 4.14.6 or later.
Upgrade affected 5.0 beta deployments to 5.0.0-beta3 or later.
Apply the fixed version consistently across relevant cluster systems.
Consult the Wazuh advisory for deployment-specific upgrade and operational guidance.
Validation and detection
Inventory Wazuh manager and cluster-peer versions against the affected ranges.
Confirm every relevant 4.x system runs 4.14.6 or later.
Confirm every relevant 5.0 beta system runs beta3 or later.
Review cluster membership and access to the shared Fernet key.
Investigate unexpected changes to ossec.conf and other files beneath WAZUH_PATH.
Review service reloads and subsequent privileged activity for suspicious behavior.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · medium confidence lookup
CWE-22: File access and web shell behavior lookup
File traversal and upload weaknesses can lead teams to review file, web shell, execution, and collection telemetry. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references code or command execution, so execution technique review may help defensive triage. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
The CVE wording references file access or upload behavior, so file telemetry and web shell review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
6Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: pocAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.