Zero ZoomEye results for Drupal's CVE-2026-96365 show why exposure counts mislead

A 36-identifier advisory for 16 Drupal projects

On 23 September 2026, Germany's CERT-BUND published advisory WID-SEC-2026-3554 and classified it as high risk. The advisory bundles 36 identifiers, CVE-2026-96355 through CVE-2026-96398, across 16 contributed Drupal projects. A dev.to analysis published in early October takes one of those identifiers, CVE-2026-96365, as a case study in what internet-wide scan data can and cannot tell you about a flaw that has only just been assigned.

According to the dev.to post, the public record characterises the flaws as remotely exploitable and sorts the possible outcomes into five classes: arbitrary code execution, extended privileges, bypassing security measures, data manipulation or disclosure, and cross-site scripting. Which specific defect sits behind each identifier has not been published, and the analysis argues that this absence directly shapes what outside observers can detect.

Why the vulnerability query returns nothing

The analysis is built around two ZoomEye queries run on 27 September 2026. A product query for app="Drupal" matched 436,403 indexed assets. A vulnerability query for vul.cve="CVE-2026-96365" matched zero.

The zero, the author argues, is the expected result rather than evidence of safety. An external scanner can only record what a service exposes, and a defect buried inside a contributed module may leave no externally visible signature a scanner can match. On top of that, the identifier was only four days old when the query ran, leaving essentially no time for scanning engines to fold it into any exposure dataset.

Severity is unaffected by the scan gap

CERT-BUND rates both probability and damage at 4 out of 4, and the advisory carries a CVSS v3.1 base score of 9.8 with a temporal score of 8.5. The dev.to analysis is explicit that an empty scan result does not soften those numbers. In its framing, external data answers a different question and cannot stand in for an internal assessment of what you actually run.

Affected projects and fixed releases

The advisory names 16 projects with the following fixed releases:

• Webform 6.2.12 and 6.3.1
• Webform REST 4.2.1
• Cloud 7.0.1
• Project Browser 2.0.3 and 2.1.5
• Commerce Decoupled Checkout 1.8.0
• Mermaid Diagram Field 1.0.9
• CookieCuttr 2.0.3
• REST & JSON API Authentication 3.2.0
• Stop administrator login 1.6
• Tawk.to Live chat application 3.0.4
• Editoria11y Accessibility Checker 2.2.23 and 3.0.9
• AI CKEditor 1.4.3
• Combined image style 1.0.7
• CSS Usage Analyzer 1.0.2
• Smart Content 3.2.1
• Diba carousel slider 3.0.2

The CERT-BUND structured record lists 16 projects and 19 fixed releases in total, the difference coming from projects that maintain more than one branch.

Reading the two numbers honestly

The core of the dev.to article is that each ZoomEye figure answers a different question, and neither is a tally of victims. The 436,403 figure sizes the population of internet-visible Drupal deployments worth reviewing. The zero says only that this CVE is not indexed as an exposed service. Neither figure reveals how many hosts run an affected module, which is the number that actually matters.

For remediation, the analysis recommends treating the product count purely as a scoping tool, using the module list to define what to check, and patching every affected module to the fixed release for its branch. It also advises keeping the two kinds of evidence apart when reporting: facts about internet-visible Drupal services on one side, facts drawn from your own module inventory on the other.

Why it matters

Exposure counts are routinely over-read in both directions. A zero result against a 9.8-scored vulnerability looks like good news and is anything but: it reflects the difficulty of fingerprinting module-level flaws and the lag in indexing newly assigned identifiers, not an absence of risk. Teams that read an empty scan as proof of safety will deprioritise patches they should be applying now. Conversely, 436,403 indexed Drupal hosts is not 436,403 compromised sites, and framing it that way misinforms just as badly. The only dependable signal in this story is internal: knowing which of the 16 modules you run and upgrading each one to its listed fixed release.