Drupal Core Flaw Lets Anyone Hijack PostgreSQL Sites Without a Login

Top/Articles/Drupal Core Flaw Lets Anyone Hijack PostgreSQL Sites Without a Login

NewsPublished May 23, 2026 Updated 4 days ago

Table of contents

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.

Only PostgreSQL Drupal Sites Are Affected, and the Fixed Releases Are Safe

The content management system Drupal — the engine behind a large share of government, university and media websites — has a critical SQL injection flaw, CVE-2026-9082, that lets an anonymous visitor read or tamper with the entire database just by hitting the login endpoint or the API. Only sites whose database is PostgreSQL are exposed. The fixed releases 10.4.10 / 10.5.10 / 10.6.9 / 11.1.10 / 11.2.12 / 11.3.10 and newer need no further action, and any older PostgreSQL-backed site should update now. Sites on MySQL, MariaDB or SQLite are unaffected regardless of version.

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.

This vulnerability is on the U.S. Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog — the list of flaws already being used in real attacks — and mass exploitation began within hours of disclosure. As of July 23, 2026, roughly two months on, it is still on that list, so treat it as actively targeted. What follows: which configurations are affected and how to confirm your version, what the actual bug does, how to check whether your own Drupal site has already been probed, the permanent fix and the stop-gaps, and the additional Drupal core releases that have shipped since this flaw went public — 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 to 11.3.x, below the patched releases, 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 (early, May)	15,000+ attempts against ~6,000 sites across 65 countries

The people lined up behind an unpatched Drupal government site

When CISA shortens a federal deadline to five days, the figures on the other side of the wire are not anonymous masks — they are crews who specifically hunt the Drupal-plus-PostgreSQL combination and sit on the database for months. The names listed in the database they are about to extract belong to citizens, students, and readers.

The people going after SQL injection in Drupal sites are not bored kids looking for a kick. The visceral motivations belong to state-aligned intelligence services hunting government memos and policy decisions, industrial spies after university research and clinical trial data, politically driven hacktivists who want to replace an official announcement with their own message, and data brokers who buy and resell entire citizen databases on underground markets. What they really want is the address-and-phone-number trail left in government portal inquiry forms, the student-faculty-lab rosters hanging off university CMSes, the unpublished article drafts and source contact lists on large media sites, and the admin password hashes that quietly link out to SSO infrastructure behind the scenes. Land this CVE, and without ever opening a login screen a single URL parameter drags every citizen address, phone number, and inquiry body out of PostgreSQL. The default behavior of this CVE is "an anonymous request walks off with the high-value database whole."

In security terminology, this is an unauthenticated remote SQL injection — attack complexity, required privileges and required user interaction all bottom out at the lowest possible rank. That combination is exactly why CISA shortened the federal deadline to an unusual five days instead of the standard several-week clock. Drupal's installed base skews toward government, higher education, large media and international organisations — operators where information has high political and economic value. The PostgreSQL filter narrows the target list even further, which from the attacker's side turns into a remarkably efficient hunting ground: "scan for Drupal-on-PostgreSQL and only the high-value prey is left in the net." This is the kind of bug that fuels silent, long-running data-exfiltration campaigns rather than loud defacements.

A 9.8 score gauges the damage measured on the server side, but the burden that lands on a government-site or university-site admin overflows that box: every citizen who entered an address, every student who registered a record, every contact who emailed a request gets enumerated as "a victim of the leak from that portal," and the operating organisation gets to face regulators, the campus senate, and the affected individuals at the same time. From the agency's perspective, the short deadline is exactly the runway before they become the side that has to explain.

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

The core sequence — pre-announcement to patch to CISA deadline — unfolded inside nine days. The timeline below lays it out, with the current status as of July 23, 2026 added at the end.

← 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.

In the days after disclosure the dominant traffic shape was reconnaissance rather than exploitation. The most common probes were 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 were 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. The stop-gaps only buy time, so book a real patching window as soon as you can.

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.

Early on, Japanese-language writeups were scarce, and neither JPCERT/CC nor IPA had issued a Japanese advisory; that has not really changed. Site owners have to go straight to the primary sources (Drupal.org and the CISA KEV catalog). The worst failure mode here is assuming that "English-only coverage" or "minority database backend" means the risk doesn't apply — that's exactly the population that ends up exploited while the flaw sits on the actively-exploited list.

Additional Fixed Releases Since Disclosure, and What to Check Now

Formally, the CISA KEV deadline binds only U.S. federal agencies, and May 27 is long past. The listing still matters well beyond that date: 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, and post-incident reviews treat a missed KEV deadline on a critical CVE as an aggravating factor. As of July 23, 2026 CVE-2026-9082 is still on the catalog, so any PostgreSQL-backed site that hasn't applied the fix should update now, deadline or no deadline.

Since this flaw went public, Drupal core has shipped several unrelated security releases. On June 17, 2026 came SA-CORE-2026-005 through 009 — including CVE-2026-55803, a PHP object injection reachable only by an attacker with JSON:API write access under narrow conditions — and on July 15 came SA-CORE-2026-010 through 012 (an Image-module information leak in CVE-2026-15916, a Layout Builder cross-site scripting flaw in CVE-2026-55805, and more). None of them are on the KEV catalog as of July 23, 2026; CVE-2026-9082 is still the only Drupal core CVE on the actively-exploited list. That said, the latest stable releases have moved on to 11.4.4 on the 11.x line and 10.6.14 on the 10.x line, so the article-era assumption that "11.3 is the newest" is now outdated. If you are updating today, don't stop at this CVE's fix — go to the newest stable release on your branch. Mind the support windows too: 10.5.x reached end of security support in June 2026, while 10.6.x and 11.3.x are covered until December 2026.

To recap: this is "Drupal 8.9 or newer, running PostgreSQL." If that describes you, apply the fixed release (10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12 or 11.3.10 or newer) 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.