Vulnerability Detection List not updating

[exe]

Hello There,

we are using Wazuh on docker on a single node stack.

We recently updated our Servers and the number of Vulnerabilities didnt decrease.

Please let me know what infos you need to help me resolve  this issue.

Thanks in advance!

[Pablo Moliz Arias]

To investigate this issue, the following information is required. You can obtain it as described below:

1. Wazuh versions (Manager, Indexer, Dashboard) and Docker image tags

   • Check the Docker image tags or run wazuh-manager -v inside the manager container.

2. Vulnerability Detection status

   • Review the <vulnerability-detection> section in ossec.conf on the Wazuh Manager to confirm it is enabled.

3. Syscollector status

   • Verify that <wodle name="syscollector"> is enabled in the agent configuration.

4. Relevant logs

   • Check Wazuh Manager logs for vulnerability-related messages, for example in /var/ossec/logs/ossec.log or by running docker logs wazuh-manager.

5. Inventory update

   • Confirm that agents reported updated package inventory after the server updates.

If you share me more this details, I can try to help you to identify why the vulnerability count did not change.

Below are links to the official Wazuh documentation that explain these components in detail:

• Wazuh Docker deployment
• Upgrading Wazuh on Docker
• Vulnerability Detection overview
• How Vulnerability Detection works
• Vulnerability Detection configuration

[exe]

Hello Pablo,

thanks for the Answer, here are the infos:

1.)
NAMES                           IMAGE                          STATUS
watchtower                      nickfedor/watchtower:latest    Up 2 days (healthy)
portainer_agent                 portainer/agent:lts            Up 2 days
single-node-wazuh.manager-1     wazuh/wazuh-manager:4.13.0     Up 2 days
single-node-wazuh.dashboard-1   wazuh/wazuh-dashboard:4.13.0   Up 2 days
single-node-wazuh.indexer-1     wazuh/wazuh-indexer:4.13.0     Up 7 hours

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

3.)
<wodle name="syscollector">
    <disabled>no</disabled>
    <interval>1h</interval>
    <scan_on_start>yes</scan_on_start>
    <hardware>yes</hardware>
    <os>yes</os>
    <network>yes</network>
    <packages>yes</packages>
    <ports all="yes">yes</ports>
    <processes>yes</processes>

4.) I couldn't find any vulnerability-related logs
5.) Still no update sadly

[Pablo Moliz Arias]

Thank you for the detailed configuration and status

The problem is that he Indexer restarted 7 hours ago, but the Manager did not. When the Indexer goes down, the Manager (specifically the filebeat service inside it) often stops sending data or gets stuck waiting for the connection to come back. Even if the Indexer comes back up, the Manager's shipping pipeline might be "stalled."

Step 1: 

We need to re-establish the connection chain. Since you are on Docker, please run these commands on your host machine:

1. Restart the Manager to reconnect to the Indexer:

   docker restart single-node-wazuh.manager-1

2. Wait 2 minutes, then check the Filebeat logs inside the manager to ensure it is talking to the indexer:

   docker exec single-node-wazuh.manager-1 cat /var/log/filebeat/filebeat | grep -i "error" | tail -n 10

Step 2

If the restart didn't solve it after a few minutes, your Vulnerability Database inside the container might be stale.

Let's force Wazuh to delete its internal database and re-download the vulnerability definitions from scratch.

Run these commands on your Docker Host:

1. Enter the Manager container as root:

   docker exec -u 0 -it single-node-wazuh.manager-1 bash

2. Stop the Wazuh service (inside the container):

   /var/ossec/bin/wazuh-control stop

3. Check if the database file exists:

   ls -l /var/ossec/queue/vulnerabilities/cve.db

           If the file exists, delete it (if it does not exist, just proceed to the start command):

           rm -f /var/ossec/queue/vulnerabilities/cve.db

       4. Start the Wazuh service:

            

           /var/ossec/bin/wazuh-control start

       5. Exit the container:

           

           exit

Using these commands:

• The Manager will realize the DB is missing.

• It will start downloading the OVAL/NVD feeds.

• Once downloaded, it will re-scan your inventory.

A common confusion is where you look in the Dashboard. 

Do NOT look at: Modules > Security Events. (This shows a history. The old vulnerability alerts will remain there forever as a historical record). 

DO look at: Modules > Vulnerability Detection > Inventory. 

Or check the specific agent: Agents > Select Agent > Vulnerability Inventory.

[exe]

Hello Pablo,

thanks for the help, here is my documentation:

Step 1:
1. worked
2. "cat: /var/log/filebeat/filebeat: No such file or directory"

Continued with step 2, because restart didn't solve the problem.

Step 2:
1. worked
2. worked
3.
bash-5.2# ls -l /var/ossec/queue/vulnerabilities/cve.db
ls: cannot access '/var/ossec/queue/vulnerabilities/cve.db': No such file or directory

To maybe save some time i did this:

bash-5.2# ls -l /var/ossec/queue/
total 88
drwxr-x---  2 wazuh wazuh  4096 Apr 30  2025 agentless
-rw-------  1 root  wazuh  7387 Jan 20 07:57 agents-timestamp
drwxrwx---  2 wazuh wazuh  4096 Jan 20 07:32 alerts
drwxrwx---  2 wazuh wazuh  4096 Apr 30  2025 cluster
drwxr-x---  2 wazuh wazuh 12288 Jan 20 07:57 db
drwxr-x---  2 wazuh wazuh  4096 Apr 30  2025 diff
drwxr-x---  3 wazuh wazuh  4096 Sep 18 07:23 fim
drwxr-x---  2 wazuh wazuh  4096 Sep 18 07:25 fts
drwxr-xr-x  3 root  root   4096 Sep 19 08:25 harvester
drw-rw---- 13 root  wazuh  4096 Sep 19 08:25 indexer
drwxr-x---  2 wazuh wazuh  4096 Jan 20 07:32 keystore
drwxr-x---  2 wazuh wazuh  4096 Sep 18 07:25 logcollector
drwxrwx---  2 wazuh wazuh  4096 Jan 20 07:23 rids
drwxrwx---  2 wazuh wazuh  4096 Jan 20 07:57 router
drwxrwx---  2 wazuh wazuh  4096 Jan 20 07:32 sockets
drwxr-x---  3 wazuh wazuh  4096 Sep 18 07:23 syscollector
drwxrwx---  2 wazuh wazuh  4096 Jan 20 07:32 tasks
drw-rw----  8 root  wazuh  4096 Sep 19 08:26 vd
drwxr-xr-x  4 root  root   4096 Jan 20 07:32 vd_updater

4.

bash-5.2# /var/ossec/bin/wazuh-control start
2026/01/20 08:05:32 wazuh-modulesd: WARNING: (1230): Invalid element in the configuration: 'scan_on_start'.
2026/01/20 08:05:32 wazuh-modulesd: WARNING: (1230): Invalid element in the configuration: 'provider'.
2026/01/20 08:05:32 wazuh-modulesd:router: INFO: Loaded router module.
2026/01/20 08:05:32 wazuh-modulesd:content_manager: INFO: Loaded content_manager module.
2026/01/20 08:05:32 wazuh-modulesd:inventory-harvester: INFO: Loaded Inventory harvester module.
Starting Wazuh v4.13.0...
Started wazuh-apid...
Started wazuh-csyslogd...
Started wazuh-dbd...
2026/01/20 08:05:35 wazuh-integratord: INFO: Remote integrations not configured. Clean exit.
Started wazuh-integratord...
Started wazuh-agentlessd...
Started wazuh-authd...
Started wazuh-db...
Started wazuh-execd...
Started wazuh-analysisd...
Started wazuh-syscheckd...
Started wazuh-remoted...
Started wazuh-logcollector...
Started wazuh-monitord...
2026/01/20 08:05:37 wazuh-modulesd: WARNING: (1230): Invalid element in the configuration: 'scan_on_start'.
2026/01/20 08:05:37 wazuh-modulesd: WARNING: (1230): Invalid element in the configuration: 'provider'.
2026/01/20 08:05:37 wazuh-modulesd:router: INFO: Loaded router module.
2026/01/20 08:05:37 wazuh-modulesd:content_manager: INFO: Loaded content_manager module.
2026/01/20 08:05:37 wazuh-modulesd:inventory-harvester: INFO: Loaded Inventory harvester module.
Started wazuh-modulesd...
Completed.

Thank you for your help

[exe]

Hello there, is there any update on my problem? Thank you in advance.

[Pablo Moliz Arias]

Hello,

Thank you for the logs and the directory list. They were very helpful.

Based on the errors you sent (Invalid element in the configuration), it looks like there are two likely causes for this issue:

1. Outdated Configuration: You are running Wazuh 4.13, but your ossec.conf seems to contain settings from an older version. 

2. Permissions: The folder /var/ossec/queue/vd is owned by root. It is possible that the Wazuh user cannot write updates there.

Here is how you can try to fix both:

Step 1: Update the Configuration

We need to replace the old vulnerability settings with the correct ones for version 4.13.

1. Enter the container:

1. docker exec -u 0 -it single-node-wazuh.manager-1 bash

2. Edit the configuration file:

   nano /var/ossec/etc/ossec.conf

3. Search for the <vulnerability-detection> block. Delete the entire block and replace it with this standard configuration:

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

1. Vulnerability detection documentation
   Vulnerability detection user manual
   

Step 2: Fix Folder Permissions

While you are still inside the container, run these commands to ensure Wazuh has the right permissions:

       chown -R wazuh:wazuh /var/ossec/queue/vd chown -R wazuh:wazuh /var/ossec/queue/vd_updater

Step 3: Restart and Check

Restart the service and check if the "Invalid element" errors are gone

If the fix works, you should see a message saying Vulnerability Detection module started instead of the previous warnings.

Let me know if this clears up the errors in the log.

If this does not work: Could you please let me know if you have updated this instance from an older version in the past? If so, do you remember which version you were running before 4.13.0? This will help us understand if there are other leftover configuration files.

[exe]

1. i dont know if this is not normal, but i when i do nano /var/ossec/etc/ossec.conf it says "Directory '/var/ossec/etc' does not exist

2. chown: invalid user: 'wazuh:wazuh'

3. we did not update from the past, i changed the ossec.conf once but cant seem to find it again sadly 

[exe]

Sorry mistake on my end, found the ossec.conf and changed it like you said, only problem i have now is; 

bash-5.2# /var/ossec/bin/wazuh-control start
2026/01/21 12:26:35 wazuh-modulesd:router: INFO: Loaded router module.
2026/01/21 12:26:35 wazuh-modulesd:content_manager: INFO: Loaded content_manager module.
2026/01/21 12:26:35 wazuh-modulesd:inventory-harvester: INFO: Loaded Inventory harvester module.
Starting Wazuh v4.13.0...
wazuh-apid already running...
Started wazuh-csyslogd...
Started wazuh-dbd...
2026/01/21 12:26:36 wazuh-integratord: INFO: Remote integrations not configured. Clean exit.
Started wazuh-integratord...
Started wazuh-agentlessd...
wazuh-authd already running...
wazuh-db did not start correctly.

i gave them permisson, that worked now too

[exe]

wazuh-db is now starting correctly, i edited the ossec.conf on the host and just copied it to the docker container and the ownership was then root root, changed it to wazuh wazuh now its working again. still  vulnerability detection isnt updating sadly

[Pablo Moliz Arias]

Hello, Since the service has just restarted successfully, the Vulnerability Detector is likely in its Initialization phase. It needs to download files from the internet.

The Possible Issue: 

This download process usually takes 20 to 60 minutes. During this time, the Dashboard will not show updates, and it might seem like nothing is happening. However, if the Docker container does not have internet access, this download will fail.

To confirm if it is currently downloading in the background or if it is blocked by a firewall, please run these two commands on your host and paste the output here:

1. Check the Module Status (Logs): This will tell us if the download started or failed today.

   docker exec single-node-wazuh.manager-1 grep -i "vulnerability" /var/ossec/logs/ossec.log | tail -n 20
   
   

2. Check Internet Connectivity: This verifies if the container can reach the vulnerability database servers.

   docker exec single-node-wazuh.manager-1 curl -I https://nvd.nist.gov
   
   

Once I see these logs, I will be able to tell you if we just need to wait for the download to finish or if we need to fix a network setting.

[exe]

Hello Pablo,

in the meantime i fixed the issue.

It was a network problem, the docker container had problems with ipv6 so i made a settings change to prefer ipv4 and then it worked.

Thank you so much for your help!