Vulnerability Scanner triggering hundreds of false positives at the same tim

[Andrehens Chicfici]

Hey,

I have the problem that on some days I get hundred of false positive alerts from Adobe Acrobat Reader DC from various machines.

This morning for example, I woke up to see

CVE-2016-6958 affects Adobe Acrobat Reader DC MUI

CVE-2016-7017 affects Adobe Acrobat Reader DC MUI

CVE-2016-4091 affects Adobe Acrobat Reader DC MUI

...

and over 180(!) more on 4 of my < 30 clients with the same OS and Adobe version.

Yes, Adobe Acrobat Reader DC is installed. Version 2025.001.21111 which was released 2 days ago (20 Jan 2026).

Why is it even triggering? And why only on those 4 machines?

I had the same thing happening for 2 other machines last Monday (12 Jan 2026), also with Adobe Acrobat Reader. And also with 3 different machines in December (10 Dec 2025), 1 machine on 1 Dec 2025, 1 machine in November (6 Nov 2025) and 1 machine in October (9 Oct 2025).

It always happens around the same time (21:38–21:40 UTC) and only affects 1–4 machines that were not affected before (virtual AND physical) and floods me with hundreds of alerts and mails.

Is there a way to not get hundred of false alerts? 

cheers

chic

[Cedrick Foko]

Hello,

The issue you describe is caused by one of the followings:

• There are multiple versions of the same package installed on the agent. It is possible for the same package to have different versions installed by multiple users. You need to make sure vulnerability detection alerts are not triggered by old version of the package installed alongside with the new one.
  
  
• Packages information is not updated in Wazuh managers' DB. If you verified that old package version is not installed, the issue can be due to packages information not updated in the manager. This means that although you updated the package on the agents, the version in Wazuh manager is still the old version. In order to verify the package version reported by the manager, check the Software section of IT Hygiene of your agent on Wazuh dashboard.
  
  
  
• If the package version reported by the manager is correct, then the information may not correctly indexed. In that case, we recommend reseting the vulnerability detection module to force a complete re-scan. Before doing this, you need to make sure the following requirements are satisfied:
  - The affected agents are active and reporting to the manager.
  - The Wazuh Indexer cluster is in 'green' status.
  - There aren't warning/error messages in the manager's ossec.log file related to the connection with the indexer, the synchronization or the abuse control mechanism.
  - Some hours have passed since the package upgrade on the agents.
  
  Follow the steps below to reset the VD module:
  • Disable the vulnerability detection module in all your managers' configuration
    <vulnerability-detection>
      <enabled>no</enabled>
      <!-- Other configurations -->
    </vulnerability-detection>
    
    
  • Stop the wazuh-manager service on all your manager nodes
    systemctl stop wazuh-manager
    
    
  • Remove the VD state DBs from all the manager nodes
    # rm -rf /var/ossec/queue/vd/inventory/
    # rm -rf /var/ossec/queue/vd/delayed/
    # rm -rf /var/ossec/queue/vd/event/
    # rm -rf /var/ossec/queue/indexer/
    
    
  • Clean the vulnerability index (run this command on the indexer)
    # curl -X DELETE "https://<INDEXER_IP>:9200/wazuh-states-vulnerabilities-*/" -u <INDEXER_USER>:<INDEXER_PASSWORD> -k
    
    
  • Verify the index is clean:
    # curl -X GET "https://<INDEXER_IP>:9200/wazuh-states-vulnerabilities-*/_count" -u INDEXER_USER>:<INDEXER_PASSWORD> -k
    
    
  • Start the wazuh-manager service on all the manager nodes
    systemctl start wazuh-manager
    
    
  • Re-enable the vulnerability detection module:
    <vulnerability-detector>
      <enabled>yes</enabled>
      <!-- Other configurations -->
    </vulnerability-detector>
    
    
  • Restart the wazuh-manager service
    systemctl restart wazuh-manager

After this, wait for a scan to be completed and check if you still have false positives.

[Andrehens Chicfici]

Tried all of that... Didn't work.

Over the weekend I got another multiple alerts from different machines with all false positive Adobe Acrobat Reader DC MUI CVE alerts...

[Cedrick Foko]

Hello,

If you are still getting alerts after resetting the VD module, you can create a custom rule as follows to silence the alerts:

<group name="vulnerability-adobe-tuning,">
  <!-- Drop noisy old Adobe CVEs for modern Reader DC -->
  <rule id="100500" level="0">
    <if_group>vulnerability-detector</if_group>
    <field name="package.name">Adobe Acrobat Reader DC MUI</field>
    <match>CVE-2016-6958|CVE-2016-7017|CVE-2016-4091</match>
    <description>Ignore old Adobe Reader DC CVEs for post-2024 versions</description>
  </rule>
</group>

Please update the rule according to the data in your environment.

This will silence all the corresponding alerts.

[Andrehens Chicfici]

Hey, Cedrick!

Thanks, will try that!

cheers

chic

[Cedrick Foko]

Hello Andrehens,

Did you try custom rules? What was the result?

Please let me know here if you need further assistance.

[Andrehens Chicfici]

Hey Cedrik,

I implemented your suggested rule:

<group name="vulnerability-adobe-tuning,">
  <!-- Drop noisy old Adobe CVEs for modern Reader DC -->
  <rule id="100500" level="0">
    <if_group>vulnerability-detector</if_group>
    <field name="package.name">Adobe Acrobat Reader DC MUI</field>
    <match>CVE-2016-6958|CVE-2016-7017|CVE-2016-4091</match>
    <description>Ignore old Adobe Reader DC CVEs for post-2024 versions</description>
  </rule>
</group>

Since I enabled the rule I had no falso positives so far... I can't tell wheter this helped out or just coincidense.

Any ideas how to figure out?

cheers

chic