Vulnerability Detection produces zero CVEs for deb packages on Ubuntu agents, while pypi matching and Windows OS matching work normally (4.14.7)

[Faqih Sulthan]

Hi all,

I've been chasing this for about a week and I've run out of ideas, so I'm hoping someone here recognises the pattern.

The short version: on my manager, vulnerability detection produces plenty of findings for Windows agents and for Python (PyPI) packages on Linux agents — but not a single finding from any deb package on any Ubuntu agent. The package inventory is there, the OS metadata is there, the scanner is clearly running. The deb matching stage just produces nothing, silently, with no error anywhere in the logs.

Setup: Wazuh 4.14.7, single node, all-in-one on Ubuntu, 116 active agents, most of them Ubuntu 20.04.

---

What I'm seeing

Vulnerability documents grouped by OS across the whole index:

Microsoft Windows Server 2022 Standard 10097 Microsoft Windows Server 2016 Standard 9251 Ubuntu 161 Microsoft Windows Server 2012 R2 Standard 79

That 161 for Ubuntu is the whole fleet combined.

To rule out anything historical, I enrolled a brand new Ubuntu 20.04.6 agent (dev-env) and let it sync from scratch. It behaved perfectly — full inventory arrived immediately. Here's what it looks like in wazuh-states-inventory-packages-*:

deb 1287 pypi 140 npm 1

So the inventory side is fine. But when I look at the 77 vulnerability documents that agent produced, grouped by package.name:

pypdf 35, pillow 17, PyJWT 7, urllib3 6, cryptography 3, protobuf 2, Pygments 1, click 1, fonttools 1, h11 1, python-dotenv 1, requests 1, zeep 1

Every single one is a PyPI package. Not one deb. No linux-image-*, no openssl, no libc6, no curl — on a 20.04 box that's well past standard support and definitely not fully patched.

Severity split for those 77: Medium 41, High 29, Low 4, unset 2, Critical 1.

---

What I've already ruled out

OS metadata — this was my main suspicion, since the Canonical feed is keyed on the codename. But sys_osinfo is complete:

os_name Ubuntu os_version 20.04.6 LTS (Focal Fossa) os_codename focal os_major 20 os_minor 04 os_platform ubuntu

Agent connectivity — agent_control -l gives 116 Active, 5 Disconnected, 0 Never connected.

Scanner health — I ran with wazuh_modules.debug=2 for a while. In a 10-minute window I got 18,641 lines from osScanner.hpp, including Windows scans completing normally:

osScanner.hpp:395 DEBUG: Vulnerability scan for OS 'windows_server_2016' on Agent 'NNN' has completed.

and for Ubuntu agents:

osScanner.hpp:380 DEBUG: OS scan for platform 'ubuntu' on Agent 'NNN' is not supported.

I understand that second line is expected — Linux has no OS-level matching stage, it's all package-level. But I never see any package-level activity for deb either, and nothing that would explain why.

Indexer connectivity — writes to the other wazuh-states-inventory-* indices succeed in the same time window.

Feed — fully downloaded locally (~9.8 GB) and the updater offset matches the CTI offset (3706504).

---

One more thing that might be related

The newest vulnerability.published_at anywhere in my data is 2026-07-14. Nothing after mid-July, even though the feed reports itself as current. I don't know whether that's the same problem or a separate one, but it feels like it could be — as if part of the feed content is downloaded but never actually loaded into whatever the scanner matches against.

---

How I got here, in case it matters

• Aug 4 — upgraded manager/indexer/dashboard 4.14.4 → 4.14.7, and reindexed wazuh-states-vulnerabilities because stale package entries were showing up.
• Aug 10 — did a full VD reset: removed queue/vd/{inventory,delayed,event} and queue/indexer, deleted the vulnerabilities index, toggled <enabled> no → yes. The feed re-downloaded in full afterwards. No change to the outcome.

---

What I'd like help with

1. Is there any way to verify that the Canonical/focal feed content is actually loaded into the matching database, rather than just downloaded to disk? Everything I can check says "downloaded", but the results say otherwise.
2. Should deb matching log anything when it runs and finds nothing? Right now I can't tell the difference between "ran and matched nothing" and "never ran at all".
3. Does 20.04 reaching end of standard support affect whether its feed entries get ingested?

Happy to run any diagnostic and post the output. Thanks in advance.

[Olamilekan Abdullateef Ajani]

Hello,

I am looking into this and will revert with my findings shortly.

Regards,

[Olamilekan Abdullateef Ajani]

Hello again,

So I tested this on my side with Wazuh 4.14.7 manager and 4.14.7 agents.

I used Ubuntu 20.04/Focal agents, and deb package vulnerabilities are being detected. I can see findings for packag like:

linux-image-5.4.0-208-generic
linux-image-5.4.0-216-generic
lxd
snapd
klibc-utils
firefox

So this does not look like a general issue with Ubuntu 20.04, Focal, or Wazuh 4.14.7.

One useful point: linux-image-5.4.0-216-generic is the current Focal kernel line, and it still produced findings in my test. So if your agent has 1,287 deb packages in inventory but no linux-image-* vulnerability findings at all, that looks unusual.

I think you should focus on the manager/feed side, especially the Canonical matching path.

Please check:

grep -iE "Failed to scan package|canonical|packageScanner" /var/ossec/logs/ossec.log | tail -100

Also check the source breakdown of the findings on that Ubuntu agent:

vulnerability.scanner.source
package.type
package.name

If the findings are only from PyPI/OSV/NVD and none from Canonical/deb packages, that would confirm the Canonical path is not being used.

You can also force a package inventory change and watch the logs again:

apt install --reinstall vim -y

Then check whether Wazuh logs show any deb package scan activity.

Also, what version is the Ubuntu agent running? I tested with the manager and agent both on 4.14.7.

Please let me know what you find