CVE-2023-50260 is a High severity (CVSS 8.8) code injection flaw in Wazuh. The host_deny active response script writes an unchecked value into hosts.deny, which can end in command execution as root. The advisory lists versions 4.2.0 and later as affected and 4.7.2 as the fix.
What's affected
Product: Wazuh, the open source threat detection and response platform, specifically the wazuh-manager package and the active response script host_deny. Affected: versions 4.2.0 and later up to the fix. Fixed: 4.7.2, per the project's GitHub advisory GHSA-mjq2-xf8g-68vw. NVD published the record on 19 April 2024.
Severity: the record scores it 8.8 High with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, and the advisory also says High 8.8, so the sources agree. Low privileges are required.
The advisory says the active response feature normally limits actions to executables under the active-response bin directory, but host_deny, which is one of them, can be abused. It states that the response can be triggered on the manager, which leads to local privilege escalation to root, and on agents through the queue that forwards events, which leads to remote code execution as root on the agent.
How to check if you're exposed
Check the Wazuh version on every manager and agent.
/var/ossec/bin/wazuh-control info
dpkg -l wazuh-manager wazuh-agent # Debian and Ubuntu
rpm -q wazuh-manager wazuh-agent # RHEL and derivatives
Anything from 4.2.0 up to but not including 4.7.2 is in range according to the advisory. Remember that agents can run an older version than the manager, and agents are where the advisory describes remote code execution, so inventory them as carefully as you do the server.
Also review whether the host_deny active response is configured in your ossec.conf. If it is not configured, the practical exposure is lower, though the safe course is still to upgrade.
What to do now
- Upgrade the Wazuh manager to 4.7.2 or later, then upgrade agents to the same version.
- Review the active response configuration. Remove any response you do not use, including host_deny if you do not rely on TCP wrappers.
- Restrict who can write to the manager's execd and agent response queues, and who holds API credentials with that ability.
- Inspect the hosts.deny file on managers and agents for entries that contain more than an address.
- Store the Wazuh version in your inventory for each host.
Why it matters
The record maps this to CWE-94, code injection. The advisory explains the root cause with a short walk through the code: the script takes a source address from a JSON message and writes a line into hosts.deny without checking that it is a valid address. TCP wrappers treat certain directives in that file as instructions, so a crafted value can add a command that runs when a connection is evaluated.
Defensive tools are attractive targets because they run with high privilege and act on input from many hosts. An automatic response script that trusts event data is a good example. The fix is validation: an address field should only ever contain an address.
KEV is false, and no source I read says it is exploited. The advisory credits a researcher working with Trend Micro's Zero Day Initiative. Safeguard's gold.safeguard.sh/scan scan checks open source dependencies in your repositories, and the Gold directory lists this CVE with its weakness class.
Try it yourself
Version drift between managers and agents is how old builds survive. The demo below shows continuous monitoring catching it.
Click through it at your own pace, or open it full screen.
Quick check
Which versions are affected?
Wazuh 4.2.0 and later, before 4.7.2, according to the project advisory. Version 4.7.2 contains the fix.
Is it remote?
The record vector is network with low privileges. The advisory describes root level code execution on agents as well as privilege escalation on the server.
Sources
Last reviewed: 19 October 2026.
