By Greg Nowak. Updated 14 October 2026.
A Drupal security update can stall on surprisingly ordinary things: a pinned dependency, a custom patch nobody remembers, or an approval sitting with the wrong person. For a business website, those delays leave both security and delivery uncertain.
Drupal’s June 17 security bundle provides a useful test of your maintenance arrangements. Can your team identify the affected sites, resolve the update, check the settings, and show what reached production? Business owners and operations leads do not need to run Composer themselves. They do need clear answers from whoever maintains the site.
What the June security advisories tell us
Two advisories illustrate why updating dependencies is only part of the work. The critical PHP object injection advisory, SA-CORE-2026-005, required both JSON:API write permission and an entity reference field type storing a serialized property. No field type shipped with core met those conditions, and JSON:API was read-only by default.
Those conditions help assess exposure. Drupal still recommended an actual update within 24 hours of that release and warned that Drupal Steward protection might not cover every case. When reviewing the June work now, ask for the deployed version and configuration checks, alongside the maintenance ticket.
The oEmbed SSRF advisory, SA-CORE-2026-008, addressed URL discovery that could cause Drupal to request arbitrary URLs from the server. Sites using URL discovery also needed a trusted-host setting. These are examples from the bundle; the developer should review all relevant advisories and the target release notes.
Choose a supported target, not June’s minimum fix
As of 14 October 2026, the Drupal release schedule lists security release windows for 11.4.x, 11.3.x, and 10.6.x. Security support for 11.2.x and 10.5.x ended in the week of June 29. June’s fixed versions are historical minimums, not suitable targets for every site today.
Agree the latest appropriate stable release on a supported branch before changing dependencies. Drupal 10 reaches end of life on December 9, 2026. A Drupal 10 site therefore needs an upgrade plan now, with compatibility work, budget, and an owner. Keep the immediate security update and the major upgrade as distinct pieces of work where that helps delivery.
| What you find | Decision to make | Evidence before closing the work |
|---|---|---|
| Supported core branch | Agree the current update target. | Installed version, target release, and deployment date. |
| Unsupported branch or Drupal 10 | Assign the supported-version upgrade. | Compatibility blockers, owner, and funded delivery plan. |
| Composer cannot resolve dependencies | Identify and address the blocking constraint. | Dependency explanation and reviewed change. |
| Affected API or media settings | Review exposure and required configuration. | Settings review and focused tests. |
| Release ready for deployment | Approve the tested build and recovery approach. | Lock file, workflow results, backup, and production verification. |
Make the Composer change small enough to review
Work in a development branch, with staging that reflects production’s PHP, extensions, and database version. Inventory custom patches and contributed modules first. An undocumented patch can turn a routine update into an investigation.
For a project using drupal/core-recommended, the Drupal Composer update guide supports this sequence:
composer show drupal/core-recommended
composer update "drupal/core-*" --with-all-dependencies --dry-run
composer update "drupal/core-*" --with-all-dependenciesRead composer.json before running it. The update can cross minor versions where the constraints allow it. If the project requires only drupal/core, use the corresponding command in Drupal’s guide. A major upgrade needs its own compatibility process.
The dry run previews the changes. After the actual update, review the lock-file diff and confirm that custom patches still apply. Explain unexpected dependency changes before approving them.
When resolution fails, use composer prohibits drupal/core VERSION, replacing VERSION with the intended release. The Composer command reference documents this diagnostic and composer audit. Run the audit after updating and review its findings; a clean result does not verify permissions, configuration, or business workflows.
Check the configuration the fix depends on
For JSON:API, confirm whether writes are enabled, which roles can use them, and whether contributed or custom code changes that access. Record the findings so the next maintainer can understand the decision.
For oEmbed, establish whether the site uses the provider registry or URL discovery. The June SSRF advisory requires sites using URL discovery to configure approved discovery hosts in settings.php:
$settings['media_oembed_discovery_trusted_host_patterns'] = [
'^example\.com$',
];Replace the example with the actual approved discovery hostname patterns. Keep them narrow and test the media sources editors use. This setting is separate from Drupal’s general trusted-host configuration; adding it is not a reason to loosen either list.
Deploy the dependency set you tested
Commit the reviewed composer.json and composer.lock. Build the release using composer install --no-dev from that lock file, then deploy the tested artifact through your normal pipeline.
Run required database updates and rebuild caches. With project-local Drush available, the commands are vendor/bin/drush updatedb and vendor/bin/drush cache:rebuild. If Drush is a development dependency, --no-dev excludes it, so arrange the deployment tooling accordingly.
Test the journeys that matter to the business: login, editing, media, forms, search, and critical integrations. For a lead-generation site, confirm a submission reaches its destination. For a shop, test checkout where applicable. Verify the deployed core version and check production logs after release.
Agree recovery steps beforehand. Database changes may make a code rollback insufficient. Confirm that backups can be restored, who decides to roll back, and how submissions or orders received after the backup would be protected.
Give the next update a clear owner
Keep a short record of the target version, dependency decisions, configuration changes, test results, and deployment outcome. Agencies should retain this evidence per site, with unresolved exceptions assigned to someone. A useful maintenance process makes the next decision easier.
If updates keep getting stuck between developers, hosting, and business approval, talk to Greg about coordinating your Drupal maintenance. Bring your current version, Composer blockers, and maintenance arrangements. That gives us a concrete starting point for agreeing priorities, responsibilities, and the next release.
Related on GrN.dk
- One Webform Release, Twenty Advisories: Audit Every Drupal Site
- CMS Upgrades in 2026: Choosing the Right PHP Version for WordPress and Drupal
- Sending Mail with Drupal: A Reliable Setup for Business-Critical Email
Need help with this kind of work?
Discuss your Drupal update process with Greg Get in touch with Greg.