Issue with cleaning up after OS upgrade

[Vuk Kadija]

Hello community,

I have wazuh in lab and prod environment. Both clusters are configured in the same way. Version 4.14.5

We have upgraded agents from Debian 12 to Debian 13. We noticed old vulnerability findings were still there and agent would report both OS-es. It was dirty.

In the lab we did the procedure

curl -s -k -u 'bla:bla' -X POST \
  "https://localhost:9200/wazuh-states-vulnerabilities-*/_delete_by_query" \
  -H "Content-Type: application/json" \
  -d '{"query":{"match":{"agent.id":"017"}}}'

rm -f /var/ossec/queue/vd/inventory/017_*
rm -f /var/ossec/queue/vd/delayed/017_*
rm -f /var/ossec/queue/vd/event/017_*
rm -f /var/ossec/queue/indexer/017_*

/var/ossec/bin/agent_control -r -u 017

...and that would clean the state, agent would report new state and all fine. Old finding would be removed, only new vulnerabilities would be reported.

However when we do the same thing on the second cluster, we can not clean anything.
I tried then the official procedure

https://documentation.wazuh.com/4.12/user-manual/capabilities/vulnerability-detection/known-issues.html

Also tried the full procedure

systemctl stop wazuh-manager

<vulnerability-detection>
   <enabled>no</enabled>
</vulnerability-detection>

rm -f /var/ossec/queue/vd/inventory/017_*
rm -f /var/ossec/queue/vd/delayed/017_*
rm -f /var/ossec/queue/vd/event/017_*
rm -f /var/ossec/queue/indexer/017_*

curl -s -k -u 'bla:bla' -X POST \
  "https://localhost:9200/wazuh-states-vulnerabilities-*/_delete_by_query" \
  -H "Content-Type: application/json" \
  -d '{"query":{"match":{"agent.id":"017"}}}'

systemctl start wazuh-manager

/var/ossec/bin/agent_control -r -u 017

grep "syscollector" /var/ossec/logs/ossec.log | grep "Evaluation" | tail -5

I just used the same agent id for example.

Can you please let me know is there something I'm missing or the procedure changed.

Best regards,

Vuk

[Stuti Gupta]

Hi Vuk Kadija,

The steps should also work in your production environment:

Can you please let me know if there are any architectural differences between the two environments?

Also, after running the _delete_by_query request, does the response show that vulnerability documents for the agent are actually being deleted?

Sharing that output, along with any relevant ossec.log entries after the agent rescan, and also from the manager side

cat  /var/ossec/logs/ossec.log | grep "syscollector" 
On manager 
cat /var/ossec/logs/ossec.log | grep -i -E "vuln|<agent_id>"

Looking forward to your reply. 

[Vuk Kadija]

Hello Stuti,

I just repeated the procedure and it worked. State is clean and agents are sending real data.
But now I noticed one thing and I can't find the real explanation how "vulnerability module" really works or I don't understand the concept.

If you can just clarify few things.
Let's say I have a Debian 13 and as you know there are lot of kernel vulnerabilities. Package name is "linux-image-amd64" and package version is "6.12.90-2" and at the moment Wazuh reports 333 vulnerabilities for this package. (51 high 90 med 1 low 191 pending)
Inventory on the Vulnerability Detection shows detections and related CVEs, but some of the CVEs should be covered with 6.12.90-2. For example https://security-tracker.debian.org/tracker/CVE-2026-23378. Also, other vulnerabilities in this package version are still active or pending...
I thought if some CVE's are covered with specific package version, event tab would show change from Active to Solved and the rest will stay in Active state.

Best regards,

Vuk  

[Stuti Gupta]

Hi Vuk,

Yes, you are correct. If the vulnerability has been fixed and the installed package version is no longer affected, it should not continue to be reported as vulnerable.

To explain how Wazuh vulnerability detection works: the agent collects package information from the endpoint using Syscollector. Wazuh then compares that information against the Wazuh CTI database, which contains vulnerability data from operating system vendors and public vulnerability databases. When Wazuh finds that an installed package version matches a known CVE, it reports the vulnerability.

Based on that, if the package has been updated to a non-vulnerable version, the vulnerability should no longer be detected.

I am checking this with the team. Please allow me some time.

In the meantime, could you run the following API query and share the output? Please replace <agent_id> with the affected agent ID:

GET /syscollector/<agent_id>/packages?search=

You can also use it to filter and verify the affected Linux package.

It would also be helpful if you could share the operating system information reported by the agent. For example:

cat /etc/os-release u
name -r

This will help me reproduce the environment and verify what is happening.

Additionally, could you share the JSON view of the affected package from the inventory? You can open the package entry in the dashboard and switch to the JSON view, then share the content with us.

[Stuti Gupta]

Additionally, you can refer to this https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/how-it-works.html for more information on how wazuh works.