Drupal advisory WID-SEC-2026-3554 covers 36 CVEs in 16 modules as 436,286 installs sit exposed

What the advisory covers

On 23 September 2026, CERT-BUND published advisory WID-SEC-2026-3554 and rated it high risk. According to a dev.to analysis of the advisory, it bundles 36 CVE identifiers across 16 contributed Drupal projects, and fixed releases already exist for every one of them. That makes this less a disclosure event and more a deadline: the patches are out, so the only variable left is how quickly operators apply them.

The affected projects include Webform, Webform REST, Cloud, Project Browser, Commerce Decoupled Checkout, Mermaid Diagram Field, CookieCuttr, REST & JSON API Authentication, Stop administrator login, Tawk.to Live chat application, Editoria11y Accessibility Checker, AI CKEditor, Combined image style, CSS Usage Analyzer, Smart Content and Diba carousel slider.

The fixed versions named in the advisory include 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 and Diba carousel slider 3.0.2.

What the 436,286 number actually measures

A ZoomEye query for the Drupal fingerprint, executed on 24 September 2026, returned 436,286 matching assets, the dev.to post reports. The caveat matters as much as the headline figure: the fingerprint appears in headers, page titles and response bodies, so the count describes Drupal deployments visible to the scanner. It cannot say which contributed modules any of them run, because module code and configuration sit behind authentication.

The practical reading, per the analysis, is that the pool of potential targets is large and attackers do not need a published victim list to find them. They scan for Drupal and then probe for known module routes. Deployments behind an internal reverse proxy or a VPN present a smaller practical window than a site answering directly on port 443.

Where to start patching

The dev.to write-up singles out the authentication-related projects as the first priority for internet-facing sites. REST & JSON API Authentication and Stop administrator login guard the outer layer of an application, so flaws there can be reached without any prior foothold. A module that only becomes relevant after authentication is a lower-tier problem by comparison.

The suggested triage order is to start with sites that accept unauthenticated traffic from the public internet, inventory the contributed projects each one runs, and compare versions against the advisory. A site running five of the affected projects is a different priority from one running none. Rank by reachability rather than raw CVE count: an API module exposed without rate limiting outranks several authenticated-only issues.

Response steps

The recommended sequence is straightforward. Patch the identified projects to their fixed releases and confirm that the files on disk actually changed. While the update campaign runs, restrict unauthenticated access to administrative and API routes at the reverse proxy. Afterwards, operators can re-run the same exposure query to watch how quickly the population of unpatched hosts shrinks.

Why it matters

The combination is what makes this urgent rather than routine. A single advisory touches three dozen vulnerabilities across widely used contributed modules, a simple fingerprint query puts roughly 436,000 Drupal deployments on a map anyone can query, and at least two of the affected projects defend the authentication layer itself. Because fixed releases exist for everything listed, the exposure window is purely a function of patch speed. Teams that inventory their modules now and patch the internet-facing, pre-authentication surface first close most of the practical risk. Teams that wait are betting that attackers scan more slowly than their update calendar runs.