Critical Drupal Core Flaw Lets Anyone Hijack PostgreSQL Sites

blog/Articles/Critical Drupal Core Flaw Lets Anyone Hijack PostgreSQL Sites — CISA Sets May 27 Deadline

News

kkm

Backend Engineer / AWS / Django

2026.05.237 min0 views

Share X Hatena LINE LinkedIn RSS

Key takeaways

The U.S. CISA gave federal agencies just five days to patch CVE-2026-9082, a highly critical SQL injection in Drupal core that lets anonymous attackers take over PostgreSQL-backed sites. Imperva already counts 15,000 attack attempts against 6,000 sites across 65 countries, including Drupal-powered government and university portals in Japan.

CISA Sets a Five-Day Deadline to Patch CVE-2026-9082

On May 22, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-9082 in the content management system Drupal to its Known Exploited Vulnerabilities (KEV) catalog and ordered federal agencies to patch by May 27. That is two days from public disclosure to KEV listing, and only five days left on the clock. The last time CISA shortened a deadline this aggressively was for F5 BIG-IP CVE-2025-53521.

At the center of the story is an SQL injection in Drupal's database abstraction layer — the component that sits between the site and the database and is meant to keep queries safe. SQL injection is the classic attack where a crafted string in a form field or URL parameter coaxes the database into doing something the developer never intended. CMS engineers have been treating it as a long-solved problem. Yet here it is, fully reachable by anonymous traffic against Drupal 8.9 through 11.3 via either the login page or the API. Drupal's own SA-CORE-2026-004 advisory rates it 20/25 on the Drupal risk scale — Highly Critical.

The narrowing factor is the database backend. Only sites running on PostgreSQL are exposed; the more common MySQL, MariaDB and SQLite paths are unaffected. That sounds reassuring until you notice which Drupal users tend to pick PostgreSQL: government portals, universities and large media organisations — exactly the operators who picked Drupal because of its security pedigree in the first place. In Japan, Drupal is the platform underneath the Digital Agency's unified government website initiative, so the blast radius is more than a niche concern.

What follows is what happened in the few days between disclosure and KEV listing, what the actual bug looks like, how to check whether your own Drupal site has already been probed, and what to do if you cannot patch right away — written for the web admins and infrastructure engineers who carry the pager for CMS deployments.

CVE-2026-9082 at a glance

Severity	CVSS 9.8 / 10.0 (Critical) Drupal vendor rating: 20/25 "Highly Critical"
Class	SQL injection (CWE-89) → info disclosure, tampering, privilege escalation, RCE
Preconditions	No authentication, no user interaction, network reachable
Affected stack	Drupal 8.9 — 11.3.10 only when running on PostgreSQL
Patched versions	10.4.10 / 10.5.10 / 10.6.9 / 11.1.10 / 11.2.12 / 11.3.10
KEV listing	Added on May 22, 2026
CISA deadline	May 27, 2026 (federal agencies, 7 days from disclosure)
Attack volume (as of May 22)	15,000+ attempts against ~6,000 sites across 65 countries

From the Pre-Announcement to the KEV Listing

What was unusual about this release is that the Drupal Security Team issued a public service announcement (PSA-2026-05-18) two days before the patch dropped, telling administrators that a "highly critical" core release was coming on May 20 and that every supported branch of Drupal 10 and 11 would be affected. They withheld details but explicitly asked teams to clear a maintenance window for the coming Friday — language that signals real urgency.

As promised, on May 20 the team shipped SA-CORE-2026-004 together with patched releases for Drupal 10.4.10 / 10.5.10 / 10.6.9 / 11.1.10 / 11.2.12 / 11.3.10, plus exceptional patches for the end-of-life 8.9 and 9.5 branches. Drupal had not given a vulnerability 20/25 on its own risk scale in years. The patch diff was visible on GitHub from minute one, and as soon as it was public the clock on "anyone can derive the exploit from the fix" started ticking.

Sure enough, on May 21 Searchlight Cyber published a full technical writeup with two working proofs of concept. They identified two anonymous paths: a time-based blind injection through POST /user/login?_format=json, and an error-based oracle through GET /jsonapi/node/article?filter[...]. The second variant only needs a single GET request to confirm vulnerability — perfect ammunition for indiscriminate mass scanning.

From there CISA moved fast. On May 22 it added CVE-2026-9082 to the KEV catalog — the list reserved for vulnerabilities already being exploited in the wild — and gave federal agencies until May 27 to remediate. CISA usually allows two to three weeks. Seven days from disclosure is reserved for cases where attackers are clearly moving fast, alongside outliers like Ivanti's CVE-2024-22024 and F5's CVE-2025-53521.

Nine Days, Pre-Announcement to Deadline

Lay the timeline out and the entire story — pre-announcement to 15,000 attack attempts to a CISA deadline — fits inside nine days.

← swipe to navigate

Why Only PostgreSQL Is Affected

Drupal supports MySQL, MariaDB, PostgreSQL and SQLite behind a single database abstraction layer, with database-specific overrides plugged in to smooth over dialect differences. The bug lives in one of those PostgreSQL-specific overrides. To make Drupal's IN operator (the SQL clause that asks "does this value match any item in this list?") behave in a case-insensitive way on PostgreSQL, the override wraps the supplied array values in LOWER() and rebuilds the placeholder names by hand.

The mistake is that those placeholder names are built from the array keys, not the values. Drupal's design assumes keys will always be the integers 0, 1, 2… that PHP hands you for a plain list. JSON input has no such constraint — an attacker can decide what the keys are. As Searchlight Cyber's writeup shows, a request like the one below smuggles a key string straight into the SQL the database eventually runs:

POST /user/login?_format=json
Content-Type: application/json

{
  "name": {
    "0": "drupal",
    "0||1/(SELECT CASE WHEN (SELECT name FROM users_field_data WHERE uid = 1) LIKE 'drupal' THEN 0 END)": "drupal"
  },
  "pass": "drupal"
}

The injected sub-SELECT turns the condition into a divide-by-zero whenever it evaluates true on PostgreSQL — and the response code flips accordingly: HTTP 500 if true, HTTP 400 if false. Step through bits one at a time and an unauthenticated attacker can leak admin usernames, password hashes, unpublished nodes and API keys. Horizon3.ai reaches the same conclusion through the second variant via JSON:API filters — both paths deliver complete unauthenticated database access.

The patch itself is three lines: pass the array through array_values() so the keys are reset to integers. It is a textbook example of a long-known PHP footgun — the fact that arrays can have arbitrary string keys — hiding in plain sight inside a database-specific override for eight-plus years. The MySQL code path never needed LOWER() and never re-used the keys, so the dialect difference itself was acting as the seawall.

15,000 Attempts Across 65 Countries

The "real-world exploitation" CISA cited when adding the CVE to KEV is already visible in vendor telemetry. Imperva's observation report records more than 15,000 attempts targeting CVE-2026-9082 across the infrastructure it protects, hitting roughly 6,000 sites in 65 countries. By industry, gaming and financial services together account for about half of all observed attacks.

For now the dominant traffic shape is reconnaissance rather than exploitation. The most common probes are GET requests to /jsonapi/node/article with filter[t][condition][operator]=IN, array-key injection strings like "0), 0)) OR 1=1 --", time-based oracles using PostgreSQL functions, and UNION-style syntax probes. In other words: attackers are still building the target list. If your site is hit while you're not watching, you join that list.

Worth flagging: Imperva's numbers only count what its own WAF sees. Sites without a managed WAF are getting scanned through separate paths, so the actual attempt count is materially higher than the public figures. The Hacker News also reports broad scanning activity beginning within 24 hours of the PoC drop.

How to Check Whether You're Exposed

First decide whether you're even in scope: is the database PostgreSQL? From the Drupal admin UI, go to Reports → Status report and look at the Database row. If it says PostgreSQL, you are affected. If it says MySQL, MariaDB or SQLite, you are not. On a server with shell access, drush status exposes the same field under "Database driver."

If you're on PostgreSQL, next check the core version. drush status --field=drupal-version or the Drupal Version row on the status report tells you. Anything below 10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12 or 11.3.10 needs to move. End-of-life 8.9 and 9.5 sites are also covered by exceptional patches linked from SA-CORE-2026-004.

For compromise indicators, search webserver access logs for requests to /user/login?_format=json and /jsonapi/node/. A spike of GETs containing filter[ and either operator=IN or condition almost certainly means you're being probed for CVE-2026-9082. Source IPs hammering the endpoint in short bursts are candidates for immediate blocklisting.

On the database side, watch for unusual reads against users_field_data and key_value, and for repeated SQLSTATE[HY093] entries (invalid parameter number) in the PostgreSQL log. If the attacker has succeeded, expect new user rows, unexpected administrator role assignments, and odd INSERTs into user__roles. Pull the recent change history directly rather than trusting dashboards.

Patch — and the Short-Term Workarounds

The only real remediation is the patch. Follow SA-CORE-2026-004 and upgrade to your branch's fixed release (10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12 or 11.3.10). For Composer-managed sites that's composer update drupal/core --with-all-dependencies followed by drush updatedb -y — a one or two minute job. If you run a single production instance without staging, back up both the database and the codebase before you touch anything.

If patching has to wait, there are three temporary tourniquets worth considering. First, disable the JSON:API module if you don't actively use it — that closes the most-scanned path. Second, disable the REST login resource (/user/login?_format=json) if no client depends on JSON-based login. Third, add a WAF rule that rejects requests to either path when the JSON body or filter[ parameters contain non-numeric keys — that blocks the bulk of the active traffic.

All three are bandages. Tenable's writeup warns that other input paths — for example contact forms — may reach the same underlying bug, so "I closed the API, I'm fine" is not a safe conclusion. WAF rules are routinely bypassed with re-encoding tricks as soon as they become public. Book a real patching window during business hours next week regardless.

Drupal in Japan: Government, Universities, Large Publishers

Drupal in Japan tilts towards large organisations. The flagship deployment is the Digital Agency's unified government website programme, which consolidates ministry sites on a shared Drupal-based platform. A Digital Agency interview published by Nara City attributes the choice to Drupal's balance of accessibility, multilingual support and security review.

In academia, OIST (the Okinawa Institute of Science and Technology) is a notable Drupal site, and vendor case lists show consistent uptake among research institutions with strong international ties. Outside Japan, Drupal is used by the U.S. White House, the Commonwealth of Massachusetts, and roughly a quarter of Canadian government agency sites — the "security-conscious org" segment that explains why PostgreSQL-on-Drupal is a meaningful slice of Drupal even though PostgreSQL is the minority backend.

As of May 23, no Japanese-language writeups have appeared on Hatena Bookmark, Zenn or Qiita, and neither JPCERT/CC nor IPA has issued a Japanese advisory yet. Site owners have to go straight to the primary sources (Drupal.org and the CISA KEV catalog). The worst failure mode here is the assumption that "English-only coverage" or "minority database backend" means the risk doesn't apply — that's exactly the population that ends up exploited after the CISA deadline.

What the CISA Deadline Actually Means, and What to Watch Next Week

Formally, the CISA KEV deadline binds only U.S. federal agencies. In practice it matters far beyond them. Cyber insurance underwriters reference KEV deadlines when assessing claims; security questionnaires from U.S. and EU partners ask whether KEV items were patched in time; post-incident reviews treat "we missed the KEV deadline on a Highly Critical CVE" as an aggravating factor. May 27 is the line where, if you're still exposed afterwards, you've moved from "victim" to "ignored a flashing red warning."

For next week, three signals are worth watching. First, follow-up reports from large CDN and WAF providers — Imperva, Cloudflare and Akamai — to see how the attack shape evolves from reconnaissance into actual exfiltration. Second, whether Japan's JPCERT/CC or IPA issues a Japanese advisory; right now operators are translating English sources themselves. Third, whether researchers find another reachable code path on end-of-life Drupal 7. The vendor statement says Drupal 7's PostgreSQL handling is structured differently, but attackers do not stop at vendor statements.

To recap: this is "Drupal 8.9 or newer, running PostgreSQL." If that describes you, patch before May 27 or layer in one of the workarounds above. If it doesn't, the takeaway is more general — do you know, from a single Drupal status report screen, which CVEs are currently being weaponised against the CMS you operate? Now is a fine time to set that up.