Thousands of repeat CVE alerts for the same few packages, all at the same severity, across every agent. Here is how to quiet them down — and what it costs you.
If you run Wazuh's vulnerability detector across more than a handful of machines, you have probably seen a version of this:
"I manage Wazuh for a large organisation and I keep getting thousands of alerts about outdated Firefox CVEs across hundreds of machines. For me these are just trash alerts. I want to drop their level from 13 down to 5 — is there a way to catch every alert for one package and re-rank it?"
Every Chrome, Firefox, Zoom, Acrobat or Java build on every endpoint produces its own CVE alert, the detector re-runs on a schedule, and the same findings come back around again. A few unpatched desktop apps can account for the large majority of your vulnerability alert volume, and they all land at the same Critical level as a genuinely urgent server-side CVE.
The goal is usually not to hide these — you still want the data for reporting and CMMC/PCI evidence — but to stop them crowding out everything else.
Wazuh's vulnerability-detector alerts are generated internally (not from a decoded log line) by a small set of rules, grouped under vulnerability-detector, with rule IDs in roughly the 23500–23510 range. Severity is assigned purely from the CVE's own CVSS rating:
There is no built-in notion of "this finding is chronic and already known" versus "this is new today." A CVE that has been open on 300 laptops for six months fires exactly like one that appeared an hour ago. That is the gap you are working around.
Add an override rule to /var/ossec/etc/rules/local_rules.xml on the manager. It matches any vulnerability-detector alert for the package you name and re-emits it at a lower level, leaving every other alert untouched.
Then reload the manager:
New alerts for that package now arrive at level 5. Documents already written to wazuh-alerts-* keep their original level — this is not retroactive.
data.vulnerability.package.name (shown above). The rewritten detector in 4.8+ uses package.name at the document root. Check one of your own alerts in Discover and match whatever you actually see.
Down-rank on the laptop fleet but keep findings on servers loud, by matching the agent name pattern:
Adjust the regex to your naming scheme. If your agent names carry no useful prefix, keep the down-rank global (the rule above without the agent.name line) and rely on your reporting to slice by host.
One rule per package gets unwieldy fast. Move the package names into a CDB list and keep a single rule.
Create /var/ossec/etc/lists/vuln-noise-packages:
Register the list in ossec.conf inside the <ruleset> block:
And match against it with one rule:
Restart the manager to compile the list. Adding a package is now one line, not a new rule.
Setting level="0" drops the alert before it is written at all:
wazuh-alerts-*, so it will not appear in vulnerability reports or compliance evidence, and you cannot tell later when the CVE was finally remediated. Prefer down-ranking (Options 1–2) unless you are certain you never need the data.
Rule tuning works, and for a short, stable list of offenders it is the right call. But be clear about what you have taken on:
The reason these alerts are noise is not their severity — it is that they are chronic. They fired yesterday, they will fire tomorrow, and nothing about them changed. What you actually want is to see the findings that are new for this agent and let the standing ones fade into the background automatically, without maintaining a list.
AlertWatch is a read-only console that sits on your existing Wazuh + OpenSearch and does exactly that: it tracks each rule's fire history per agent, so "first seen today on FILESERVER-01" is visually separated from "fires every day on everything," with the CVE detail shown inline so you are not switching tabs to get context. No rule edits, no restarts, nothing written back to your indices.
demo / demo), or read how it connects in the docs.