Drupal's June security bundle exposes fragile Composer update habits

By Greg Nowak. Last updated 2026-06-22.

Drupal's June 17, 2026 core security releases are a useful stress test for site operations. The release notes for Drupal 11.4.0-rc2 bundle five core security fixes, including a critical PHP object injection advisory, a server-side request forgery advisory, and an upstream dependency security update for guzzlehttp/psr7. For a site owner, the message is not simply: update Drupal. It is: can your team update Drupal quickly without guessing?

That is where Composer habits matter. Drupal's release page gives Composer commands for updating core and dependencies, including updating drupal/core-* with all dependencies. It also warns that pinning to a specific release can make future updates more difficult. In calm weeks, those details feel procedural. Under a security deadline, they expose old constraints, unreviewed patches, abandoned modules, PHP platform mismatches, and lock files nobody has touched outside production pressure.

The critical advisory, SA-CORE-2026-005, deserves a measured response. Its exploit conditions are narrow, but the rating is serious. It concerns PHP object injection tied to JSON:API write access and fields that store serialized properties. Drupal core says JSON:API is read-only by default, and that no field type shipped with core meets the advisory's criteria. That reduces panic. It does not remove the need to act. The same advisory recommends updating Drupal within 24 hours and notes that WAF mitigation may not cover every case or hosting setup.

Commercial Drupal sites need a triage-and-update workflow, not a scramble. Start with the active Drupal branch and whether it is still covered. The advisory lists supported update targets for Drupal 10.5, 10.6, 11.2, and 11.3. It also describes Drupal 11.1, 11.0, 10.4, and below as end-of-life for security coverage. The release schedule adds another deadline: the week of June 22, 2026 brings Drupal 11.4.0 and the end of security support for 11.2.x and 10.5.x. Staying one minor behind can feel cautious, but on Drupal it can quickly become a support-window problem.

The SSRF advisory, SA-CORE-2026-008, is a good example of why the bundle has to be read carefully. It concerns Drupal's Media module and oEmbed. The advisory explains that oEmbed supports discovery through providers.json and through URL discovery, and that the URL discovery code could be used to trick Drupal into making server-side requests to any URL. The fix is partly code and partly configuration. If a site uses URL discovery, it now needs trusted oEmbed discovery host patterns in settings.php. Drupal notes that most sites likely use providers.json, but likely is not the same as checked.

A casual maintenance process runs Composer, clears caches, and waits to see what breaks. A better process asks the awkward questions early. Which environments use Media oEmbed? Are any custom modules enabling JSON:API writes? Do contributed or custom field types store serialized properties? Is the Composer constraint broad enough to receive the intended security release? Did the update bring in the guzzlehttp/psr7 version Drupal expected? Can the deployment be reproduced from a clean checkout?

The dependency point is easy to underestimate. Drupal's release notes explicitly mention upstream security releases and name guzzlehttp/psr7 2.11.0. The Guzzle PSR-7 security page has its own security policy and advisory history. So Drupal patching is also PHP supply-chain work. A frozen lock file can leave a site nominally updated but not aligned with the dependency state Drupal intended. An uncontrolled composer update, meanwhile, can move more packages than expected. The useful middle ground is a staged update with a reviewed lock-file diff.

Release timing is another reason to prepare before the next advisory. Drupal's schedule says security release windows usually fall on the third Wednesday of the month, although not every window includes a core security release and rare releases can happen outside the preset windows. That is predictable enough to plan readiness, but not predictable enough to design the process on the day. A site owner should already know who approves emergency deployment, who checks the lock file, who validates backups, who tests editorial workflows, and how fast a patch can move from staging to production.

A practical Drupal emergency update runbook should be short and usable under pressure. Capture the Drupal core version, PHP version, database version, installed contributed modules, enabled Media and JSON:API configuration, and Composer constraints. Create a staging branch and use the Drupal-recommended Composer update pattern. Review the lock-file changes, especially Drupal core packages and named upstream security packages. Apply required configuration changes, including oEmbed trusted host patterns where URL discovery is in use. Test login, content editing, media embeds, JSON:API endpoints, search, forms, caches, and business-critical integrations. Then deploy with a rollback path that has already been checked.

For GrN.dk clients, this is a sensible moment to treat patching as an operations maturity check. Greg can help inventory core and contributed versions, stage the update, resolve Composer conflicts, review JSON:API write exposure, adjust oEmbed trusted-host settings, validate backups, and document a repeatable runbook for the next security window. The value is not drama. It is knowing what happens when the next advisory lands.

Related on GrN.dk

• ChatGPT Visibility Without Open Access Takes More Than robots.txt
• Drupal CMS 2.0 and Drupal Canvas turn marketing-site rebuilds into real implementation work
• MariaDB 10.6's July 2026 end-of-life makes quiet CMS hosting debt a paid database upgrade project

Need help with this kind of work?

Plan a Drupal security update runbook Get in touch with Greg.

Sources

• Drupal 11.4.0-rc2 release notes
• SA-CORE-2026-005 PHP object injection
• SA-CORE-2026-008 SSRF advisory
• Drupal core release schedule
• Guzzle PSR-7 security page