A Practical Drupal Runbook for the Critical Core Security Release on 14 October 2026

Tim Rabbetts | October 14, 2026

Drupal’s Security Team has announced a critical core security release for 14 October 2026, scheduled between 16:00 and 21:00 UTC. The announcement affects every currently supported Drupal core branch, but deliberately withholds technical details until the release is published. That disclosure model is intended to reduce the opportunity for attackers to develop an exploit before site owners can update. ([drupal.org](https://www.drupal.org/psa-2026-10-12?utm_source=openai))

This is therefore not the moment for speculative vulnerability analysis. It is the moment for operational preparation. A well-managed Drupal site should be able to identify its exact core version, produce a repeatable deployment artefact, test the update in a production-like environment, deploy it through the normal approval path and preserve enough evidence to investigate unexpected behaviour afterwards.

What Drupal has confirmed

The public service announcement rates the forthcoming issue as critical, with a risk score of 19 out of 25. The affected versions include Drupal 11.4.x, Drupal 11.3.x and Drupal 10.6.x. Drupal 12.0.0-beta1 is also affected, while versions older than Drupal 10.6.x and Drupal 11 releases older than 11.3.x are already end-of-life. ([drupal.org](https://www.drupal.org/psa-2026-10-12?utm_source=openai))

The announcement does not identify the affected subsystem, provide a CVE, describe an exploit path or publish a mitigation. Those details are expected with the security advisory during the release window. Treat any unofficial claims about the vulnerability mechanism as unverified until the official advisory is available.

Drupal has also stated that Drupal Steward provides protection against some known attack vectors, but not all possible exploits. Steward is useful defence in depth; it is not a substitute for applying the security update. ([drupal.org](https://www.drupal.org/psa-2026-10-12?utm_source=openai))

Start with an accurate inventory

The first practical task is to establish what is actually deployed. Do not rely on a spreadsheet that was last updated during the previous release cycle. Drupal sites often have differences between local development, integration, staging and production, especially when emergency hotfixes or manual server changes have been made.

Record the deployed Drupal version

From the Drupal project directory, use Composer to inspect the installed core package:

composer show drupal/core-recommended

If the project uses drupal/core rather than drupal/core-recommended, inspect that package instead:

composer show drupal/core

Drush can provide a useful application-level confirmation:

vendor/bin/drush status

Capture the output in the deployment record, along with the Git commit, environment name, PHP version, database engine and web server version. The objective is not bureaucracy: when a critical update behaves differently across environments, these details are often the shortest route to the cause.

Check the project’s dependency strategy

Inspect composer.json and determine whether the site follows Drupal’s recommended package structure. A typical project will contain a requirement similar to this:

{
  "require": {
    "drupal/core-composer-scaffold": "^11.3",
    "drupal/core-project-message": "^11.3",
    "drupal/core-recommended": "^11.3"
  }
}

The exact constraint will vary by project. Do not replace an existing constraint with the example above without understanding the site’s current branch and upgrade policy. The important point is that the lock file, rather than an unrecorded command run directly on production, should determine the deployed dependency set.

Also check whether the site uses patches, custom repositories or pinned third-party libraries:

composer validate
composer outdated --direct
composer config --list
git status --short

A clean working tree is especially valuable before a security update. If there are uncommitted changes to composer.json, composer.lock or scaffolded files, stop and resolve them before attempting the release.

Prepare the update before the security window

Drupal’s advisory recommends updating to the latest supported bugfix release before 14 October so that unrelated upgrade problems are discovered in advance. This is a sensible distinction: the security update may be urgent, but it should not be the first time the team discovers that the project has a broken patch, an incompatible PHP version or an unreviewed dependency conflict. ([drupal.org](https://www.drupal.org/psa-2026-10-12?utm_source=openai))

Bring the current branch up to date

First create a branch dedicated to preparation:

git switch -c chore/prepare-drupal-core-security-update
composer update --with-all-dependencies --dry-run

The dry run is useful for identifying conflicts without changing the lock file. Once the proposed changes are understood, update the Drupal core packages used by the project. For a project based on drupal/core-recommended, a common command is:

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

Do not blindly copy this command into every project. Some sites use a different core package arrangement, custom scaffolding or a wider dependency update policy. Review the resulting diff carefully:

git diff -- composer.json composer.lock
composer show --outdated
composer audit

composer audit is a useful additional signal, but it does not replace Drupal’s own security advisory process. It may report vulnerabilities in packages that are not exploitable in the site’s configuration, and it may not immediately describe a Drupal-specific issue. Treat it as a dependency hygiene check rather than a final security verdict.

Do not update directly on production

Running Composer on a production server makes the server both the build environment and the deployment target. That creates avoidable uncertainty: the result can depend on network availability, repository state, credentials, PHP extensions and the contents of the local Composer cache.

A safer workflow is:

  1. Resolve dependencies in a controlled build environment.
  2. Commit composer.json and composer.lock.
  3. Build the application artefact, including the vendor directory and Drupal scaffold files.
  4. Run automated tests against that artefact.
  5. Deploy the same artefact to staging and production.

If your hosting platform requires Composer to run during deployment, make sure the command uses the lock file and fails on errors:

composer install \
  --no-interaction \
  --prefer-dist \
  --no-progress \
  --optimize-autoloader

For production builds, the project may also use --no-dev, depending on how development and test dependencies are separated:

composer install \
  --no-dev \
  --no-interaction \
  --prefer-dist \
  --no-progress \
  --optimize-autoloader

Keep the exact build command in version control or in the deployment pipeline definition. A security release is a poor time to rely on institutional memory.

Test the update like a production change

A Drupal core security update can alter behaviour in areas that are not obviously related to the vulnerability. Core dependencies, request handling, rendering, database queries, JavaScript libraries and administrative forms may all be involved. The right test suite depends on the site, but every production Drupal deployment should have a small set of meaningful smoke tests.

Run automated checks

At a minimum, run the project’s existing test commands after Composer has resolved the new packages. Examples might include PHPUnit, PHPStan, code style checks and custom integration tests:

vendor/bin/phpunit
vendor/bin/phpstan analyse
vendor/bin/phpcs --standard=phpcs.xml web/modules/custom web/themes/custom

Only run commands that are genuinely configured in the project. If the repository does not contain PHPUnit configuration or PHPStan configuration, do not invent a new test expectation during the incident window. Record which checks were run and which were not available.

Exercise the important user journeys

Browser-level testing is particularly valuable for Drupal because many high-impact failures occur at the boundary between PHP, forms, JavaScript and caching. Test the workflows that would cause immediate business or operational damage if they failed:

  • Anonymous page delivery and cache hits.
  • User login, password reset and logout.
  • Content creation, editing, moderation and publication.
  • Media upload and image derivative generation.
  • Forms, email notifications and integrations.
  • JSON:API or REST responses used by external applications.
  • Search, feeds, sitemaps and scheduled jobs.
  • Commerce checkout and payment confirmation, where applicable.

For sites using Playwright or another browser automation framework, the security update is a good reason to run the existing suite rather than create a large new suite from scratch. The Drupal community has recently been discussing browser-based regression testing as part of a dependable update process, which reflects the practical reality that a successful security deployment must preserve important journeys as well as close the vulnerability. ([drupal.org](https://www.drupal.org/planet?sa=X&ved=0CB4Q9QEwA2oVChMIz-7Oxb70xgIVjqKICh0DTwUw&utm_source=openai))

Check configuration synchronisation

Do not confuse a code update with a configuration import. A core security release normally changes code and dependency versions; it should not require importing unrelated configuration from another environment.

Before deployment, inspect whether the update has created unexpected configuration changes:

vendor/bin/drush config:status

If configuration changes are expected as part of the release, review them separately and document why they are included. Mixing a security update with unrelated content, configuration or feature work makes rollback and incident analysis harder.

Apply the release safely

Once the official advisory and package versions are published, confirm the affected branches and the required target version. Do not assume that the highest available version is always the right answer; follow the advisory’s instructions for each supported branch.

Update the project in the controlled build environment, commit the resulting lock file and build the release artefact. Then deploy it using the normal process. A typical Drush sequence after the new code is active is:

vendor/bin/drush updatedb -y
vendor/bin/drush cache:rebuild
vendor/bin/drush status

Run updatedb only when the release contains database updates. Drush will report whether updates are pending, but the deployment process should still treat database updates as an explicit step with backups and monitoring.

For a horizontally scaled Drupal site, ensure that all web nodes receive the same release before traffic is distributed between old and new code. Mixed application versions can create intermittent failures, particularly when services, schema changes or cached containers differ between nodes.

Take and verify backups

A backup that has never been restored is an assumption, not a recovery plan. Before the production update, verify that the database backup completes successfully and that the backup is accessible from the recovery environment. If the site stores user-uploaded files outside the database, include the relevant files or confirm that they are covered by a separate backup system.

A rollback plan should identify:

  • The previous application artefact or Git commit.
  • The previous database backup.
  • The person authorised to initiate rollback.
  • The point at which rollback becomes safer than continued diagnosis.
  • How cache, queues, cron and background workers will be handled.

Do not automatically restore a database simply because the application deployment has failed. If the update made no schema changes, reverting code may be sufficient. If database updates were applied, restoring the database may be necessary, but that decision must be based on the release’s actual update path.

Monitor for compromise, not only breakage

The critical rating and the warning that exploits may be developed within hours or days mean that post-deployment monitoring matters. A green deployment pipeline confirms that the release was installed; it does not prove that the site was not attacked before the update.

Review logs for unusual activity before and after deployment. Depending on the infrastructure, examine:

  • Web server access logs for unusual request patterns, unexpected methods or repeated requests to administrative and upload paths.
  • Drupal watchdog records for unexpected account, permission, configuration or content changes.
  • Authentication logs for new logins, password resets and one-time login activity.
  • File system changes in writable directories.
  • Database changes to users, roles, permissions and configuration.
  • Outbound network connections from the application server.
  • Queue and cron behaviour, especially unexplained jobs or repeated failures.

Preserve relevant logs before rotating or deleting them. If compromise is suspected, avoid making extensive changes that destroy evidence. Isolate the affected environment where practical, involve the organisation’s incident-response process and consult the official Drupal guidance rather than treating the event as an ordinary failed deployment.

Common mistakes to avoid

Waiting for a full technical explanation before preparing

Drupal’s disclosure policy intentionally means that the most useful technical details are not available before the release. You do not need to know whether the vulnerability concerns access control, input validation, rendering or a third-party library to prepare a reproducible update process.

Assuming a WAF or Drupal Steward makes patching optional

Protective layers can reduce exposure to known patterns, but they cannot guarantee coverage for every exploit path or deployment configuration. Drupal explicitly states that Drupal Steward does not cover all possible attack vectors for this release. ([drupal.org](https://www.drupal.org/psa-2026-10-12?utm_source=openai))

Testing only the homepage

The homepage can remain healthy while editorial forms, authenticated APIs, media handling, queues or payment callbacks are broken. Use a short, prioritised workflow list that reflects how the organisation actually uses Drupal.

Combining the security update with unrelated upgrades

Updating Drupal core, replacing a mail provider, changing PHP, upgrading a front-end build and importing a large configuration set in one deployment creates a poor diagnostic environment. Keep the security change as isolated as the project schedule allows.

Forgetting unsupported versions

Sites running Drupal 10 versions older than 10.6.x or Drupal 11 versions older than 11.3.x are already outside the supported range. The October advisory is an immediate reason to upgrade, but remaining on an unsupported branch also leaves the site exposed to previously disclosed issues. ([drupal.org](https://www.drupal.org/psa-2026-10-12?utm_source=openai))

A concise release-day checklist

  1. Confirm the official advisory and affected target versions.
  2. Record the current production commit, Drupal version, PHP version and dependency lock file.
  3. Confirm backups and recovery access.
  4. Build the update in a controlled environment using the lock file.
  5. Review Composer changes and security advisories.
  6. Run automated tests and the site’s critical browser or smoke tests.
  7. Deploy the same artefact to production.
  8. Run required database updates and rebuild caches.
  9. Verify anonymous, authenticated, editorial and integration workflows.
  10. Monitor logs, errors, authentication and file-system activity.
  11. Record the final deployed versions and advisory status.

Conclusion

The most important fact about Drupal’s 14 October 2026 security release is that it has been announced as critical while its technical details remain private until publication. That combination rewards preparation rather than speculation.

For a Composer-managed Drupal site, readiness means knowing the exact deployed state, keeping the supported branch current, building reproducible artefacts, testing the workflows that matter and having a recovery plan that has been exercised. Once the official advisory is available, the update itself should be a controlled execution of that process, not an improvised production experiment.

Drupal’s recent security history also demonstrates why this needs to become routine operational practice. Core advisories have recently covered issues involving third-party libraries, cross-site scripting, access control, file handling and request processing, while contributed projects have exposed risks in areas such as authentication, JSON:API access and template rendering. ([drupal.org](https://www.drupal.org/security?utm_source=openai)) A dependable Drupal team therefore treats security releases as a normal, testable deployment capability—urgent when necessary, but never mysterious.