Drupal Just Patched a Bug That Lets Any Anonymous Visitor Run Arbitrary SQL Against the Million Sites Running on PostgreSQL—No Authentication, No Login, No Plug In Required

What Happened

On May 21, 2026, the Drupal security team released a coordinated emergency advisory covering every supported branch of Drupal core. The bug, tracked as CVE-2026-9082, is a SQL injection flaw in Drupal Core's own database abstraction API—the layer that is supposed to make SQL injection mathematically difficult by parameterizing every query.

On PostgreSQL backends, the sanitization breaks. An unauthenticated attacker can send a specially crafted HTTP request—no login, no token, no special role—and execute arbitrary SQL on the database. From "arbitrary SQL" the path to remote code execution is short: dump credentials, write a backdoor file via COPY ... TO PROGRAM, escalate to a shell.

Drupal's security team warned that "exploits might be developed within hours or days." The advisory urged operators to schedule maintenance windows for the release window, 5–9 PM UTC on May 20, and patch before the next attack window opened.

Why PostgreSQL Specifically

Drupal supports three database engines: MySQL, MariaDB, and PostgreSQL. The same query goes through different driver code for each. The bug lives in the PostgreSQL driver path—the way Drupal's abstraction layer escapes certain identifier characters when speaking to Postgres differs from the way it escapes them for MySQL or MariaDB. Under specific patterns of input, the Postgres path lets a payload escape its escaped context and reach the query planner as raw SQL.

Drupal 7 is unaffected—it predates the modern abstraction layer. Everything from 8.0 forward on Postgres is vulnerable until patched. Two of the affected branches are technically end-of-life (10.5 and below) but Drupal published manual patches for them anyway, an unusual move that signals how severely the team views the bug.

Patched Versions

• Drupal 11.3 → upgrade to 11.3.10
• Drupal 11.2 → upgrade to 11.2.12
• Drupal 11.1 → upgrade to 11.1.10
• Drupal 10.6 → upgrade to 10.6.9
• Drupal 10.5 → upgrade to 10.5.10
• Drupal 10.4 → upgrade to 10.4.10
• End-of-life 9.5 and 8.9 → manual patch files published

If your site is on a branch older than 10.4, Drupal's recommendation is unambiguous: upgrade to a supported version. The manual patch exists as a courtesy, not as ongoing support.

Who Runs Drupal on PostgreSQL—and How Many Sites Are Exposed

Drupal powers an estimated one to two percent of all CMS-driven sites globally, which translates to several hundred thousand active installs. Government and higher education make up a heavily disproportionate share. The U.S. federal government's USA.gov, the Australian Government Digital Transformation Agency, the European Commission's portals, NASA's nasa.gov, and dozens of state and university portals all run Drupal.

PostgreSQL is the default database choice in government and higher-ed Drupal deployments. The compliance argument is straightforward—PostgreSQL has stronger row-level security primitives and a longer FedRAMP history. The result is that the population of Drupal sites most exposed to CVE-2026-9082 is also the population running the most regulated data.

The Attack Window

Drupal advisories follow a published cadence: patches drop at a specific UTC window, security mailing lists notify maintainers in advance, and the public advisory text goes live alongside the patch. For high-severity issues, that means the world learns the bug exists the moment the fix ships. Skilled exploit developers regularly publish proof of concept within hours of an advisory like this one. Mass scanning typically follows within a day.

The mitigations Drupal recommends are blunt. Take the site offline if necessary. Apply the patch. Restore. If you cannot patch immediately, deploy a web application firewall rule that blocks the specific request patterns the advisory describes—Cloudflare, AWS WAF, and Akamai have all already pushed managed rules. None of those rules are a substitute for the patch.

From SQL Injection to RCE: The Short Path

SQL injection is often discussed as if it stops at data theft. On PostgreSQL it does not. A user with the pg_execute_server_program role—and the Drupal database user historically has elevated rights for the same reason every CMS does, schema migrations—can use COPY (SELECT ...) TO PROGRAM 'sh -c "$payload"' to execute arbitrary commands as the Postgres process user. From there, anyone who shares disk with that user is one privilege-escalation primitive away from root.

In the worst case, the attacker dumps the Drupal users table—every administrator, every editor, every password hash. They write a backdoor PHP file into the webroot. They log into your administrator account at leisure. They do this in roughly six seconds of automated work. The only thing slowing them down is the time to find your Drupal install. With Shodan and similar services indexing Drupal sites by fingerprint, that time is measured in minutes.

What to Do Right Now

• Identify your database backend. drush sql:conf or vendor/bin/drush sql-connect shows it. If the connection string starts with pgsql:, you are exposed.
• Apply the patch matching your branch. Composer-managed sites: composer update drupal/core --with-dependencies after pinning the patch version. Tarball installs: download the new branch tarball and apply it over the existing webroot.
• Audit access logs from the past 72 hours. Look for POSTs to forms with abnormally long query parameters, or GETs containing %27, %22, or UNION SELECT patterns.
• Rotate the Drupal database password. If exploitation occurred, the attacker has it.
• Reduce the Drupal database user's privileges. Revoke pg_execute_server_program. Restrict to a non-superuser role that owns only the Drupal schema.
• Check for backdoors. Compare your webroot against a known-good copy from the same Drupal release. Any unexpected PHP file is suspicious.

The Bigger Pattern

Modern frameworks promise SQL injection is solved. The promise rests on the framework's own abstraction layer being correct everywhere, on every supported driver, for every input pattern. CVE-2026-9082 is a reminder that "almost correct" abstractions are how injection bugs end up in software written by people who would never write raw SQL themselves. The 2014 Drupalgeddon (CVE-2014-3704) sat at the same layer and produced the same outcome: an internet-scale mass-exploitation event before most sites finished patching.

The cadence here is roughly a critical Drupal core bug every 18 to 24 months. Operators who pre-stage patching procedures get hit by these advisories; operators who do not get hit and breached by them.

Why This Matters Beyond Drupal

Many Drupal sites store user email addresses, account passwords, and—on government and education sites—identity verification data. A successful exploitation against any of the major Drupal-backed government portals would hand attackers a list of citizen email accounts and partial identity records, which feed phishing and account-takeover operations for years afterward. Mass extraction of email addresses from Drupal sites is exactly how lists like the 6.8 billion email dump on BreachForums get built.

Patch fast. The clock started at the moment the advisory text became searchable.