CERT-BUND's high-risk Drupal advisory puts 36 CVEs in 16 contributed modules

The identifiers run from CVE-2026-96355 to CVE-2026-96398 ^[2]. That span covers 44 numbers and the batch holds 36 of them. A scanner rule that matches the whole range will therefore flag eight identifiers that are not in this batch ^[1].

A write-up of the advisory on dev.to explains how a bug in a contributed module gets reached. A contributed module is PHP code that runs inside Drupal's request cycle, usually with the privileges of the web server user ^[7]. A flaw becomes reachable when an anonymous or low-privilege visitor can get to the vulnerable controller, form or AJAX callback, and the attacker's input lands in a sink the module failed to protect ^[7].

The web user's privileges decide how far a compromise goes. Drupal keeps its database credentials in settings.php ^[8]. Code running as the web user frequently reaches that configuration, along with stored data well beyond the affected module ^[8].

The per-project detail is in the structured record's version list ^[10]. Thirteen of the projects have one fixed release each: Webform REST 4.2.1, Cloud 7.0.1, 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, 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 ^[12]. Add two each for the three two-branch projects and you get all 19 fixes ^[2]. Where a project has two fixed releases, the write-up advises reading that project's advisory before choosing a target version ^[18].

ZoomEye's large count is the number of Drupal deployments visible in its index ^[15]. According to the write-up, sizing exposure from it would take knowing which contributed modules each site runs, and at what version ^[15]. Its author treats the zero as a result about the index and not as evidence that no deployment is affected ^[15]. A zero for an identifier three days after the advisory came out mostly describes how far the index has caught up ^[3].

For a module that cannot be updated right away, the write-up says to disable or remove it ^[16]. Disabling takes the module's routes out of the request cycle, and the author rates that above blocking paths at a proxy ^[16]. I agree, and the reason is in the advisory itself. It publishes no per-CVE root cause, no proof of concept and no list of affected routes, so a proxy rule would be written against paths nobody has listed ^[5].

Drupal caches aggressively ^[17]. A container image or an unapplied database update can leave a correct-looking version string in front of vulnerable code ^[17].