Critical security vulnerabilities don't wait for a convenient time. They arrive on their own schedule, and how quickly your team responds can mean the difference between a routine update and a serious exposure.

A highly critical advisory with a 48-hour window

On May 18, the Drupal Security Team issued PSA-2026-05-18, a pre-announcement for a highly critical security release affecting every supported branch of Drupal core. The advisory scored a 20 out of 25 on the security risk scale. No authentication required, no special access needed. The release window was two days later, on May 20, between 17:00 and 21:00 UTC.

The Drupal Security Team urged site owners to reserve time for immediate updates because exploits could be developed within hours or days. They took the unusual step of providing best-effort patch files even for end-of-life versions of Drupal 8 and 9 because the potential impact was that significant.

If you're running a site that processes orders and manages customer data, you can’t put something like this off until the next sprint.

Coordinating across every client

When the pre-announcement landed, we reached out to all of our support clients and worked directly with their teams to determine priority, assess whether the vulnerability applied to each site's specific configuration, and plan accordingly.

That communication happened in real-time through Slack. Our clients aren't going through a ticketing system. They interface directly with the team that knows their codebase, their deployment process, and their hosting environment.

Over the next 48 hours, we created an internal tracker and assigned primary and secondary developer responsibilities for each client site. Secondary assignments provided genuine redundancy. If a deploy got held up on one site, the backup developer could step in immediately, so no client was left waiting.

Every site is different. That’s the point.

Our clients run Drupal across a range of hosting environments (Acquia, Pantheon, Upsun, self-hosted infrastructure), and many are on different versions of Drupal core. A few are still running Drupal 8 or 9.

That diversity requires an individualized response. We knew Acquia and Pantheon would have platform-level protections in place quickly, so we prioritized non-platform-hosted sites first. For sites still on Drupal 8 or 9, we evaluated and applied the best-effort patch files directly.

We also worked with each client's stakeholders to establish interim protections. For self-hosted sites where the vulnerability was particularly concerning, we had processes ready to take sites offline temporarily if the severity of the exploit demanded it. None of our clients were running the specific configurations most at risk, so we didn't need to go that far. 

But we were ready.

Patched and tested, day of

Every impacted client was updated the day the security release dropped.

After applying patches, we coordinated user acceptance testing with each client through those same direct communication channels before pushing to production. Status updates flowed in real time through Slack, and we shared findings across the team as they came up, keeping work visible where work was happening.

Each client has a documented standard operating procedure, and the specifics vary. Some clients handle their own deploys. Others rely on us for the full process. Some have additional steps related to staging environments or stakeholder sign-off. The tracker captured all of this, including notes about anything out of the ordinary, so the team could move quickly without dropping details.

What this means for platform and partner selection

This kind of coordinated response highlights something enterprise IT leaders should consider when evaluating eCommerce platforms and the support structures around them.

Drupal's architecture handled this well. Even with sites spread across different hosting providers, different core versions, and different levels of customization, the security update process was consistent. A site on Acquia running Drupal 11 and a self-hosted site still on Drupal 9 both had clear paths to remediation.

But the platform is only part of the equation. Having a support team that already knows your deployment process, already has direct communication channels in place, and already has documented procedures for your specific site means the difference between a stressed-out 48-hour scramble and a planned, stable, 48-hour execution.

The security advisory also reinforced something we see regularly with Drupal: the open-source security model works. Everything, from the coordinated disclosure to the cross-version patch files, was handled transparently by a volunteer security team supported by organizations across the community.