Drupal’s June security bundle exposes fragile Composer update habits

By Greg Nowak. Updated 11 September 2026.

Drupal’s June 17 security releases raised a practical question for anyone responsible for a business website: how quickly can your team ship a security update and prove the site still works? The difficult part is often an old dependency constraint, an undocumented patch, or uncertainty over who can approve deployment.

The June bundle remains a useful test of your maintenance process. For business owners, operations leads, and agencies, the goal is straightforward: know what needs updating, give someone responsibility for delivery, and check the workflows that keep the business running.

What the June advisories actually required

The critical PHP object injection advisory, SA-CORE-2026-005, had specific exploit conditions. An attacker needed permission to write through JSON:API, and the site needed an entity reference field type storing a serialized property. Drupal core shipped no field type meeting those criteria, and JSON:API was read-only by default.

That helps teams assess exposure. It does not justify leaving core unpatched. Drupal recommended an update within 24 hours of the June release and warned that its Drupal Steward protection might not cover every case. If you are reviewing this now, establish what was actually deployed; a closed maintenance ticket alone is insufficient evidence.

The separate oEmbed SSRF advisory, SA-CORE-2026-008, addressed URL discovery that could make Drupal request arbitrary URLs from the server. Sites using that discovery mechanism also needed a configuration change. This is why a successful Composer command cannot be the only completion check.

Choose a supported target before running Composer

June’s fixed versions are historical minimums, not September update targets. As of 11 September 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, when 11.4.0 was released.

Select the latest appropriate stable release on a supported branch. Drupal 10 reaches end of life on December 9, 2026, so a Drupal 10 maintenance plan also needs a funded upgrade path. An emergency patch and a major upgrade can have different delivery plans, but both need an owner.

Make the Composer update reviewable

Start in a development branch with staging that reflects production’s PHP, extensions, and database version. Record custom patches and contributed modules before changing dependencies.

For projects using drupal/core-recommended, Drupal’s Composer update guide provides this pattern. Run the preview first, then the update once the proposed scope makes sense:

composer show drupal/core-recommended
composer update "drupal/core-*" --with-all-dependencies --dry-run
composer update "drupal/core-*" --with-all-dependencies

Check the constraints in composer.json first: this command can cross minor versions where allowed. Projects requiring only drupal/core need the corresponding command from Drupal’s guide. Avoid copying a command for a different project structure.

The dry run previews changes; the actual update creates the lock-file changes to review. Check core packages, changed dependencies, and whether custom patches still apply. Give unexpected changes an explanation before approval.

Use composer prohibits drupal/core VERSION, replacing VERSION with the intended release, to investigate blockers. Run composer audit after updating to check reported package advisories. The Composer command reference documents both. A clean audit is useful evidence, but it does not test site configuration or business workflows.

Check the settings the patch depends on

For JSON:API, confirm whether writes are enabled and which roles or integrations require them. Include contributed and custom code in that review.

For oEmbed, establish whether the site uses the provider registry or URL discovery. If it uses URL discovery, the June advisory requires trusted 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 the list narrow and test the media sources editors use. This setting is separate from Drupal’s general trusted-host configuration.

Deploy the tested dependency set

Commit the reviewed composer.json and composer.lock. Build the release with composer install --no-dev from that lock file, then deploy the tested artifact through your normal pipeline. The lock file records the exact dependency versions; maintaining it is essential to repeatable delivery.

Run required database updates and rebuild caches using your deployment procedure; with project-local Drush, the commands are vendor/bin/drush updatedb and vendor/bin/drush cache:rebuild. Check login, editing, media, forms, search, and critical integrations. Test checkout or lead delivery where applicable.

Agree recovery steps before release. A code rollback may be insufficient after database changes. Confirm backups can be restored, who makes the rollback decision, and how new submissions or orders would be protected during recovery.

Give the next update a clear owner

A useful runbook records the target version, dependency decisions, configuration changes, test results, deployment owner, and recovery steps. For an agency managing several sites, keep that evidence per site so exceptions remain visible.

If your team needs help resolving Composer blockers or coordinating developers, hosting, and business approval, talk to Greg about your Drupal update process. Bring your current version, maintenance arrangements, and known blockers; those are a practical starting point for agreeing the work.

Related on GrN.dk

• CMS Upgrades in 2026: Choosing PHP for WordPress and Drupal
• Sending Mail with Drupal: A Reliable Setup for Business-Critical Email
• Agentic AI: What It Is, How It Works, and When to Use It

Need help with this kind of work?

Discuss your Drupal update process with Greg Get in touch with Greg.

Sources

• Drupal core: PHP object injection — SA-CORE-2026-005
• Drupal core: Server-side request forgery — SA-CORE-2026-008
• Drupal core release schedule
• Updating Drupal core via Composer
• Composer command-line reference