Max-severity flaw CVE-2026-56699 hits the Wazuh security monitor (CVSS 10.0): unauthenticated record tampering, update 5.0 beta now

Wazuh, a "security monitoring tool" used worldwide to watch servers and PCs and log suspicious activity, has a maximum-severity vulnerability. Tracked as CVE-2026-56699, it carries a severity score (CVSS) of 10.0 — the top of the 0-to-10 scale. Without any login, an attacker can delete or rewrite the alert records the monitoring system has collected.

First, let's be clear. Only the still-in-testing new "5.0" beta builds (beta1 and beta2) are affected. The stable 4.x line that most sites run in production is not affected, so there is no need to rush. The issue is already fixed in 5.0.0-beta3, so only those evaluating or testing 5.0 ahead of release need to update right away.

This article walks through what Wazuh is, why the score is a perfect 10.0, who would target this flaw and why, and how to tell whether you are actually affected — all in plain terms that require no special background.

What Wazuh is, and why a "perfect 10.0" matters

Wazuh is open-source security monitoring software that analyzes logs (activity records) gathered from a company's servers and PCs, then flags dangerous signs such as "someone tried to log in illegitimately" or "an unfamiliar program ran." It belongs to the category known as SIEM and XDR — in plain terms, "the watchdog that notices attacks." Because it is free and modifiable, it is widely adopted by corporate security operations centers (SOCs) and IT departments.

Its footprint is not small. The project's GitHub page has around 16,000 "stars," and downloads run into the tens of millions per year. In Japan, firms such as Jupiter Technology provide Japanese-language deployment support and commercial backing, and the tool is well known among security practitioners.

Severity is expressed as a number from 0.0 to 10.0 by an international yardstick called CVSS (Common Vulnerability Scoring System). A 10.0 is the most dangerous rank, awarded only when a flaw is exploitable "over the network," "without a login," and "easily," while also risking leakage, tampering, and destruction of data all at once. CVE-2026-56699 hit that perfect score under both the CVSS 3.1 and 4.0 formulas. The awkward part is that the very tool meant to watch for attacks could itself be turned into a stepping stone for one.

Overview of the vulnerability

CVE-2026-56699: the monitoring server can have its alert records tampered with

The flaw lives in the heart of Wazuh, the "management server (Wazuh Manager)." The small watchdog (agent) installed on each PC or server sends data to the manager, and the manager processes part of that data without checking it thoroughly. As a result, simply sending crafted data lets an attacker delete or rewrite records. The key points are summarized below.

The flaw was found and reported by TarPeg007, and fixed by developer juliancnn. The full timeline from discovery to fix to numbering is laid out in the write-up by VulnCheck, which runs a vulnerability database.

Who would target this, and why

Lining up numbers and classification codes rarely conveys "does this concern me?" So let's spell out who would abuse this hole, what they would do, and what happens as a result.

The likely attacker is not someone hammering random websites from the outside. It is an attacker who has already gotten into an organization that watches itself with Wazuh. They are inside — but their movements are being recorded by Wazuh's monitoring net. That is where this flaw comes into play as the next move.

What the attacker does here is erase the alert records that show their intrusion, blinding the monitoring. By sending crafted data to the management server, they delete or rewrite stored alert logs, and they can even embed malicious content into the monitoring dashboard, according to the advisory. Picture pages being torn out of the watchdog's notebook after the fact — but only the inconvenient ones.

The damage lands in two layers. For the company or organization running the monitoring tool, the biggest blow is that the very evidence of a breach gets erased. Clues to notice the attack are lost, a full forensic investigation becomes impossible, and an intruder can linger undetected. For the end users of that service, the impact is indirect: the "watchdog" meant to protect their data had been quietly neutralized. That is exactly why the next section — telling whether you are affected — matters.

What is actually happening: breaking down the mechanism

From here it gets a bit technical. This is for readers who want the mechanism; if you only want the fix, feel free to skip ahead.

Wazuh 5.0 runs a subsystem called "inventory_sync" that takes the information (inventory) collected by each agent, sends it to the management server, and writes it in bulk to the data search engine OpenSearch. In doing so, the manager embedded an agent-supplied field, DataValue.index, straight into a write command (OpenSearch's bulk request) without inspecting or neutralizing its contents.

That write command uses "NDJSON," a plain format that lists one record per line. If an attacker slips in newlines and symbols, they can append extra commands — "delete this record," "rewrite that record" — right after what was supposed to be a single record. It is like inserting a line break and a new instruction into the middle of a sentence to swap its meaning entirely. In technical terms, it combines improper handling of special characters in output (CWE-74) with a newline-abusing technique (CWE-93) and a mismatch in permission handling (CWE-863).

What makes it serious is that these appended commands run with the powerful administrative rights the management server holds (a default all-operations-allowed privilege). The attacker need not hold much privilege themselves; they get the privileged server to carry out the command on their behalf — a structure known in security as a "confused deputy," the same root cause as the flaw we recently covered in mcp-grafana, the connector for the monitoring tool Grafana.

One more premise is what "no login required" actually means. Wazuh has a mechanism to register agents with the management server, but the default (use_password=no) allows anonymous, password-free enrollment. In other words, if the attacker is positioned to reach the manager's enrollment port (TCP 1515) and communication port (TCP 1514), they can register as a fake agent without any valid account and send crafted data. Conversely, keeping those ports off the public internet acts as an effective barrier.

Am I affected? A version-by-version quick reference

The single most important question with this flaw is "is the Wazuh I use affected?" The short answer: if you run the mainstream 4.x line in production, this does not concern you. Check your situation in the table below.

Even if you fall under "affected," actually pulling off the attack requires that "the attacker can reach the manager's enrollment and communication ports." If your setup places the manager deep inside the internal network and does not expose those ports externally, the bar for exploitation rises accordingly. That said, it does not stop an insider attack or lateral movement once someone is already inside the network, so if you run an affected version, updating is the surest move.

The timeline from discovery to disclosure

About a month passed between the fix and the formal number assignment for this flaw. Because working proof-of-concept code circulated in that window, knowing the timeline helps you judge the situation.

← Swipe to move

What to do right now

The response is not hard. If you are testing a Wazuh 5.0 beta, update to 5.0.0-beta3 or later. That alone resolves this issue. Update steps and changes are covered in the release notes in Wazuh's official documentation.

Regardless of version, there are two settings worth checking. One is to require authentication for agent enrollment. Dropping the default anonymous enrollment (use_password=no) and making a password mandatory stops fake agents from registering in the first place. The other is to not expose the manager's communication ports (TCP 1514 and 1515) to the outside. These two are fundamentals of running Wazuh safely, well beyond this particular flaw.

Free open-source software like Wazuh is easy to adopt, but it requires you to keep up with fix information yourself. When you want to review which open-source components have which vulnerabilities, see our companion piece on how to check the safety of open-source software.

Production is mostly unaffected — so why know now

To recap: CVE-2026-56699 scores a perfect 10.0 for severity, but it affects only the in-testing 5.0 beta builds, and there are no reports of actual exploitation so far. For most sites, this is "news you don't need to panic about."

We still cover it because working proof-of-concept code is already public and Wazuh 5.0 is the flagship version going forward. Organizations weighing a move to 5.0 will benefit from understanding now "why this earned a perfect score," which helps with configuration checks during migration. The structure — a tool that watches for attacks being turned into a tool that erases traces — is also a lesson that applies to monitoring tools in general.

This blog continues to track vulnerabilities found in monitoring and log-collection tools. Reading alongside the case of the monitoring tool Splunk, the network monitoring tool Cacti, and the log collector Fluentd — all flagged for takeover risks without a login — reveals the recurring pattern of problems in this space.

Frequently asked questions

Q. If our company's Wazuh is 4.x, do we need to do anything?

A. For CVE-2026-56699, no action is needed. Only the 5.0 beta builds are affected; the 4.x line is out of scope. Do keep applying your routine security updates, though.

Q. It's "severity 10.0" — why is there no need to rush?

A. 10.0 only indicates "how dangerous it would be if exploited," which is separate from how broad the affected scope is. Here the scope is limited to beta builds and no exploitation has been confirmed, so for most people there is no urgency.

Q. Will my personal PC be targeted?

A. Wazuh is software mainly used for the security monitoring of companies and organizations; individuals rarely run it on their own. The target is the monitoring server, and ordinary consumers are not directly harmed.

References

• ▸ NVD - CVE-2026-56699 (published July 15, 2026)
• ▸ GitHub Security Advisory - GHSA-ff9g-85jq-r3g3 (June 8, 2026)
• ▸ VulnCheck - Wazuh Manager NDJSON injection in inventory sync
• ▸ SecurityOnline - Wazuh CVSS 10 Vulnerability (June 15, 2026)
• ▸ Wazuh Official Documentation - Release Notes
• ▸ Wazuh - GitHub repository
• ▸ Jupiter Technology - Wazuh (Japanese support)