Last Wednesday, May 20, Drupal's security team dropped SA-CORE-2026-004 — a highly critical advisory covering an anonymous SQL injection vulnerability in Drupal core. The Drupal Association had telegraphed the release two days earlier via a public service announcement, which gave hosting providers and larger agencies a narrow window to prepare. If you haven't patched yet, this is the one you stop everything for.
What shipped
SA-CORE-2026-004 addresses an unauthenticated SQL injection flaw in Drupal core. The key word there is unauthenticated — an attacker does not need a login, a role, or any kind of session to attempt exploitation. The vulnerability is specific to sites running PostgreSQL as the database backend, not MySQL or MariaDB.
The Drupal security team rated this highly critical, which is their top severity tier. That classification is not used lightly; in recent years it's been reserved for vulnerabilities with realistic remote exploitation paths and meaningful blast radius. An anonymous SQL injection that can be hit without credentials absolutely qualifies.
Patched releases were published simultaneously with the advisory. Affected versions span the actively supported Drupal 10 and 11 release lines. The fix was backported accordingly, so there's no forced major-version jump to get protected.
The two-day advance advisory (PSA-2026-05-18) named the release date but intentionally withheld technical details — standard practice designed to let responsible parties patch before the exploitation window opens. That window is now open. Public advisories of this severity typically see active scanning within 24–72 hours of publication, and SQL injection tooling means exploitation doesn't require sophisticated attackers.
It's worth noting that PostgreSQL is more common in enterprise and government Drupal deployments than in typical agency-managed marketing sites. If your Drupal stack runs MySQL or MariaDB, SA-CORE-2026-004 does not apply — but it's still worth confirming your database backend explicitly rather than assuming.
Our take
This advisory is a good reminder of something we tell clients regularly: security patching is not optional maintenance, it's infrastructure hygiene. Highly critical Drupal advisories are rare — the security team is conservative with that label — and when one lands, the response window is measured in hours, not sprint cycles.
A few things stand out to us about this particular advisory.
PostgreSQL deployments skew toward exactly the clients who should care most. Government agencies, universities, large nonprofits, and enterprise clients are disproportionately likely to run PostgreSQL — often for compliance reasons or because their infrastructure team standardized on it organization-wide. These are also the clients with the most to lose from a breach: sensitive constituent data, regulated information, high-profile public presence. If you manage Drupal sites in those sectors, you should have already patched. If you haven't, today is the day.
The advance advisory system works — if you're paying attention. Drupal's two-day pre-notice gave hosting platforms and proactive agencies time to stage the patch before attackers could reverse-engineer the fix. We've built a process around monitoring drupal.org/security and the Drupal security PSA feed precisely because of moments like this. If you're not subscribed to Drupal security advisories — either directly or through your hosting provider's notification system — that's the first thing to fix after you've patched.
"PostgreSQL only" doesn't mean ignore it. We've already had a client ask whether they need to act since they're on MySQL. The honest answer is: confirm your database engine, patch anyway (the update includes other fixes), and use this moment to audit whether your patching cadence would have caught this in time if you were on PostgreSQL. A security incident is a bad time to discover your update process has a four-week lag.
Managed hosting platforms moved fast. Kinsta, Pantheon, and Acquia all had communications out to customers within hours of the advisory — some with one-click update prompts. This is exactly the value proposition of managed Drupal hosting, and it's a concrete data point worth sharing with clients who push back on managed hosting costs.
One honest trade-off to name: aggressive patching on production without staging validation carries its own risk. We've seen rushed security updates break custom modules, particularly ones that extend the database abstraction layer. Our standard practice is to apply the patch to a staging clone first, run a 20-minute smoke test, and then promote — the total elapsed time from advisory to production patch is still well under four hours. That's the right balance between speed and safety.
What to do right now
- Confirm your Drupal sites' database backends. MySQL/MariaDB installs are not affected, but verify — don't assume.
- Apply the patch immediately on PostgreSQL-backed sites. No staging delay is appropriate for an unauthenticated, highly critical advisory once public exploitation is possible.
- For all Drupal sites: update to the patched release regardless of database engine — it's good practice and gets you other fixes in the same package.
- Check your security notification subscriptions. Drupal security advisories are available via drupal.org/security and RSS. Your hosting provider should also be sending these; if they're not, that's a support conversation worth having.
- Review your patching SLA with clients. If your managed services agreement doesn't define a maximum response window for highly critical advisories, add one — something like "highly critical patches applied within 24 hours of confirmed compatibility."
Originally referenced: Drupal core - Highly critical - SQL injection - SA-CORE-2026-004 on Drupal.org.
If you're managing Drupal sites and want a second set of eyes on your patching process, security posture, or whether your database configuration creates exposure — get in touch. This is exactly the kind of thing we help clients think through before it becomes an incident.
Originally published by Drupal.org. Read the full announcement here.
