Skip to main content
OneCon26: Gain the advantage in the AI era. Oct. 20–22 in Las Vegas.Register Now
CVE Vulnerability Database
Vulnerability Database/CVE-2026-48162

CVE-2026-48162: Wazuh Privilege Escalation Vulnerability

CVE-2026-48162 is a privilege escalation flaw in Wazuh that allows cluster peers to read sensitive files and forge administrator tokens. This post explains the technical details, affected versions, impact, and mitigation.

Updated:

CVE-2026-48162 Overview

CVE-2026-48162 is a path traversal vulnerability in Wazuh, an open source threat prevention, detection, and response platform. The flaw resides in the DistributedAPI.send_tmp_file() function in framework/wazuh/core/cluster/dapi/dapi.py. The function joins an attacker-controlled tmp_file value to WAZUH_PATH without canonicalization or directory confinement. A cluster peer holding the shared Fernet key can supply a traversal sequence or absolute path to make the master node return any file readable by the Wazuh process. The vulnerability affects Wazuh versions 4.0.0 through 4.14.5 and the 5.0.0-beta releases before 5.0.0-beta3.

Critical Impact

An authenticated cluster peer can read /var/ossec/api/configuration/security/private_key.pem and forge administrator REST API tokens offline, gaining full administrative privileges without creating an account.

Affected Products

  • Wazuh 4.0.0 through 4.14.5
  • Wazuh 5.0.0-beta1 and 5.0.0-beta2
  • Wazuh cluster deployments sharing a Fernet key across worker and master nodes

Discovery Timeline

Technical Details for CVE-2026-48162

Vulnerability Analysis

Wazuh cluster nodes coordinate over an encrypted channel keyed by a shared Fernet secret. Worker nodes may forward API requests that reference temporary files stored under /var/ossec/tmp on the master. The send_tmp_file() method constructed the target path by concatenating common.WAZUH_PATH with the attacker-controlled tmp_file argument. Because the resulting path was neither canonicalized with os.path.realpath() nor confined to the temporary directory, a malicious peer could inject ../ sequences or an absolute path such as /var/ossec/api/configuration/security/private_key.pem. The master then transmitted the requested file back over the cluster channel. This constitutes an external control of file name or path issue tracked as [CWE-73].

Root Cause

The root cause is missing path validation. The original implementation trusted the tmp_file parameter provided by a peer node and passed it directly to client.send_file() and os.remove(). Any peer with the Fernet key was effectively granted read primitive access to the master's filesystem within the Wazuh process privileges.

Attack Vector

An attacker who controls a worker node, or who has otherwise obtained the shared cluster Fernet key, sends a distributed API request specifying tmp_file as a traversal string. The master reads and returns the referenced file. By exfiltrating the REST API private key, the attacker forges signed JWT tokens with administrator claims and issues privileged API calls from outside the cluster without needing an account.

python
     async def send_tmp_file(self, node_name=None):
         # POST/agent/group/:group_id/configuration and POST/agent/group/:group_id/file/:file_name API calls write
         # a temporary file in /var/ossec/tmp which needs to be sent to the master before forwarding the request
+        tmp_file = self.f_kwargs.get('tmp_file', '')
+        if not tmp_file:
+            raise exception.WazuhClusterError(3034, extra_message='tmp_file parameter is required')
+
+        tmp_path = os.path.join(common.OSSEC_TMP_PATH, tmp_file)
+        resolved_path = os.path.realpath(tmp_path)
+
+        allowed_tmp_dir = os.path.realpath(common.OSSEC_TMP_PATH)
+        if not resolved_path.startswith(allowed_tmp_dir + os.sep) and resolved_path != allowed_tmp_dir:
+            raise exception.WazuhClusterError(3034,
+                extra_message=f'Invalid tmp_file path: {tmp_file}. Path must be within tmp directory')
+
         client = self.get_client()
-        res = json.loads(await client.send_file(os.path.join(common.WAZUH_PATH,
-                                                             self.f_kwargs['tmp_file']),
-                                                node_name),
+        res = json.loads(await client.send_file(resolved_path, node_name),
                          object_hook=c_common.as_wazuh_object)
-        os.remove(os.path.join(common.WAZUH_PATH, self.f_kwargs['tmp_file']))
+        os.remove(resolved_path)

Source: GitHub Commit de1eeed. The patch rebases the path onto OSSEC_TMP_PATH, resolves symlinks, and rejects any resolved path that escapes the allowed directory.

Detection Methods for CVE-2026-48162

Indicators of Compromise

  • Cluster protocol messages containing tmp_file values with ../ sequences or absolute paths outside /var/ossec/tmp
  • Unexpected reads of /var/ossec/api/configuration/security/private_key.pem by the wazuh process
  • REST API authentication events using administrator tokens that were not issued by the master's token endpoint
  • Worker node processes accessing files outside their normal working directories

Detection Strategies

  • Inspect cluster logs for send_tmp_file invocations referencing paths outside /var/ossec/tmp
  • Compare issued JWT jti values recorded by the API against tokens observed on inbound authenticated requests
  • Alert on any file access to the API private key outside of Wazuh manager startup routines

Monitoring Recommendations

  • Enable auditd rules on /var/ossec/api/configuration/security/private_key.pem to record all read operations
  • Forward Wazuh cluster and API logs to a central data lake for correlation
  • Monitor for API tokens presenting administrator claims from source IPs that are not registered cluster peers

How to Mitigate CVE-2026-48162

Immediate Actions Required

  • Upgrade all Wazuh manager and worker nodes to 4.14.6 or 5.0.0-beta3
  • Rotate the cluster Fernet key defined in ossec.conf after patching
  • Regenerate the REST API signing key at /var/ossec/api/configuration/security/private_key.pem and revoke existing tokens
  • Audit historical cluster traffic and API access logs for signs of exploitation

Patch Information

The fix is available in Wazuh 4.14.6 and Wazuh 5.0.0-beta3. Details are published in GHSA-r6f5-h662-8ffc and merged via Pull Request 36246.

Workarounds

  • Restrict cluster network exposure so that only trusted management hosts can reach the cluster port
  • Enforce mutual TLS or network-layer authentication between cluster peers where feasible
  • Limit filesystem permissions on /var/ossec/api/configuration/security/ so the API key is only readable by the API service account
bash
# Verify installed Wazuh version and upgrade
/var/ossec/bin/wazuh-control info | grep WAZUH_VERSION
apt-get update && apt-get install --only-upgrade wazuh-manager=4.14.6-1

# Rotate the REST API signing key after upgrade
systemctl stop wazuh-manager
rm /var/ossec/api/configuration/security/private_key.pem
systemctl start wazuh-manager

# Restrict access to the API key material
chmod 600 /var/ossec/api/configuration/security/private_key.pem
chown wazuh:wazuh /var/ossec/api/configuration/security/private_key.pem

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.

Try SentinelOne