Post cover image

July 31, 2026

How Wazuh Vulnerability Detection Actually Works

From endpoint inventory and CVE correlation to indexing and dashboard visibility

By Serdar Göksu

11 min read

None

From endpoint inventory and CVE correlation to indexing and dashboard visibility

When a vulnerability appears on the Wazuh Dashboard, the first assumption is usually simple:

The Wazuh agent scanned the endpoint and found a CVE.

That is not quite how the system works.

The Wazuh agent is not a standalone vulnerability scanner that directly checks installed software against CVEs. Its primary role is to collect accurate information about the operating system, installed packages, applications, and Windows updates.

The actual vulnerability assessment takes place on the Wazuh server. The server compares the inventory received from the agent with vulnerability intelligence provided by the Wazuh Cyber Threat Intelligence platform and then builds the current vulnerability state.

In simplified form, the process looks like this:

None

Each component in this chain has a different responsibility. A failure or delay at any stage can directly affect what appears on the Dashboard.

For that reason, when a vulnerability is missing or remains visible after patching, looking only at the Dashboard is not enough. You need to follow the data from the endpoint and identify the exact stage where it becomes incomplete, outdated, or unavailable.

The Agent Collects Inventory, Not Vulnerabilities

The process begins with the Syscollector module running inside the Wazuh agent.

Syscollector gathers inventory information describing the current state of the endpoint. Depending on the operating system and configuration, it can collect:

  • Operating system information
  • Installed packages and applications
  • Package versions and architectures
  • Windows hotfix information
  • Running processes
  • Open ports
  • Network interfaces
  • Hardware details
  • Users and groups
  • Services
  • Browser extensions

For vulnerability detection, the three most important datasets are:

* Operating system information
* Installed package inventory
* Windows hotfix inventory

A typical Syscollector configuration may look like this:

<wodle name="syscollector">
  <disabled>no</disabled>
  <interval>1h</interval>
  <scan_on_start>yes</scan_on_start>
  <hardware>yes</hardware>
  <os>yes</os>
  <packages>yes</packages>
  <hotfixes>yes</hotfixes>
</wodle>

When scan_on_start is enabled, Syscollector performs an inventory scan when the agent starts. It then repeats the scan according to the value configured under interval.

The collected data is processed locally and new or changed records are sent to the Wazuh server. The server maintains a separate inventory state for every enrolled agent.

The important point is this:

Vulnerability Detection is only as accurate as the Syscollector inventory it receives.

If Syscollector cannot see an application, reports an unexpected package name, or holds an outdated version, Wazuh cannot perform an accurate CVE correlation.

Inventory Is a State, Not a Log Event

Many Wazuh security capabilities are event-driven.

For example:

A login attempt failed
A process started
A file changed
A connection was blocked

Each of these describes something that happened at a specific moment.

Syscollector works differently. It describes the current state of the endpoint:

Google Chrome 134.0.6998.118 is installed
Windows Server 2022 is running
KB5030216 is installed
OpenSSL 3.0.2 is installed

The Vulnerability Detection module compares this current state with the latest available vulnerability intelligence.

This distinction explains several behaviors that may otherwise seem strange:

  • A vulnerability can appear in Inventory without creating a new alert.
  • A vulnerability can disappear from Inventory after a package update.
  • A CTI update can change the result even when nothing changed on the endpoint.
  • Reconnecting an agent can rebuild the vulnerability state without generating a new event.
  • A software update performed while the agent is stopped may not create a package-change event.

The following two Dashboard views should therefore be treated separately:

Inventory
Which vulnerabilities are currently active?
Events
Which vulnerability-related changes generated an alert?

Inventory represents the current state. Events represent changes that Wazuh observed over time.

Treating them as the same thing is one of the most common mistakes in vulnerability troubleshooting.

The Vulnerability Decision Is Made on the Wazuh Server

Once the inventory reaches the Wazuh server, the Vulnerability Detection module begins the correlation process.

When comparing endpoint inventory with Wazuh CTI content, the module may evaluate:

  • Product or package name
  • Installed version
  • Package format
  • Operating system distribution
  • Operating system version
  • System architecture
  • Vendor-specific revision information
  • Affected version ranges
  • Known fixed versions
  • Windows update and hotfix data

Consider a simple example:

Installed package:
Google Chrome 134.0.6998.118
CTI condition:
Versions earlier than 136.0.7103.59 are affected
Result:
The installed version falls within the affected range
State:
Vulnerable

On paper, this looks straightforward.

In real environments, however, version comparison is often much more complicated. Linux distributions may add release numbers, epoch values, architecture identifiers, or vendor-specific suffixes to package versions.

The same application may also be reported under different package names on different platforms.

For example, the same product may have:

  • One package name on one Linux distribution
  • A vendor-specific suffix on another
  • A different registry display name on Windows

A simple string comparison would therefore produce both false positives and missed detections.

Wazuh addresses this problem through standardized vulnerability content, product mappings, operating system rules, and version comparison logic.

Where Does Wazuh Get Its Vulnerability Data?

The Wazuh CTI platform collects vulnerability information from vendors and public security databases.

Examples include:

  • AlmaLinux
  • Amazon Linux
  • Arch Linux
  • Canonical
  • Debian
  • Fedora
  • Oracle Linux
  • Red Hat
  • Rocky Linux
  • SUSE
  • Microsoft Security Updates
  • National Vulnerability Database
  • Open Source Vulnerabilities
  • CISA

These sources do not all use the same data format, package naming convention, or version structure.

Wazuh therefore processes the content before using it for correlation.

Content normalization

Data arriving in different vendor formats is converted into a common structure.

Data sanitization

Missing fields, inconsistent version values, and product naming differences are corrected or enriched where possible.

Content merging

Vendor information is combined with Wazuh-maintained product mappings and operating system rules.

The result is a more consistent vulnerability dataset that the Wazuh server can use during correlation.

The manager-side configuration typically looks like this:

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Each setting controls a different part of the process:

enabled
Enables the vulnerability correlation engine.
index-status
Allows the current vulnerability state to be written to the indexer.
feed-update-interval
Defines how frequently the CTI content is refreshed.

Enabling only the Vulnerability Detection module is not enough.

Results may still be incomplete when:

  • Syscollector is not collecting inventory
  • CTI content cannot be updated
  • The indexer integration is not working
  • The manager cannot access the configured online or offline repository

In isolated environments, an offline copy of the Wazuh CTI content can be used. However, the offline repository must also be updated regularly. Otherwise, new CVEs may remain unavailable and corrected vulnerability definitions may stay outdated.

Why Windows Vulnerability Detection Is More Complicated

On Windows, determining whether a vulnerability has been fixed cannot always be done by checking only the operating system or application version.

Microsoft vulnerabilities are commonly remediated through:

  • Cumulative updates
  • Security updates
  • Servicing stack updates
  • New updates that supersede older ones

This makes the Windows hotfix inventory particularly important.

The process can be summarized as follows:

None

Wazuh compares installed hotfix identifiers with Microsoft update information to determine whether a particular CVE has been addressed.

The hotfix inventory is stored under the following index pattern:

wazuh-states-inventory-hotfixes-*

Even when the required update has been successfully installed, the vulnerability may remain active until Syscollector collects and reports the new hotfix information.

For that reason, seeing a successful result in Windows Update is not always enough.

The real question is:

Does the relevant KB appear in the Wazuh hotfix inventory?

How the Vulnerability State Is Created

After correlation, Wazuh creates a new vulnerability state or updates the existing state for the affected agent.

A vulnerability record may contain:

  • Agent ID and name
  • Operating system information
  • Package name
  • Installed package version
  • Package architecture
  • CVE identifier
  • Description
  • Severity
  • CVSS score
  • Publication date
  • First detection time
  • Matching version condition
  • Vulnerability source
  • References

The current vulnerability state is stored under:

wazuh-states-vulnerabilities-*

Package inventory is stored separately under:

wazuh-states-inventory-packages-*

Windows hotfix data is stored under:

wazuh-states-inventory-hotfixes-*

This separation is extremely useful during troubleshooting.

It allows you to investigate the problem one layer at a time:

Does the package appear in inventory?
        ↓
Is the reported version correct?
        ↓
On Windows, is the relevant hotfix visible?
        ↓
Was a vulnerability state created?
        ↓
Can the Dashboard display that state?

Using this method turns a vague problem such as "Wazuh is not showing the vulnerability" into a specific and testable failure point.

Filebeat and the Indexer Connector Do Not Perform the Same Function

One of the most commonly misunderstood parts of the Wazuh architecture is the difference between Filebeat and the Wazuh indexer connector.

Both move data from the manager toward the indexer, but they handle different types of data.

Filebeat
Transfers alerts and archived events generated by
the Wazuh analysis engine to the indexer.
Wazuh indexer connector
Synchronizes vulnerability state and inventory data
between the manager and the indexer.

A healthy Filebeat service therefore does not prove that vulnerability inventory is being indexed correctly.

Likewise, a working vulnerability inventory does not prove that the normal Wazuh alert pipeline is healthy.

These are separate data paths and should be verified independently.

Inventory and Events Are Not the Same

Imagine that a newly enrolled endpoint contains 100 vulnerabilities.

After the first inventory synchronization, those vulnerabilities may appear in the Inventory view.

That does not mean 100 new alerts must also appear in Events.

The initial synchronization is treated differently from changes observed later.

Consider this example:

The agent is running
        ↓
Syscollector records Chrome 134
        ↓
Chrome is upgraded to version 136
        ↓
The next scan detects the version change
        ↓
The vulnerability state becomes resolved
        ↓
A remediation event may be generated

In this case, Wazuh has observed both the old and new versions, so it can track the change.

Now consider a different scenario:

The Wazuh agent is stopped
        ↓
Chrome is upgraded
        ↓
The agent is started again
        ↓
The first scan sees only Chrome 136
        ↓
The current vulnerability state is correct
        ↓
No package-change event is generated

The final vulnerability state can be correct in both cases. However, only the first scenario is likely to produce an event describing the change.

The same behavior may appear when:

  • An agent connects to a different manager node
  • The initial inventory synchronization is rebuilt
  • Agents are re-evaluated after CTI content changes
  • CVE information or product mappings are updated
  • Software is upgraded while the agent is stopped

In other words:

A change in the current vulnerability state does not always produce a new alert.

A Complete Detection Example

Assume the following package is installed on a Windows 11 endpoint:

Package: Google Chrome
Version: 134.0.6998.118
Architecture: x86_64
Operating system: Windows 11

The process works as follows.

1. Syscollector discovers the package

The agent adds the package name, version, and architecture to the inventory.

2. The inventory is sent to the Wazuh server

The server updates the package inventory associated with the agent.

3. Vulnerability Detection evaluates the package

The server compares the installed version with the current CTI content.

Assume the CVE condition is:

Google Chrome versions earlier than
136.0.7103.59 are affected

The installed version falls within that range and is therefore considered vulnerable.

4. A vulnerability state is created

Wazuh creates a record containing the agent, package, CVE, severity, CVSS score, and matching condition.

5. The indexer connector synchronizes the record

The vulnerability state is written to:

wazuh-states-vulnerabilities-*

6. The Dashboard displays the result

The record becomes visible in the Vulnerability Detection Inventory view.

7. The package is upgraded

Chrome is upgraded to a version outside the affected range.

8. Syscollector detects the new version

During the next scan, the new package version is sent to the server.

9. Wazuh recalculates the state

The new version no longer satisfies the affected-version condition.

10. The vulnerability is resolved

The vulnerability is removed from the active state.

When the package change is observed during normal agent operation, Wazuh may also generate a remediation event.

Why an Expected Vulnerability May Be Missing

There are several reasons why a CVE may not appear.

The package is missing from inventory

If Syscollector cannot see the package, there is nothing for the vulnerability engine to correlate.

Possible causes include:

  • Syscollector is disabled
  • Package collection is disabled
  • The initial scan has not completed
  • The application was installed using a non-standard method
  • The package name is different from what was expected
  • The agent inventory is outdated

The reported version is different from the expected version

The version shown in an application's About page may not match the version stored in Wazuh inventory.

Version information can differ between:

  • Application interface
  • Executable metadata
  • Windows Registry
  • Package manager
  • Installation database

Vulnerability correlation uses the value stored in the Wazuh inventory.

The operating system is not fully supported

A partially supported or unsupported operating system may still produce some findings, but complete coverage cannot be guaranteed.

CTI content is outdated

If the manager cannot retrieve current vulnerability intelligence, new CVEs may not appear.

When an offline repository is used, it must also be kept up to date.

The package name does not match

Custom builds, manually installed software, and vendor-specific packages may be difficult to map to the expected product name.

Windows hotfix information is missing

Even when an update is installed, Wazuh may continue to report the CVE until the hotfix appears in inventory.

The vulnerability was detected but could not be indexed

In this case, inventory collection and correlation may work while Dashboard visibility fails.

Inventory collection works
Correlation works
Indexer synchronization fails
The Dashboard cannot display the result

Inventory exists, but no alert was generated

This is not always an error.

Initial synchronization, CTI-driven re-evaluation, or changes made while the agent was stopped may update the state without generating a new event.

Why a Vulnerability May Remain After Patching

A vulnerability remaining active after a patch does not necessarily mean the patch failed.

Possible causes include:

  • Syscollector has not performed another scan
  • The old package is still installed
  • Multiple versions of the same product exist
  • The installed update does not actually resolve the CVE
  • Windows hotfix inventory has not been updated
  • A reboot is required before the version changes
  • Indexer state synchronization is delayed
  • The Dashboard is showing historical Events instead of current Inventory
  • CTI content changed after the patch was installed

At this point, the first question should be:

Which package, version, operating system, and hotfix information is Wazuh currently evaluating?

Starting with "Why is Wazuh wrong?" usually leads the investigation in the wrong direction.

The first step should always be to verify whether the data available to Wazuh is accurate.

A More Reliable Troubleshooting Sequence

When an unexpected vulnerability result appears, use the following order:

1. Verify the actual endpoint state
        ↓
2. Check the Syscollector package inventory
        ↓
3. Verify the reported version and architecture
        ↓
4. Check the operating system and hotfix inventory
        ↓
5. Verify the Vulnerability Detection configuration
        ↓
6. Confirm that CTI content is current
        ↓
7. Check whether the vulnerability state exists
        ↓
8. Verify indexer connector communication
        ↓
9. Evaluate Inventory and Events separately
        ↓
10. Check again after the next Syscollector scan

Starting with the following actions is usually a mistake:

  • Deleting indices
  • Reinstalling the agent
  • Adding more CPU to the manager
  • Resetting all vulnerability data

First determine where the expected data disappears from the pipeline.

Querying the Vulnerability State Directly

When the Dashboard result is unclear, the vulnerability state can be queried directly from the indexer.

For example, the following query searches for a specific CVE:

GET /wazuh-states-vulnerabilities-*/_search
{
  "query": {
    "term": {
      "vulnerability.id": "CVE-2025-4050"
    }
  }
}

If the record exists in the index but does not appear on the Dashboard, the following stages have probably completed successfully:

  • Inventory collection
  • Vulnerability correlation
  • Indexing

The problem may instead be related to a Dashboard filter, time range, or visualization setting.

If the record does not exist in the index, follow the pipeline backward:

Vulnerability state
        ↑
CTI correlation
        ↑
Package and hotfix inventory
        ↑
Syscollector scan
        ↑
Endpoint

This approach significantly reduces unnecessary changes, especially in large Wazuh environments.

Conclusion

Wazuh Vulnerability Detection is not a standalone vulnerability scan.

It is a continuous correlation system built from several connected layers:

Inventory collection
        +
Vulnerability intelligence
        +
Product and version matching
        +
State synchronization
        +
Alert generation
        +
Dashboard visualization

To produce an accurate result, the system must correctly answer the following questions:

  • Which software is installed on the endpoint?
  • What exact version is installed?
  • Which operating system is running?
  • Which patches and hotfixes are present?
  • Which versions are vulnerable?
  • Which versions contain the fix?
  • Did the resulting vulnerability state reach the indexer?

The Dashboard is only the final presentation layer.

When a result appears incomplete or incorrect, troubleshooting should not begin with assumptions based on the Dashboard. It should begin with endpoint inventory and follow the data through each stage of the pipeline.

Once this architecture is understood, validating, explaining, and troubleshooting Wazuh vulnerability findings becomes much easier.