Drupal's 14 October 2026 disclosure put two critical remote code execution advisories in front of site teams at once, with an advance warning that exploits might follow within hours or days. A change plan that treats this as two separate tickets will usually miss the dependency between them.

What has to land in the same window

  • Core: 10.6.19, 11.3.19, or 11.4.10, or 12.0.0-beta2 or later on the pre-release line, for CVE-2026-108097.

  • Module: Entity List 3.0.10, for CVE-2026-108099.

  • Optional interim: uninstall the core field_ui module if core cannot be upgraded in the window, which the Field UI advisory names as a mitigation.
    Core alone is not a complete fix. Entity List is a separately versioned contributed module, so a maintenance task that only updates core leaves CVE-2026-108099 open. Sequencing them in one window also avoids testing the same site twice.

Who needs a different plan

Three groups do not fit the simple patch template.

  • Sites on Drupal 10.5.x or earlier, and 11.2.x or earlier: no security coverage, so the work starts with a branch upgrade and compatibility testing for every contributed module in use.

  • Sites on Drupal 8 or 9: end of life, no fix available. The plan is a migration, and until it completes the site is permanently exposed to CVE-2026-108097.

  • Sites with heavy custom field handling: the advisory's statement that custom code may expose the vulnerable functionality means these sites need a code review, not just a version bump.

Test scope worth defining before the window

Because the advisories describe reachability through contributed modules and custom code, the regression test should cover the paths that involve field definitions and entity listing, not only content editing. Concretely: creating and rendering user-driven field structures, any endpoint that accepts structured input and maps it into fields, and any Entity List rendering used on public pages. A test plan that only verifies the administrative interface exercises a different code path from the one an unauthenticated attacker would use.

Communicate the exposure honestly

The security risk score for both advisories is 19/25 with exploitation rated Theoretical, and the vendor warned that exploits might be developed shortly after disclosure. Those two statements are compatible: the score describes exploit maturity at publication, the warning describes expected speed. When briefing stakeholders, do not present the Theoretical rating as a reason to defer, and do not present the 436,580-asset Drupal fingerprint count as a count of vulnerable hosts. The number describes a large reachable population, not confirmed compromise.

Rollback and aftercare

Rollback for a failed core update is a version revert to the previous release, not a database restore, because the security release does not require schema changes that would block reverting. After the window, confirm the running versions again, check whether field_ui was removed on any site where the core update slipped, and record the Entity List version per site so the next module advisory starts from a current inventory.

References