Drupal issued an emergency core security patch on May 20, 2026, resolving a SQL injection vulnerability that carries a severity rating of 20 out of 25 — the highest the Drupal Security Team has assigned to a core issue in years. The flaw, tracked as CVE-2026-9082 and formally published as SA-CORE-2026-004, affects all Drupal installations running on PostgreSQL databases and requires no authentication to exploit.

With hundreds of thousands of government agencies, universities, and large enterprises running Drupal on PostgreSQL — and with the Drupal Security Team explicitly warning that exploits could emerge within hours of patch publication — the patch window here is measured in hours, not days.

The Vulnerability

CVE-2026-9082 is a SQL injection flaw in Drupal’s database abstraction API — the layer that mediates all database queries for Drupal core and contributed modules. The flaw allows an unauthenticated attacker to send specially crafted HTTP requests that result in arbitrary SQL execution against the PostgreSQL database backing the site.

The severity parameters make this particularly dangerous:

  • Authentication required: None
  • Access complexity: None
  • Privileges required: None
  • User interaction: None

This is as close to a trivially exploitable critical vulnerability as exists. Any internet-facing Drupal site running PostgreSQL is potentially exploitable by an attacker with no prior access, no credentials, and no need to trick a user into taking any action.

The vulnerability is specific to the PostgreSQL driver within Drupal’s database abstraction layer and does not affect installations running MySQL, MariaDB, or SQLite. However, PostgreSQL is disproportionately common among large institutional Drupal deployments — government agencies, universities, and NGOs that prefer PostgreSQL’s licensing model, performance characteristics, and compliance posture over MySQL alternatives.

Affected Versions

The following version ranges are affected:

  • Drupal 8.9.0 through any version below 10.4.10
  • Drupal 10.5.0 through any version below 10.5.10
  • Drupal 10.6.0 through any version below 10.6.9
  • Drupal 11.0.0 through any version below 11.1.10
  • Drupal 11.2.0 through any version below 11.2.12
  • Drupal 11.3.0 through any version below 11.3.10

Drupal 7 is end of life and will not receive a patch. Sites still running Drupal 7 on PostgreSQL should treat this as a critical exposure with no vendor remediation path.

Why Drupal Gave Advance Warning

In an unusual move, Drupal published a public service announcement (PSA-2026-05-18) on May 18 — two days before the patch release — warning administrators to reserve time for emergency updates on May 20 between 17:00 and 21:00 UTC. The advance notice did not disclose the nature of the vulnerability, but the severity rating embedded in the PSA — 20/25 “highly critical” — was sufficient to signal the urgency.

The pre-announcement strategy is a calculated risk. It gives administrators time to prepare maintenance windows, coordinate deployments, and ensure they are not caught flat-footed by an emergency patch. The downside is that it signals to threat actors that something significant is coming, providing a window in which sophisticated attackers might attempt to discover or acquire the vulnerability details before the patch drops.

The Drupal Security Team has used pre-announcements for a handful of previous highly critical issues. Each time, the gamble has been that the operational benefit to the defender community outweighs the intelligence signal provided to attackers.

Who Is Most at Risk

Government websites are disproportionately represented in the high-risk pool. Drupal holds a significant share of the government CMS market globally, driven by its flexibility, accessibility compliance support, and open-source licensing. Many of these deployments run PostgreSQL. Sites that manage citizen services, permit applications, public records access, or sensitive departmental information and run Drupal on PostgreSQL should treat this as a P0 incident until patched.

Universities and research institutions are similarly exposed. Drupal is among the most widely deployed CMS platforms in higher education. University IT teams managing multiple Drupal instances across departments, research portals, and public-facing sites should audit which are PostgreSQL-backed immediately.

NGOs and public-interest organizations running Drupal on PostgreSQL complete the highest-risk profile. These organizations often have older deployments, limited IT staffing, and less mature vulnerability response processes — the combination that historically produces the longest patch lag.

How to Respond

Patch immediately. This is not a vulnerability where waiting for organizational change management cycles is appropriate. The combination of zero authentication required, zero access complexity, and a publicly disclosed patch window means functional exploit code is likely to appear within 24–48 hours of this writing.

Target versions by current installation:

  • Drupal 11.3.x → update to 11.3.10
  • Drupal 11.2.x → update to 11.2.12
  • Drupal 11.1.x / 11.0.x → update to 11.1.10
  • Drupal 10.6.x → update to 10.6.9
  • Drupal 10.5.x → update to 10.5.10
  • Drupal 10.4.x and below → update to 10.4.10

If immediate patching is not possible, temporary mitigations include: placing the site behind a WAF rule blocking unusual query string patterns associated with SQL injection, restricting PostgreSQL user permissions to the minimum required for Drupal operation (preventing the attacker from executing DROP, TRUNCATE, or system-level commands even if injection is achieved), and taking the site offline until the patch can be applied.

Drupal 7 sites have no vendor patch path. Migration to a supported version is the only durable solution; short-term mitigation requires WAF-level protection.

Sources