Drupal high-severity advisory CVE-2026-96364 hits 16 contributed projects; patching requires version checks

High-severity advisory covers 16 contributed modules

According to a dev.to analysis, CERT-BUND published advisory WID-SEC-2026-3554 on 23 September 2026 for CVE-2026-96364, a high-rated and remotely exploitable vulnerability whose batch record ties it to 36 identifiers across 16 contributed Drupal projects. The record lists a CVSS 3.1 base score of 9.8 and a temporal score of 8.5, and its patch field confirms that fixes exist. Drupal core sits outside the advisory; the entire affected surface is third-party contributed code. The matching Drupal security advisories run from sa-contrib-2026-154 to sa-contrib-2026-191, also dated 23 September 2026.

No published trigger, no signatures

The central operational problem, as the dev.to write-up lays out, is that the batch record publishes no exploit trigger. A network signature needs a recognisable request pattern and a file-integrity check needs a known artefact; neither is available, and the record does not even map the identifier to a specific project. Class and version detail lives in the per-project advisories instead. Until a mechanism is published, hunting for exploit indicators only produces alerts that cannot be triaged.

Remote scanning cannot answer the question

Verification therefore has to rest on versions and inventory: read each site's installed project versions from its own status report or Composer lock file, then check them against the version ranges for the branch in use. An external scanner cannot see a module that sits behind authentication, so an organisation relying on remote scanning alone has not actually established whether it is exposed. The write-up illustrates the point with ZoomEye data: on 27 September 2026 a search for app="Drupal" returned 436,388 assets, while a search on the CVE string returned zero — a result that says more about how the index handles a fresh identifier than about real-world exposure.

The 16 projects and their fixed releases

The advisory names Webform (6.2.12 and 6.3.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 and JSON API Authentication (3.2.0), Stop administrator login (1.6), Tawk.to live chat (3.0.4), Editoria11y Accessibility Checker (2.2.23 and 3.0.9), Webform REST (4.2.1), 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). Several of these ship a separate fixed release per supported branch, so an inventory that assumes a single branch under-reports a mixed estate.

A remediation sequence that starts with inventory

The recommended order of operations is to build the version check first, because the same export feeds the patching work: list every installed project and version, compare against the range table, and label each row as affected, already fixed or absent. Update affected rows to the fixed release for their branch; where an update is not immediately possible, disable the module or restrict its routes. Re-verify from the status report afterwards, keep the export as the baseline for the next batch, and treat any indicator-based detection as supplementary until a mechanism is published.

Why it matters

A single high-rated, remotely exploitable identifier spread across 16 contributed projects, from Webform to Project Browser, is exactly the shape of advisory where detection tooling is weakest and inventory discipline pays off. Operators who can state, per site, which modules are installed and at which version can act within hours; those who depend on external scans or wait for exploit signatures cannot answer the exposure question at all. For anyone running a live Drupal estate, the export-and-diff exercise is cheap insurance this week, and it becomes a reusable asset for the next batch advisory.