HIGH: Drupal Core SQL Injection CVE-2026-9082 Hits CISA KEV Days After Disclosure

If you run Drupal on PostgreSQL, the last 72 hours have been the kind that ruin a long weekend. Drupal published SA-CORE-2026-004 on May 20 to disclose an SQL injection bug in the core database abstraction API, tracked as CVE-2026-9082 and rated 23 out of 25 on Drupal's own severity scale, which is the tier the project labels Highly Critical and does not hand out lightly. Two days later, on May 22, Drupal updated the advisory to confirm that exploit attempts were already landing in the wild. CISA added the bug to its Known Exploited Vulnerabilities catalog the same day and gave Federal Civilian Executive Branch agencies until May 27 to patch or remove affected systems. That is a five day window from disclosure to mandated remediation, which is about as compressed as CISA gets short of an emergency directive.

The technical heart of the bug is exactly the kind of finding that makes a database team grimace. The vulnerability lives in Drupal core's database abstraction layer, the code path every contributed module relies on when it talks to the database, and it allows anonymous attackers to inject SQL through crafted requests when the underlying database is PostgreSQL. Sites running MySQL, MariaDB, or SQLite are not affected, which is the rare piece of good news in the advisory. The bug was reported by researcher Michael Maturi. Successful exploitation gives an attacker enough leverage in the database to escalate privileges, and from there to remote code execution, which means a website that was supposed to be serving content suddenly becomes a foothold inside whatever network it sits in.

The official CVSS base score landed at 6.5, which on paper reads as a fairly polite medium severity rating. That number undersells what is actually going on. Drupal's internal rating, which weighs the realities of a CMS deployed at internet scale, classified the same bug as highly critical because the combination of unauthenticated network access, an SQL injection primitive in core, and a feasible path to remote code execution is exactly the combination that historically becomes a worm or a mass deface within a week of disclosure. CISA's KEV listing within 48 hours, and Imperva's telemetry showing real exploitation, both vindicate the higher rating. If you have a Drupal site behind PostgreSQL, treat this like a critical regardless of what the CVSS number says.

The affected version sprawl is impressive in the depressing sense of the word. Drupal 8.9.0 through 10.4.9 are vulnerable, along with the 10.5 train through 10.5.9, the 10.6 train through 10.6.8, and the 11 series from 11.0.0 all the way through 11.3.9 with intermediate stops on 11.1.9 and 11.2.11. Drupal pushed fixes in 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10, and 10.4.10 simultaneously. The project also released patches for Drupal 8.9 and 9.5 despite both being out of long term support, a clear signal that maintainers expect a meaningful population of unsupported sites in the wild and would rather hand out a patch than read about another mass compromise on Bleeping Computer next week.

Imperva published the first hard numbers on exploitation activity within hours of the KEV addition. The company says it observed more than 15,000 attack attempts targeting close to 6,000 distinct sites across 65 countries. The current activity is overwhelmingly probing, with attackers fingerprinting Drupal sites and checking whether they sit on PostgreSQL backends before committing to a full exploit. Gaming and financial services sites accounted for roughly half of the traffic Imperva flagged, which tracks with where the better data and the better monetization paths happen to live. The framing matters for defenders. Probing today becomes data exfiltration and webshell deployment tomorrow, and the operators running the scanners are mapping the attack surface for a follow up wave that will be quieter and more targeted.

For organizations trying to figure out whether they are exposed, the first question is the only one that really matters in the short term. Is the database backend PostgreSQL. The Drupal documentation makes this easy enough to verify through settings.php, where the database driver and connection settings are spelled out near the top of the file. Hosts running on Pantheon, for example, default to MySQL or MariaDB depending on the plan, while many self hosted enterprise Drupal deployments lean PostgreSQL for reasons related to scaling, replication, or compliance. Government and higher education tend to skew PostgreSQL more than the broader Drupal user base, which is part of why the federal patch deadline matters. If your site uses PostgreSQL and you do not have a patch in flight today, you are squarely inside the population the attackers are currently fingerprinting.

The patching steps themselves are mercifully familiar to anyone who has run a Drupal site through a security release before. Composer based sites can take the relevant point release through the standard composer require workflow, push it through the same continuous integration pipeline they use for any other deployment, and run database updates via drush updb. Sites still managed through the older tarball replacement process need to drop in the new core files and refresh the database schema the same way they would for any other security release. The bigger risk for most operators is not the patch itself, it is the modules, custom code, and Composer constraint files that pin Drupal core to a specific minor version and have to be loosened first. Plan to spend the bulk of the maintenance window reading dependency errors, not changing core files.

While the upgrade is being staged, defenders have some immediate actions available that do not require touching production. Web application firewalls in front of the site are the obvious first stop. Most major WAF vendors, including Imperva, Cloudflare, Akamai, and AWS WAF, shipped detection signatures for CVE-2026-9082 within hours of the advisory. Tuning the existing SQL injection rules to a slightly more aggressive posture for the duration of this incident is a reasonable trade off, even if it produces a small bump in false positives on legitimate admin traffic. On the host itself, defenders should look at access logs for unusual POST and GET activity against endpoints that interact with the database abstraction API, particularly any traffic that includes obvious SQL keywords inline in the query string or body and is coming from anonymous sessions. Imperva's reporting suggests the current wave of attackers is not putting much effort into evasion, which means simple signature based hunting actually works at this stage.

The story is also a useful reminder that database abstraction layers are not the security feature people sometimes imagine them to be. Drupal's database API is a strong piece of engineering and a major reason the platform has held up through nearly two decades of internet weather. It is also, by definition, a place where every contributed and custom module funnels SQL into the database, and that means a single bug in the abstraction layer touches the entire ecosystem at once. The same shape of issue has bitten Joomla, WordPress, and various ORM frameworks at different points over the years. Whenever a security boundary doubles as a developer convenience, the boundary tends to lose the argument with developer convenience over a long enough timeline.

For Drupal site owners who have been ignoring the urgency around modern Drupal upgrades, this is also the wake up call. The fix for sites running 8.9 or 9.5 exists, but those branches have been out of long term support long enough that any reasonable program would have already migrated to a supported release. If your organization is still running unsupported Drupal because the upgrade path is painful, congratulations, the upgrade path just got more painful in a different way. Schedule the modernization conversation for next week, with this incident as the opening exhibit.

The MSP angle here writes itself for any provider with even a small Drupal book of business. Every PostgreSQL backed customer needs a same week patch engagement, a WAF rule audit, and a quick log review to confirm no successful exploitation has already happened. Customers running unsupported Drupal branches need a modernization quote attached to that engagement, because patching an end of life CMS once is fine, but doing it for the third time in two years is malpractice. Bundle the patch work with a managed WAF subscription and a vulnerability management offering, because the next CVE in Drupal core, or in any other widely deployed CMS, is going to land on the same compressed timeline and the same customers will be asking the same questions. Sell the program, not the incident.