Vulnerability Scanner triggering hundreds of false positives at the same tim

147 views
Skip to first unread message

Andrehens Chicfici

unread,
Jan 22, 2026, 3:33:16 AMJan 22
to Wazuh | Mailing List
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

unread,
Jan 22, 2026, 7:02:38 AMJan 22
to Wazuh | Mailing List
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.
    image-1.png

  • 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

unread,
Jan 26, 2026, 5:18:57 AMJan 26
to Wazuh | Mailing List
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

unread,
Jan 29, 2026, 9:46:32 AMJan 29
to Wazuh | Mailing List
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

unread,
Feb 3, 2026, 5:54:29 AMFeb 3
to Wazuh | Mailing List
Hey, Cedrick!

Thanks, will try that!

cheers
chic

Cedrick Foko

unread,
Feb 9, 2026, 2:46:13 AMFeb 9
to Wazuh | Mailing List
Hello Andrehens,
Did you try custom rules? What was the result?
Please let me know here if you need further assistance.

Andrehens Chicfici

unread,
Feb 9, 2026, 4:19:25 AMFeb 9
to Wazuh | Mailing List
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

Cedrick Foko

unread,
Feb 13, 2026, 4:27:19 AMFeb 13
to Wazuh | Mailing List
Hello Andrehens,
As I explained, the rule is supposed to silence alerts for the specified CVEs. If you are no longer seeing false positive alerts, it means the rule worked as expected.
You can keep monitoring and let me know if the alerts appear again.

Andrehens Chicfici

unread,
Feb 16, 2026, 3:55:12 AMFeb 16
to Wazuh | Mailing List
Hey Cedrick,

it happened again. Tonight hundreds of CVE triggered from just one host although I implemented the silencing advices you gave me:

The rule that got triggered is 23506 from 0520-vulnerability-detector_rules.xml

  <rule id="23506" level="13">
      <if_sid>23501</if_sid>
      <options>no_full_log</options>
      <field name="vulnerability.status">Active</field>
      <field name="vulnerability.severity">Critical</field>
      <description>$(vulnerability.cve) affects $(vulnerability.package.name)</description>
  </rule>

Cedrick Foko

unread,
Feb 17, 2026, 3:03:06 AMFeb 17
to Wazuh | Mailing List
Hello Andrehens,
Can you please confirm if the reported CVEs are part of the CVEs defined in the custom rule?
We may need to update the rules.
Kindly share a sample JSON alert so I can update the silencing rule.

Andrehens Chicfici

unread,
Feb 17, 2026, 3:52:04 AMFeb 17
to Wazuh | Mailing List
Hey Cedrick,

Here's a sample JSON. This event with different CVE-2016-... triggered 218 times from the same host on  Feb 13, 2026 around 21:33


{
  "_index": "wazuh-alerts-4.x-2026.02.13",
  "_id": "8gTsWJwBaczMXdxzvIj-",
  "_score": null,
  "_source": {
    "input": {
      "type": "log"
    },
    "agent": {
      "ip": "192.168.180.1",
      "name": "Client-1",
      "id": "185"
    },
    "manager": {
      "name": "wazuh"
    },
    "data": {
      "vulnerability": {
        "severity": "Critical",
        "package": {
          "condition": "Package less than or equal to 15.016.20045",
          "name": "Adobe Acrobat Reader DC MUI",
          "source": " ",
          "version": "15.007.20033",
          "architecture": "i686"
        },
        "assigner": "adobe",
        "cwe_reference": "CWE-119",
        "published": "2016-07-13T02:00:56Z",
        "classification": "CVSS",
        "title": "CVE-2016-4250 affects Adobe Acrobat Reader DC MUI",
        "type": "Packages",
        "rationale": "Adobe Reader and Acrobat before 11.0.17, Acrobat and Acrobat Reader DC Classic before 15.006.30198, and Acrobat and Acrobat Reader DC Continuous before 15.017.20050 on Windows and OS X allow attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors, a different vulnerability than CVE-2016-4191, CVE-2016-4192, CVE-2016-4193, CVE-2016-4194, CVE-2016-4195, CVE-2016-4196, CVE-2016-4197, CVE-2016-4198, CVE-2016-4199, CVE-2016-4200, CVE-2016-4201, CVE-2016-4202, CVE-2016-4203, CVE-2016-4204, CVE-2016-4205, CVE-2016-4206, CVE-2016-4207, CVE-2016-4208, CVE-2016-4211, CVE-2016-4212, CVE-2016-4213, CVE-2016-4214, CVE-2016-4251, CVE-2016-4252, and CVE-2016-4254.",
        "reference": "https://helpx.adobe.com/security/products/acrobat/apsb16-26.html, http://www.securityfocus.com/bid/91716, http://www.securitytracker.com/id/1036281",
        "score": {
          "version": "3.0",
          "base": "9.800000"
        },
        "cve": "CVE-2016-4250",
        "scanner": {
          "reference": "https://cti.wazuh.com/vulnerabilities/cves/CVE-2016-4250"
        },
        "enumeration": "CVE",
        "cvss": {
          "cvss3": {
            "base_score": "9.800000",
            "vector": {
              "user_interaction": "NONE",
              "integrity_impact": "HIGH",
              "scope": "UNCHANGED",
              "availability": "HIGH",
              "confidentiality_impact": "HIGH",
              "attack_vector": "NETWORK",
              "privileges_required": "NONE"
            }
          }
        },
        "updated": "2025-04-12T10:46:40Z",
        "status": "Active"
      }
    },
    "rule": {
      "firedtimes": 206,
      "mail": true,
      "level": 13,
      "pci_dss": [
        "11.2.1",
        "11.2.3"
      ],
      "tsc": [
        "CC7.1",
        "CC7.2"
      ],
      "description": "CVE-2016-4250 affects Adobe Acrobat Reader DC MUI",
      "groups": [
        "vulnerability-detector"
      ],
      "id": "23506",
      "gdpr": [
        "IV_35.7.d"
      ]
    },
    "location": "vulnerability-detector",
    "decoder": {
      "name": "json"
    },
    "id": "1771018433.5475363046",
    "timestamp": "2026-02-13T22:33:53.863+0100"
  },
  "fields": {
    "data.vulnerability.published": [
      "2016-07-13T02:00:56.000Z"
    ],
    "data.vulnerability.updated": [
      "2025-04-12T10:46:40.000Z"
    ],
    "timestamp": [
      "2026-02-13T21:33:53.863Z"
    ]
  },
  "sort": [
    1771018433863
  ]
}



cheers
chic

Cedrick Foko

unread,
Feb 19, 2026, 10:34:36 AMFeb 19
to Wazuh | Mailing List
Hello Andrehens,
You are still getting the alerts because the custom rule is silencing once the CVEs defined in the <match> tag.
I order to silence all the alerts from Adobe Acrobat Reader DC MUI, you need to update your rule as follows: 

<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="vulnerability.package.name">Adobe Acrobat Reader DC MUI</field>

    <description>Ignore old Adobe Reader DC CVEs for post-2024 versions</description>
  </rule>
</group>

Reply all
Reply to author
Forward
0 new messages