Vulnerability Detection false positives

curl -sk -u USER:PASS -H 'Content-Type: application/json' 'https://INDEXER:9200/wazuh-states-vulnerabilities-*/_search?size=0' -d '{
  "aggs": { "why": { "terms": { "field": "vulnerability.scanner.condition", "size": 15 } } } }'

What we found on our lab

A default-status match that does not apply

Our Windows 11 agent got CVE-2023-1386, High, on the package QEMU guest agent 110.2.3, condition Package default status. That CVE describes a flaw in QEMU's 9p passthrough filesystem, which runs on the virtualisation host, not in the guest agent installed inside a Windows VM. The name matched; the component did not.

A fixed version from another branch

Among the 1,056 less than findings we compared the installed major.minor with the fixed major.minor. 53 differ. Most are ordinary upgrades on one line (curl 8.17 against a fix in 8.21, expat 2.6 against 2.8). But 10 are lxd 5.0.9 against fixed versions 5.21.x: 5.0 and 5.21 are separate long-term branches. Whether the 5.0 branch is affected has to be read from the vendor's advisory, not from a version comparison. This is the pattern reported for Oracle Linux in wazuh/wazuh #39731.

Stale findings after an OS update

Each finding stores the OS version it was evaluated against (host.os.version). Comparing that, per agent, with the OS version in the system inventory shows findings left over from an older build, the situation reported for Windows Server in #39810. On our lab the two matched for all 7 agents, so we could not reproduce that case:

curl -sk -u USER:PASS -H 'Content-Type: application/json' 'https://INDEXER:9200/wazuh-states-vulnerabilities-*/_search?size=0' -d '{
  "aggs": { "agent": { "terms": { "field": "agent.id", "size": 100 },
    "aggs": { "os": { "terms": { "field": "host.os.version" } } } } } }'
# then the same aggregation on wazuh-states-inventory-system-*

An agent whose vulnerability findings show an OS version that is no longer in its system inventory has stale findings.

What you can do

1. Review against the vendor. For default status findings, read the CVE's affected component; for less than, check the fixed version belongs to your branch.

2. Stop the alert for a pair you have reviewed. Vulnerability alerts come from stock rules 23503–23506 (by severity). A level 0 child for the exact CVE and package:

<group name="local,vulnerability-detector,">
  <rule id="100900" level="0">
    <if_sid>23503,23504,23505,23506</if_sid>
    <field name="vulnerability.cve">^CVE-2023-1386$</field>
    <field name="vulnerability.package.name">^QEMU guest agent$</field>
    <description>Suppressed: CVE-2023-1386 does not apply to QEMU guest agent (reviewed).</description>
  </rule>
</group>

In wazuh-logtest on 4.14.7, the same High event went from 23505 (level 10) to 100900 (level 0). The same CVE on another package, and another CVE on the same package, still hit 23505. Keep each suppression to one CVE and one package, and note why.

3. Know what the rule does not touch. The Vulnerability Detection inventory and dashboard read the wazuh-states-vulnerabilities-* index, which the manager fills from its own evaluation. A rule only decides whether an alert is written. Wrong inventory entries are fixed in Wazuh's vulnerability data or engine; report them with the finding's vulnerability.scanner.condition and scanner.reference.