[CVE-2025-62792] Wazuh Buffer Over-Read Lets Compromised Agents Sneak a Peek at Manager Memory

TL;DR
All Wazuh managers up to version 4.11.2 trust that the str_test field they copy out of an agent message is correctly NULL-terminated. If a malicious agent omits the trailing byte, the w_expression_match() helper over-reads the heap and leaks whatever happens to sit right after the buffer. Upgrading to 4.12.0 eliminates the issue by allocating an extra byte and hard-terminating the string before matching begins.

1. Summary

A hostile agent under an attacker’s control can craft a single log message that tricks the manager into reading data that sits just beyond the allocated heap chunk. The disclosure may include pieces of other log entries, pending event data or even authentication tokens kept nearby in memory. Because Wazuh fleets often aggregate logs from hundreds of hosts, the blast radius grows with every agent that eventually falls to an attacker.

2. Context – Why an agent-side read matters on a security platform

Wazuh prides itself on secure communication channels between agents and the central manager. TLS protects data in transit, but once an agent is compromised, the attacker can still speak the Wazuh protocol legitimately. That is precisely the trust boundary this vulnerability abuses. A single message from the rogue endpoint reaches deep into the manager’s memory and returns additional bytes inside the response payload. When the same manager also forwards events to SIEM back-ends or cloud services, the leaked strings can expose environment variables, API keys or partial credentials that help attackers pivot.

3. Technical Details – A missing NULL byte in w_expression_match()

The vulnerable function sits in os_regex.c and looks roughly like the snippet below before the fix. The manager copies the str_test field sent by the agent and then tries to match it against a rule expression.

/* simplified */
char *str_test_dup = NULL;
str_test_dup = malloc(len);         /* len received from the agent */
memcpy(str_test_dup, str_test, len);
os_match regex_result = w_expression_match(str_test_dup, expression);

Nothing guarantees that len includes the space for a terminating NULL byte. If it does not, w_expression_match() keeps reading until it stumbles upon the next \0 on the heap, handing the attacker whatever comes after the buffer. The patch responsible for 4.12.0 adds one byte to the allocation and sets str_test_dup[len] = '\0' before calling the matcher, eliminating the over-read.

Why the issue stops at information disclosure

Unlike a typical overflow, the memory past the buffer is only read, not written. That limits exploitation to data leakage rather than remote code execution. Still, when the affected process runs as root and continually parses sensitive logs, the leaked information can be valuable in follow-on attacks.

4. Impact – From single host compromise to cross-fleet intelligence

Many defenders assume that once an agent is lost, the damage ends on that endpoint. CVE-2025-62792 breaks that assumption. Attackers controlling one workstation can harvest snippets of log data from the manager, potentially revealing:

• Kerberos tickets or JWTs temporarily logged for debugging.
• File integrity monitor paths that expose directory structures.
• Names of high-value hosts collected by active response modules.

These disclosures help adversaries map the environment and craft more precise attacks, especially when multiple business units share a single Wazuh cluster.

5. Remediation – Upgrade immediately or isolate untrusted agents

The Wazuh team released 4.12.0, which fixes the allocation logic. For most users, a standard package upgrade and service restart suffices. If an immediate upgrade is not possible, consider:

• Disabling automatic agent registration to reduce the risk of rogue endpoints.
• Segregating high-trust agents from low-trust ones by running a dedicated manager instance for sensitive workloads.
• Monitoring manager logs for unusually long or malformed messages coming from any single agent ID.

Because the protocol does not include explicit length fields for every sub-structure, defensive filtering at the network layer is impractical.

6. Timeline

7. References

• GitHub advisory: https://github.com/wazuh/wazuh/security/advisories/GHSA-2672-vfhm-xhr6

About Volerion

Volerion delivers AI-driven enrichment minutes after a CVE goes live. A single call to our REST API returns CVSS 4.0 vectors, exploitability metrics and affected products complete with remediation. Additionally, we offer different scoring profiles, complete with insight into the eight comprehensive categories that make up the final score. Our API is also available in the traditional NVD API 2.0 format, so integration is as simple as swapping hosts. Spend less time parsing CVEs and more time closing them.

How the Volerion Risk Score Fits With CVSS, EPSS and KEV

At the time of writing:

• This CVE carries a 7.5 base score under CVSS 3.1, reflecting the high confidentiality impact combined with the ease of exploitation from any network location.
• EPSS has not yet published a probability estimate and currently lists a score of 0.
• CISA has not placed the vulnerability on its Known Exploited Vulnerabilities catalog, so there is no federal remediation deadline.

The Volerion Risk Score for CVE-2025-62792 is 7.6. That places it in our high-risk band, largely because the attack requires no credentials and the vulnerable product often sits at the heart of an organization’s detection stack.