Drupal SA-CORE-2026-014: A Practical Incident-Response and Upgrade Runbook for the Field UI RCE

Tim Rabbetts | October 17, 2026

Drupal site owners have had to treat the 14 October 2026 core security release as an emergency maintenance event. Security advisory SA-CORE-2026-014 describes a critical remote-code-execution vulnerability in Drupal’s Field UI module, rated 19 out of 25 by the Drupal Security Team. The advisory states that the vulnerable functionality is not directly exploitable with core alone, but that serious exploit paths exist when contributed modules or custom code expose the affected behaviour. At least one known path does not require authentication. ([drupal.org](https://www.drupal.org/sa-core-2026-014))

This is not a “wait for the next normal maintenance window” update. It is a structured response exercise: establish whether the site is affected, apply the supported core release, confirm that the deployment is complete, and investigate evidence of compromise before declaring the incident closed. This runbook is designed for Drupal developers, technical site owners and hosting teams operating Composer-managed Drupal installations.

What SA-CORE-2026-014 affects

The affected component is the Field UI module in Drupal core. The published affected ranges are:

  • Drupal 8.9.0 through versions before 10.6.19.
  • Drupal 11.0.0 through versions before 11.3.19.
  • Drupal 11.4.0 through versions before 11.4.10.
  • Drupal 12.0.0-alpha1 through versions before 12.0.0-beta2.

The recommended fixed releases are Drupal 10.6.19, Drupal 11.3.19 and Drupal 11.4.10, depending on the supported branch used by the project. Drupal 10.5.x and earlier, Drupal 11.2.x and earlier, and Drupal 8 and 9 are not covered by current security support and should not be treated as acceptable long-term destinations for a security response. ([drupal.org](https://www.drupal.org/sa-core-2026-014))

The most important operational distinction is between affected and exploitable in your deployment. Do not spend the first few hours trying to prove that your particular combination of modules is exploitable. The advisory explicitly warns that contributed modules and custom code can create serious exploit paths. Treat every supported installation in an affected version range as requiring an update.

First response: establish the scope

Identify the deployed Drupal version

Run the checks against the actual production release, not just the branch recorded in a ticket or the version displayed on a development workstation.

drush status --fields=drupal-version,root,uri
composer show drupal/core-recommended --direct
composer show drupal/core --direct

On projects using the drupal/core-recommended metapackage, the first Composer command is usually the most useful representation of the locked core version. Some projects use drupal/core directly, while others have a custom Composer structure. Inspect composer.json and composer.lock rather than assuming every Drupal site is built in the same way.

You can also inspect the lock file without bootstrapping Drupal:

composer show drupal/core-recommended --locked
composer show drupal/core --locked

If the production host does not contain Composer, obtain the version from the immutable build artefact, deployment manifest or release metadata. Avoid running an improvised Composer update directly on a production web server unless that is explicitly how the platform is designed to operate.

Check whether Field UI is enabled

The advisory identifies field_ui as the vulnerable core module. Its presence is common on editorial and administrative Drupal sites because it provides the interface for managing fields and related configuration.

drush pml --status=enabled --type=module --fields=machine-name,name,status | grep -E 'field_ui|field'

Do not interpret the absence of an enabled Field UI module as permission to postpone the core update. The advisory’s scope is based on affected core versions and the possibility that contributed or custom code exposes relevant functionality. The module check is useful for triage and mitigation, not for replacing the upgrade.

Record the current state before changing anything

Before applying the update, capture enough information to reconstruct what happened. At minimum, record the current Git commit, Composer lock hash, Drupal version, enabled extensions, deployment time and database backup identifier.

git rev-parse HEAD
sha256sum composer.lock
drush status --fields=drupal-version,db-status,bootstrap,uri
drush pml --status=enabled --type=module --fields=machine-name,status
drush config:status

If configuration changes are pending, decide whether they belong in the security deployment. A security release should normally be kept as narrow as possible. Mixing it with unrelated content-model changes, theme work or large dependency upgrades makes validation and rollback harder.

Temporary mitigation when the update cannot happen immediately

The advisory states that uninstalling the core Field UI module can mitigate the vulnerability while the site is being updated. ([drupal.org](https://www.drupal.org/sa-core-2026-014)) This should be regarded as a temporary containment measure, not a substitute for installing the fixed core release.

Before uninstalling anything, determine whether the module is required by site administrators, deployment scripts or custom administrative workflows. Removing Field UI can affect the ability to create or modify fields through the user interface. It should also be performed through the normal configuration and deployment process, with a database backup and a tested rollback path.

drush pm:uninstall field_ui -y
drush cr

Do not run that command blindly on a production site. First test it on a production-like environment and confirm that configuration imports, editorial workflows and administrative login remain usable. If Field UI cannot be removed safely, prioritise the core update and use network-level controls, restricted administration access and maintenance mode as additional short-term controls.

Drupal Steward protection may block some known attack vectors, but the security advisory explicitly says that Steward protection does not cover every possible exploit and that sites still need to upgrade. ([drupal.org](https://www.drupal.org/sa-core-2026-014)) A WAF rule or managed protection layer is useful defence in depth; it is not evidence that the application is fixed.

Build the security update with Composer

Use the project’s existing dependency model

For a Composer-managed Drupal project, update the Drupal core packages through the project’s normal build process. Do not edit composer.lock manually and do not download a replacement Drupal tarball into a Composer-managed codebase.

A typical Drupal 11 project using core’s recommended package can update the relevant core packages with:

composer update \
  drupal/core-recommended \
  drupal/core-composer-scaffold \
  drupal/core-project-message \
  --with-all-dependencies

A project that uses drupal/core directly may instead update that package and the associated scaffold and project-message packages:

composer update \
  drupal/core \
  drupal/core-composer-scaffold \
  drupal/core-project-message \
  --with-all-dependencies

The exact command depends on the project’s declared requirements. Before updating, inspect the root package definition:

composer why drupal/core-recommended
composer why-not drupal/core-recommended 11.4.10
composer prohibits drupal/core-recommended 11.4.10

Use the fixed version appropriate to the project’s branch. Do not force Drupal 11.4.10 onto a Drupal 10.6 project simply because it is numerically newer. A major-version migration is a separate change with its own compatibility testing, contributed-module review and deployment plan.

Review the dependency diff

A security update should produce an explainable dependency diff. Review the result before committing it:

git diff -- composer.json composer.lock
composer validate --strict
composer audit

composer audit is a useful additional check, but it does not replace Drupal’s own security advisories. Drupal contributed projects, application configuration and custom code are not fully represented by a generic PHP dependency audit.

Pay particular attention to unexpected updates outside Drupal core. The --with-all-dependencies option may move transitive packages where the dependency graph requires it. That is often correct, but it should be visible in code review and tested rather than accepted without inspection.

Deploy safely

The safest production deployment is a repeatable release, not a sequence of commands typed into a live server. Build the Composer dependencies in CI or a controlled build environment, run automated tests, package the result and deploy the resulting artefact consistently across web nodes.

A simple deployment sequence might look like this:

drush state:set system.maintenance_mode 1 -y
drush cr

drush updatedb -y
drush config:import -y
drush cr

drush status --fields=drupal-version,db-status,bootstrap
drush state:set system.maintenance_mode 0 -y
drush cr

The exact order depends on the hosting platform and whether configuration import is part of the release process. Do not import configuration automatically if your deployment model intentionally separates security code releases from configuration changes. The critical requirement is that the database updates, configuration and code are compatible with one another.

On a multi-webhead installation, ensure that every node receives the same release. A partially upgraded cluster can produce confusing failures: one node may serve old class files while another serves the patched code, or different nodes may report different Drupal versions depending on load balancing.

Validate the release from outside the application

After deployment, validate the site as both an operator and an external observer. Check the version from the release directory or container image, then exercise representative routes:

  • Anonymous front-page and content requests.
  • Authenticated editor login.
  • Administrative login for a controlled test account.
  • Field and content-type administration, if Field UI remains enabled.
  • JSON:API, REST or other public integration endpoints.
  • Form submissions, file uploads and cache-backed pages.
  • Queue workers, cron and scheduled deployment jobs.

Watch PHP-FPM, web-server and Drupal logs during and after the deployment:

drush watchdog:show --count=100 --severity=Error
journalctl -u php-fpm --since "30 minutes ago"
journalctl -u nginx --since "30 minutes ago"

The service name varies by distribution and hosting platform. On some systems PHP-FPM is versioned, and on container platforms logs are retrieved through the orchestrator rather than journalctl. The principle is the same: inspect application and infrastructure telemetry around the maintenance window.

Investigate possible compromise

A patched site is not automatically a clean site. Because SA-CORE-2026-014 is a remote-code-execution vulnerability, treat unexpected changes around the exposure window seriously. The advisory was published on 14 October 2026 and warns that exploit development can occur quickly after disclosure. ([drupal.org](https://www.drupal.org/security/p))

Preserve evidence before deleting suspicious files or rotating logs. At a minimum, retain:

  • Web-server access and error logs covering the period before the upgrade.
  • Drupal watchdog records and authentication logs.
  • PHP-FPM, container and operating-system logs.
  • The pre-update code and database backup.
  • Composer manifests, lock files and deployment metadata.
  • File integrity results for webroot, public files and private files.

Look for high-value indicators

Review requests to administrative and unusual routes, especially requests with unexpected query parameters, encoded payloads or unusual methods. Correlate them with successful logins, account changes, newly created content and filesystem modifications.

grep -Ei 'POST|PUT|PATCH|DELETE' /var/log/nginx/access.log | tail -n 200
grep -Ei 'admin|user/login|field|ajax|jsonapi|rest' /var/log/nginx/access.log | tail -n 200
find web -type f -newermt '2026-10-01' -print

The date passed to find is only an example. Use the actual period relevant to your site, including the time before the public disclosure and the time between disclosure and patching. Be cautious with automated “malware scanners”: an unfamiliar file is not necessarily malicious, and a clean scan is not proof that no code execution occurred.

Review administrative accounts and recent permission changes. Unexpected privileged users, modified roles, new API credentials, altered cron jobs and unfamiliar service accounts warrant escalation.

drush sql:query "SELECT uid, name, status, created, access FROM users_field_data ORDER BY uid"
drush sql:query "SELECT uid, name, rid FROM user__roles ORDER BY uid, rid"

Database table names and available fields can vary with Drupal versions and custom schemas, so verify queries against a non-production database first. For a serious suspected compromise, involve the hosting provider, an incident-response specialist or the organisation’s security team rather than attempting to clean the site casually.

Common upgrade failures and how to diagnose them

Composer refuses the fixed version

This usually indicates a root constraint, an outdated package, a PHP-platform requirement or another dependency that blocks the target release. Start with composer why-not and inspect the complete solver output. Do not solve the problem by deleting the lock file: that turns a targeted security update into an uncontrolled dependency re-resolution.

Database updates fail after code deployment

Restore the previous release only if the database has not been changed, or follow the project’s tested rollback procedure. Once database updates have partially run, a code rollback may not be safe. This is why database backups, release directories and a staging rehearsal matter more than speed alone.

Administrative pages fail after the update

Clear Drupal caches first and inspect PHP errors. Then check custom modules and contributed modules for deprecated APIs, service changes or assumptions about Field UI routes. A security release should not normally require broad application rewrites, but custom integrations can expose compatibility issues that automated tests did not cover.

Some web nodes still report the old version

Check the load balancer, document roots, container image digests and release symlinks. Confirm that opcache has been reset or restarted according to the hosting model. Never assume that deploying files to one node updates all nodes.

Hardening after the emergency patch

Once the fixed release is running, convert the incident into an improvement programme rather than closing the ticket immediately.

  • Subscribe production and development teams to Drupal security advisories.
  • Maintain a documented supported-version policy for Drupal core and PHP.
  • Automate dependency update pull requests, but require human review and deployment testing.
  • Keep production administration behind strong authentication, restricted networks or an access proxy where practical.
  • Use least-privilege roles and review who can administer fields, menus, text formats and custom code.
  • Separate build, deployment and runtime credentials.
  • Keep private files outside the public document root and verify web-server execution rules.
  • Retain centralised logs long enough to investigate security disclosures.
  • Test restoration of both database and files rather than merely creating backups.

It is also worth reviewing whether Field UI is needed on production at all. Some tightly controlled installations manage field configuration through version-controlled configuration and limit administrative modules in production. That approach is not suitable for every editorial organisation, but reducing exposed administrative functionality can lower operational risk.

A concise response checklist

  1. Confirm the deployed Drupal core version and affected branch.
  2. Record the current release, lock-file hash, configuration status and backups.
  3. Assess whether Field UI is enabled and whether temporary removal is practical.
  4. Build the appropriate fixed release: Drupal 10.6.19, 11.3.19 or 11.4.10.
  5. Review the Composer diff and test the complete dependency set.
  6. Deploy consistently to every web node or container.
  7. Run required database updates, configuration steps and cache rebuilds.
  8. Validate anonymous, authenticated, administrative and API paths.
  9. Review logs, accounts, files and deployment history for indicators of compromise.
  10. Document the response and improve the next-update process.

Conclusion

SA-CORE-2026-014 is precisely the kind of Drupal vulnerability that exposes the weakness of version-only patching. The fixed package matters, but so do deployment discipline, access control, logging and post-update investigation. The advisory’s affected ranges and mitigation guidance provide a clear starting point; the responsibility of each site team is to turn that guidance into a controlled, evidenced production response.

Upgrade affected sites to the supported fixed release without delay, avoid treating Drupal Steward or a WAF as a replacement for patching, and preserve enough evidence to determine whether the site was merely vulnerable or actually compromised. That combination of rapid remediation and careful verification is the difference between closing a security ticket and completing a security incident response.