CERT-BUND advisory bundles 36 Drupal module CVEs; agencies patch 16 projects across client sites

A high-risk advisory aimed at modules, not core

On 23 September 2026, Germany's CERT-BUND published advisory WID-SEC-2026-3554 and rated it high risk. According to a dev.to write-up by an agency practitioner, the record collects 36 identifiers spanning CVE-2026-96355 through CVE-2026-96398, and every one of them sits in contributed Drupal projects rather than Drupal core. That distinction shapes the entire response: because the unit that needs patching is the individual module, no single platform upgrade clears the advisory, and shops running many client sites inherit the same 16-project question multiplied across their portfolio.

What the flaws allow

The advisory's outcome classes include arbitrary code execution, extended privileges, bypass of security mechanisms, data manipulation or disclosure, and cross-site scripting, and CERT-BUND confirms that fixes are available. It does not, however, tie any single identifier to a specific defect, and the technical details of how CVE-2026-96365 in particular is exploited have not been made public. The practical precondition described is simple: an affected module must be enabled on a site that is reachable. Sites that install none of the listed projects fall outside the advisory's scope.

On severity, CERT-BUND rates both probability and damage at 4 out of 4, with a CVSS v3.1 base score of 9.8 and a temporal score of 8.5.

Sixteen projects, nineteen fixed releases

According to CERT-BUND's structured record, the advisory covers 16 projects with 19 fixed releases in total, since several projects maintain two supported branches:

• 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

Reading the exposure numbers correctly

The dev.to post reports a ZoomEye query for Drupal-tagged assets returning 436,403 results on 27 September 2026. That figure measures the CMS's global footprint, not the number of vulnerable installations, and a companion ZoomEye query tagged with CVE-2026-96365 returned zero results. The author's point is that internet-wide scans answer the wrong question for an agency. What actually determines exposure is the internal inventory: which client sites run which of the sixteen modules, at which versions.

A workflow for coordinating many sites

The write-up's practical guidance is aimed at the coordination problem rather than the vulnerabilities themselves:

• Sequence the rollout around testing capacity instead of the advisory's publication date.
• Group client sites by the modules they have in common, so a single test pass validates several sites, then apply the fixed release for each supported branch.
• Delete modules that no client actively uses, since an unused module still carries security and maintenance overhead while returning nothing.
• Record the module versions running on every site once the patch window closes, so the next advisory can be handled by checking records instead of re-auditing from scratch.

The aggregate framing the author offers is that for multi-site operators, even a module present on a minority of sites generates real work, and the update window has to be scheduled per site rather than per module.

Why it matters

This advisory illustrates a structural feature of contributed-module ecosystems like Drupal's: security work lands on integrators and agencies, not on a single vendor shipping one patch. A 9.8-base-score cluster with fixes already available is a solvable problem, but only for teams that know what they run. The scarce resource here is coordination capacity — testing, scheduling and record-keeping across dozens of client sites — and the recommended mitigations target exactly that: shared-module test grouping, branch-aware version bumps, pruning dead dependencies, and durable per-site inventories that make the next advisory a lookup rather than an investigation.