Wazuh Vulnerability Detection Guide

How Wazuh Vulnerability Detection Works

Traditional vulnerability scanning sends probes across the network to fingerprint services and guess at versions. It is noisy, needs scan windows, can destabilise fragile systems, and only sees what is reachable at scan time. Wazuh takes a fundamentally different approach: the agent already running on each endpoint inventories the exact packages installed, and the manager correlates that precise inventory against vulnerability feeds.

Because the data comes from inside the host, it is accurate. There is no guessing whether a banner reflects the real version or whether a backported patch fixed a CVE without changing the version string. The agent reports the actual installed package and the distribution's patch metadata, and the correlation reflects real exposure.

Crucially this is continuous. The agent maintains the software inventory; when the vulnerability feeds update with a newly disclosed CVE, the manager re-correlates and surfaces newly-vulnerable hosts without anyone launching a scan. You learn about a fresh vulnerability in your estate as the feed updates, not when the next scheduled scan happens to run weeks later.

Package Inventory: The Foundation

The vulnerability detector rests on the System Inventory (syscollector) module. Syscollector periodically gathers a structured inventory from each agent: installed packages and versions, operating system and patch level, running processes, open ports, network interfaces and hardware details. This inventory is stored centrally and is queryable in its own right.

For vulnerability detection the package list is the critical input. On Linux this comes from the package manager (dpkg, rpm), giving exact package names and versions plus the distribution context that determines whether a given version is patched. On Windows it reads installed programs and hotfixes. The richer and more current this inventory, the more accurate the vulnerability correlation.

The inventory has value beyond vulnerabilities. It answers 'where is package X installed', 'which hosts are running an unauthorised application', and 'what is listening on port Y across the estate'. This makes syscollector a foundational asset-management capability that the vulnerability detector then builds upon.

Keeping the inventory accurate is itself part of running the detector well. If syscollector is disabled on some agents, or its scan interval is set so long that newly installed software is not reflected for days, the vulnerability correlation works from stale data and under-reports exposure on exactly the hosts that changed most recently. Reviewing inventory freshness across the fleet, and confirming that every in-scope agent is reporting, is a routine operational check that ensures the vulnerability picture reflects the estate as it is today rather than as it was last week.

CVE Feeds and Why Vendor Sources Matter

The detector correlates inventory against vulnerability feeds. The baseline source is the National Vulnerability Database (NVD), which provides CVE identifiers, descriptions and CVSS scores. But NVD alone produces false positives on Linux, because it does not know that a distribution backported a fix into an older version number.

This is why Wazuh also consumes vendor and distribution feeds: Canonical for Ubuntu, Red Hat for RHEL, Debian, Microsoft for Windows, and Amazon Linux Security Advisories (ALAS). These feeds carry the authoritative patch status for each distribution, so the detector can tell that a package which looks vulnerable by version number is in fact patched, or vice versa. The result is far fewer false positives than generic version matching.

The manager downloads and maintains these feeds automatically. Keeping the feeds current is itself an operational task: a manager that cannot reach the feed sources will silently fall behind and under-report new vulnerabilities. Part of running Wazuh well is monitoring that the feeds are updating, which is one of the checks built into a managed SOC service.

Reading the Vulnerability Output

Detected vulnerabilities surface in the Wazuh dashboard's vulnerability detection module and as events you can search and alert on. For each finding you see the affected agent, the vulnerable package and version, the CVE identifier, the CVSS base score and severity, and a reference to the advisory. You can pivot from a CVE to every host that carries it, or from a host to every CVE it has.

This per-endpoint precision changes how remediation works. Instead of a 200-page scan report listing findings by network address with no software context, you get an inventory-grounded answer: these specific hosts run this specific vulnerable package, fixable by this specific update. Patch teams can act directly from it.

The same data feeds dashboards and scheduled reports: critical-CVE counts over time, most-vulnerable hosts, vulnerability ageing (how long known CVEs have remained unpatched), and exposure by asset group. These views turn raw detections into a managed vulnerability programme with trend lines a board can read.

Because the detector also alerts on events, you can route the appearance of a new critical or actively-exploited CVE on an in-scope host straight into your normal alerting pipeline, rather than waiting for someone to open the dashboard. This matters most at disclosure time: when a high-profile vulnerability lands and the feeds update, the hosts in your estate that carry it are surfaced as alerts within the feed cycle, giving your patch team a head start measured in hours rather than the days or weeks a scan-driven process would take to even notice.

Risk-Based Prioritisation: Fix What Will Actually Be Exploited

A mid-size estate routinely shows thousands of CVEs. You cannot patch them all at once, and CVSS severity alone is a poor sole guide, because a critical-rated vulnerability on an isolated internal box may matter far less than a high-rated one on an internet-facing server. Effective prioritisation combines several signals.

Three factors dominate. First, exploit availability: a CVE with public exploit code or, better, evidence of exploitation in the wild (the CISA Known Exploited Vulnerabilities catalogue is the canonical reference) jumps to the top regardless of base score. Second, exposure: internet-facing and lateral-movement-adjacent assets are weighted above isolated ones. Third, asset criticality: a vulnerability on the domain controller or the payment system outranks the same flaw on a kiosk.

Operationally, you triage the continuous detector output against these factors each cycle, drive the urgent set into the patch queue, and track ageing so nothing critical lingers. Wazuh provides the detection and the data; the prioritisation discipline is what converts it into reduced risk. Codesecure runs this triage as part of managed SOC, mapping findings to exploitability and exposure so clients patch the few that matter before the many that do not.

What Wazuh Vulnerability Detection Does and Does Not Replace

Wazuh vulnerability detection is excellent at one thing: knowing which known, CVE-tracked vulnerabilities exist in installed software across every endpoint running an agent, continuously and accurately. For software-inventory vulnerability management that is a strong, low-overhead capability that many organisations pay heavily for elsewhere.

It is not a penetration test. It will not find business-logic flaws, authentication bypasses, injection vulnerabilities in your own code, misconfigurations that no CVE describes, or chained exploits that a human attacker would discover. Those require manual testing by skilled testers, which is a separate discipline from continuous vulnerability detection.

The two are complementary. Wazuh keeps the known-vulnerability surface continuously visible and patched between engagements, while periodic VAPT finds the flaws no feed lists. A mature programme runs both: Wazuh for continuous coverage of the known, and scheduled manual VAPT for the unknown. Codesecure delivers both, so the continuous detection and the deep testing reinforce each other rather than duplicate.