Wazuh Vulnerability Scanner strange behavior on upgrade Packages stay on unsolved

[No Data]

Hello everyone,

We are currently observing some strange behavior in the vulnerability scanner. CVEs are only marked as Solved when the affected packages are uninstalled. However, when a package is upgraded, it is not marked as solved.

The inventory (IT hygiene) correctly shows the newly installed package. According to the vendor’s errata, this is a fixed version. Nevertheless, the vulnerability scanner still lists it as Unsolved.

A test involving the uninstallation of packages confirmed that such cases are detected correctly.

Attached are two screenshots illustrating the situation — both SUSE (SLES 12/15) and Red Hat (8/9) systems in our environment are affected.

According to Red Hat, the fixed version is installed:
https://access.redhat.com/errata/RHSA-2024:1436

The package details in the inventory confirm this.



However, the vulnerability details still list the system as vulnerable — interestingly, the package has been installed longer than the vulnerability has been detected. In other words, the vulnerability has been known for some time but was only recently flagged by the scanner, even though the fixed version is already in place.



Something about this seems quite odd.

I also noticed that the vulnerability scanner details are missing information about the fixed version. In the past, before CTI, this information was always shown. I believe including this would be quite useful.

i'm confused, any help will be welcome?

with best regards

[Ifeanyi Onyia Odike]

Hi @ata...@tutanota.com

Your query is acknowledged.

Let me get back to you on this.

Regards

[Rafael Gomez]

Same here. I’m dealing with other kinds of the same false positive. It’s driving me crazy.

Rafael Gómez
+34 644 668 229

--
You received this message because you are subscribed to the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wazuh/f89e0497-7fef-41d6-adfa-e1d200df2178n%40googlegroups.com.

[Ifeanyi Onyia Odike]

Hello 

To resolve this query, I will itemize the three issues you have observed and provide responses:

• Patched packages are not marked as “Solved.” The scanner only resolves CVEs when the vulnerable package is uninstalled, not when it’s upgraded.

Answer: This is strange and shouldn't work like that. Could you confirm that you restarted your Wazuh agent after upgrading the package? The vulnerability detector needs to perform another scan on the Wazuh agent after packages are updated to patched versions.

• The System Inventory shows correct (fixed/upgraded) versions, but the vulnerability scanner still flags them as vulnerable.

Answer: That's an important part. The scanner is working as expected. Could you confirm that the old vulnerability does not appear in the inventory dashboard while we investigate this further?

• I also noticed that the vulnerability scanner details are missing information about the fixed version. In the past, before CTI, this information was always shown. I believe including this would be quite useful.

Answer: Could you please share more details about the exact field you are referring to/missing?

[app...@proton.me]

Question: This is strange and shouldn't work like that. Could you confirm that you restarted your Wazuh agent after upgrading the package? The vulnerability detector needs to perform another scan on the Wazuh agent after packages are updated to patched versions.

yes the agents restarted.

Question: That's an important part. The scanner is working as expected. Could you confirm that the old vulnerability does not appear in the inventory dashboard while we investigate this further?

Yes, only one version is visible in the Inventory Dashboard. What’s strange is that the package.installed column is empty here. However, the Vulnerability Report does show an installation date. I checked the installation directly on the server, and the package is installed. No duplicate packages. . Removed Package on the affected Servers are marked as solved in the last days.

Question: Could you please share more details about the exact field you are referring to/missing?

  In the old days, before CTI was used as a source for the Vulnerability Scanner (NVD and vendor ERRATA), the Red Hat errata data at least included a field with the fixed version. That field no longer exists today, which makes filtering for false positives more difficult. Now, it’s always necessary to check directly on the vendor’s website.  

[Ifeanyi Onyia Odike]

Hi 

This is the related behavior for the first question.

"If the changes are made to packages while the Wazuh agent is in a stopped state, no alerts will be triggered. Also, if these changes are only detected after the Wazuh agent is restarted, no alert will be triggered."

I will get back to you with a reply about the third question.

Regards,

[app...@proton.me]

Hi,

  I think we misunderstood each other. I thought you meant whether we had restarted the agents themselves after an upgrade. That has been done. The agents are updated remotely on our side. They run continuously and are not stopped during a package upgrade on the servers — that wouldn’t make any sense anyway. It’s not that simple. So this is not the expected behavior.  

with best regards

[Ifeanyi Onyia Odike]

Hi,

Regarding your third question. I have attached an image from what is currently available.

Can you try utilizing the vulnerability.scanner.condition for your use case?

[app...@proton.me]

  No, that doesn’t help at all, and of course I know the link. However, there are no fixed versions listed there either — otherwise, they would probably also appear as a value in the dataset. The only workaround is to go through your errata pages; then I can copy the CVE and go directly to the corresponding page. Furthermore, it’s hard to filter using just a link — something like “version greater than” or “version smaller than” doesn’t really work well with a link.

In principle this is more of a luxury problem, but it would be better if the “Vulnerability Scanner” did its job — which it effectively does not at the moment. Is there any solution for this? Otherwise I’ll delete the index now and have everything rebuilt. I can’t accept this poor, invalid state. The old version of the Vulnerability Scanner was noticeably better and more robust. Since the switch, there have apparently been widespread problems — not just for us. 

with best regards   

[app...@proton.me]

 Good morning,

I just want to clarify once again that of course the field vulnerability.scanner.condition is helpful, but it can’t really be used for searches — just like vulnerability.scanner.reference.

Wouldn’t it be better to only include the package version here and then query it against the inventory?
Of course, we could build our own version of the Vulnerability Dashboard via the API, but is that really the way to go?

Regarding the actual issue:
I went through the alert logs again yesterday. It’s definitely the case that some servers report the fixed version, but a large number do not. This affects both Red Hat and SLES servers. Even after several days, the CVE remains active.

All servers are running the latest agent version, and the agent also runs whenever packages are updated. The inventory in IT Hygiene is correct; only some packages are missing the installation date.

I really want to get this under control. Is there a way to trigger the scan again and have the vulnerability database rewritten without deleting the index?

Is the only option really to disable and re-enable the vulnerability scanner? That would again take quite some time before everything is fully captured.

with best regards  

[app...@proton.me]

  I conducted some further analysis. In the CVE mentioned above as an example, the vulnerability.scanner.condition field says “Package default status.” So, there is no fixed version listed here — could that be part of the problem?  

[Ifeanyi Onyia Odike]

Hi,

I will be responding to your questions.

Regarding the actual issue:
I went through the alert logs again yesterday. It’s definitely the case that some servers report the fixed version, but a large number do not. This affects both Red Hat and SLES servers. Even after several days, the CVE remains active.

• The expected behaviour is that as long as the agent remains reachable and active during and after the package upgrade, the vulnerability detector modifies the remediated/updated alert as solved. Please assist us by providing logs from your instance, enabling module debug 2, and checking the agent and server to see which events are being processed during one of the vulnerable package upgrades.

Is the only option really to disable and re-enable the vulnerability scanner? 

• Unfortunately, this is the option for now.

I conducted some further analysis. In the CVE mentioned above as an example, the vulnerability.scanner.condition field says “Package default status.” So, there is no fixed version listed here — could that be part of the problem?

• This is what the content has in some cases. If the scanner can not match the version, it will respect what the "defaultStatus" says.

            {
              "defaultStatus": "affected",
              "platforms": [
                "cpe:/o:redhat:enterprise_linux:8"
              ],
              "product": "postgresql-jdbc",
              "vendor": "redhat"
            },

Regards,

[app...@proton.me]

Hello, 

sorry for the late reply, I've been a bit busy the past few days. I had debugging enabled already, but I will try to activate it during an update. Is it enough to enable debugging on the agent, or should I also enable it on the manager servers?

 Currently, I'm even experiencing the strange effect where a package is marked as both vulnerable and solved at the same time. I will upload screenshots of this in the next few days.  

with best regadrs

[Ifeanyi Onyia Odike]

Hi 

You can enable it on both the server and the agent.

[app...@proton.me]

Hello,

I performed additional investigations and came across a strange phenomenon. The CVE visible in the screenshots appears once as “solved” and then again as “not solved” in the system. The vulnerability.scanner.condition matches the installed package. This package was installed on November 12 at around 10:30 a.m. I also verified this in the Zypper logs. The scanner then wrote “solved” into the events at around 11:30 a.m. However, it seems it did not do this for all entries in the index related to the CVE.

Maybe I’m missing something. How does the “solved” marking work? Is it like with firewalls — first rule match and then it exits? Is our CVE/CTI database corrupt? Why do we apparently have two different entries in the index for the same CVE and software? Why is it not possible to trigger a full rescan of the entire server with a single action, essentially as if the server were new again? Am I overlooking something?

With best regards

[Ifeanyi Onyia Odike]

Hello,

Thanks for the detailed investigation and the screenshots; they are very helpful.

Let me clarify how the “solved” status works and why you might be seeing the same CVE both as solved and not solved:

1. How “solved” is marked internally

• Each vulnerability event is generated by matching the CVE/CTI entry (including vulnerability.scanner.condition)against the current software inventory of the agent.

• When the scanner detects that the installed package version satisfies the fixed condition for that CVE, it generates a new event wherevulnerability.status = "Solved" for that specific match.
• Existing “Unsolved” documents already stored in the index are not retroactively rewritten; instead, new “Solved” events are added. This is why, from an index perspective, you can have: older “Unsolved” documents for a CVE and newer “Solved” documents for the same CVE and package.

2. Why do you see the same CVE as both solved and not solved?

Typical reasons are:

• There are multiple events/records for the same CVE on the same host (for example, generated at different times, or with slightly different package metadata), and only part of them were later matched as solved. 
• Dashboards or saved searches may be: showing historical events (no time filter, or a long time range), or aggregating on CVE only, without always distinguishing the latest status per host+package. So even though the most recent state for that host+package is solved, older unsolved entries are still visible in the index.

3. Is the CVE/CTI database corrupt?

Based on your description (first “Unsolved”, later “Solved” for the same CVE after upgrade), this behaviour is more consistent with normal CTI+scanner logic plus indexing/history than with

database corruption.

To be safe, you can still:

• Verify that CTI sync/tasks are completing successfully in the manager logs.

• Double-check that the condition shown in vulnerability.scanner.condition really matches the installed version (epoch, release, arch included).