Establish scope and select a patch target
Drupal’s October 14, 2026 advisory identifies fixes for CVE-2026-108097, a Field UI remote code execution vulnerability rated Critical 19/25. Drupal says core alone does not directly expose exploitation. According to the advisory, contributed modules expose serious exploitation paths, including at least one unauthenticated path. Custom code can also expose the vulnerability. For October 15 deployments, start by identifying affected sites and their upgrade paths. Sources: Drupal.org
The advisory identifies Drupal 10.6.19, 11.3.19 and 11.4.10 as fixed releases. The table lists those releases; it is not a complete affected-version or support-coverage matrix. Sources: Drupal.org
Table
Stable Drupal branches and released fixes
| Intended stable branch | Released fix |
|---|---|
| Drupal 10.6.x | 10.6.19 |
| Drupal 11.3.x | 11.3.19 |
| Drupal 11.4.x | 11.4.10 |
Drupal’s advisory does not identify every vulnerable module combination or establish whether exploitation occurred in the wild. Its theoretical exploitation rating does not rule out past exploitation. According to the advisory, Drupal Steward covers some known vectors, not every possible exploit. Keep patch completion as the goal. Sources: Drupal.org
Capture a baseline for every deployment and site
This guide recommends building the target list from infrastructure records before collecting versions. Include every serving replica, container or release directory and each multisite URI it serves. Keep unreachable targets as unresolved entries.
Record the core version and Field UI state in the intended project and runtime for each site. Keep lockfile, installed-package and running-site observations separate in the deployment record. Confirm that each observation refers to the intended site and deployment.
Apply temporary mitigation and preserve its configuration
If patching must wait, Drupal names uninstalling Field UI as temporary mitigation. Before changing module state, this guide recommends retaining restorable database and file backups and the current configuration export. Sources: Drupal.org
Review dependencies and configuration consequences before applying the mitigation to each site. Test editorial forms and displays, and review any dependent-module removals in staging.
This guide recommends reconciling the uninstall with the pipeline’s imported configuration, including environment-specific transformations. Review the full export diff and test the next import to check that the mitigation persists. Allow deliberate re-enablement only after successful patch verification.
Plan the dependency update
Inspect composer.json for core-recommended, exact pins and minor-version constraints before updating. Select a fixed release appropriate to the project and review the dependency changes needed to reach it.
Use a project-specific update procedure that has been checked against the installed tools and tested in staging. Review dependency conflicts and test the resulting dependency set before release.
Test and deploy the resolved release
Exercise the resolved dependencies in staging, including custom modules and temporary configuration changes. This guide recommends retaining composer.json and composer.lock with the release record and deploying through the project’s tested release process.
Confirm the sequence of code deployment, database updates and cache rebuilding in that process before production rollout. Coordinate database updates per site and database instead of launching competing jobs on every replica. Retain installation, database-update and cache-rebuild results with the release record. Run application tests as well.
Verify serving deployments and retain evidence
Repeat the baseline version and module checks inside every serving deployment, selecting every site URI. This guide recommends comparing command-line and web version observations for the same site and backend. Route checks to identifiable backends using the platform’s existing facilities. Repeated requests through a load balancer do not establish which replicas were checked.
If command-line and web results disagree, confirm that both refer to the same release, document root, site and backend. Compare the intended lockfile or artifact with installed package metadata and actual core files. Investigate incomplete rollout, stale processes and caches as hypotheses, then repair or redeploy and repeat both checks. The proposed template below is this guide’s operational recommendation for collecting deployment evidence.
Table
Proposed deployment verification record
| Evidence field | Record |
|---|---|
| Target | Environment, instance/container ID, site URI |
| Release identity | Commit, artifact/image digest, lockfile checksum |
| Version observations | Locked package, installed package, Drush, web status |
| Extension state | field_ui status and reviewed dependent-module changes |
| Release completion | Database-update and cache-rebuild results |
| Functional checks | Anonymous, authenticated and administrative outcomes |
| Audit details | UTC verification time, operator/job, retained output |
Verify Field UI’s expected state and smoke-test anonymous access, authenticated login and editing, administrative access and representative field rendering. Check whether field-management interfaces are present or absent as intended. Use the following completion states to distinguish mitigation, patching and verification. Retain unresolved targets even when other deployments pass, and keep compromise assessment separate from rollout checks.
- Mitigated: the relevant site’s Field UI uninstall is verified.
- Patched: the intended fixed core release is verified in the serving deployment.
- Fleet verification record: every inventoried deployment and site has matching evidence or an explicitly unresolved exception.