osbytes

Search

Find posts, projects, and members.

← back to blog

Drupal CVE-2026-9082 lands on CISA KEV the same morning exploit attempts hit the advisory

2026-05-22by@osbytes5 min read
#drupal #sql-injection #postgresql #cisa-kev #cms #security #coordinated-disclosure

TL;DR

  • SA-CORE-2026-004 picked up a May 22, 04:30 UTC note: exploit attempts are now showing up in the wild, and the internal risk score moved to match.
  • CISA’s Known Exploited Vulnerabilities catalog (catalogVersion 2026.05.22) lists CVE-2026-9082 with dateAdded 2026-05-22 and a dueDate of 2026-05-27 for orgs that live under BOD 22-01 style calendars.
  • NVD still points at the same Drupal advisory as the patch source; the useful delta today is behavioral confirmation plus the federal clock, not a second technical root cause write-up.

What changed since the coordinated drop

Two days ago Drupal shipped a coordinated security release for a highly critical flaw in core’s database abstraction layer, tracked as CVE-2026-9082. The write-up has always been blunt: anonymous attackers can reach arbitrary SQL injection on sites whose backing store is PostgreSQL, with outcomes Drupal lists as information disclosure and, in some configurations, privilege escalation or worse. Everyone else still got a nudge because the same maintenance releases folded in Symfony and Twig advisories Drupal links from the same page.

The advisory delta is smaller on bytes, larger on urgency. Drupal appended an Updates line time-stamped May 22 2026, 04:30 UTC stating that exploit attempts are now being detected and that the risk score was revised to reflect that. That is the kind of edit security teams watch for: same URL, new facts.

Hours later, CISA’s published KEV feed (dateReleased 2026-05-22T18:00:11Z in the JSON envelope) carries a new row for the same CVE. dateAdded is 2026-05-22, dueDate is 2026-05-27, and the required action is the usual “follow vendor guidance / BOD 22-01 cloud language / stop using it if you cannot patch” triad. If your compliance function only wakes up for KEV, it just woke up.

How to read the blast radius without overfitting

Treat the SQL injection itself as PostgreSQL-shaped. Drupal’s own language is explicit: crafted web requests hit the DB API and become injection on PostgreSQL-backed installs. If you run MySQL or MariaDB, you are not magically “fine” in the long run; you still inherit the dependency advisories bundled into the same security releases, and those deserve the same change window.

Treat the KEV row as calendar pressure, not a second opinion on exploit mechanics. CISA’s short description compresses the impact ladder into “privilege escalation and remote code execution via specially crafted requests,” which is broader than Drupal’s “PostgreSQL + DB API” framing. When the two disagree, patch against the vendor reproduction and release matrix, use CISA for deadline arithmetic.

What to do in the next maintenance window

Work from the advisory’s Solution table, not a blog paraphrase: pick the fixed minor that matches your supported branch (11.3.10, 11.2.12, 10.6.9, 10.5.10, plus the exceptional backports called out there for older supported lines). If you are still on EOL 11.0/11.1 or 10.4, Drupal shipped best-effort tarballs anyway because the issue is nasty; expect frank talk in the advisory about other known holes still present on those branches.

If you cannot upgrade immediately, be honest about what “compensating control” actually buys: virtual patching or WAF rules can blunt dumb scans, but this class of bug tends to iterate fast once it is public. Your more durable buys are version movement, breaking-glass releases, and evidence (composer.lock / vendor diff, RPM/DEB inventory, platform-managed Drupal images) you can show an auditor after the fact.

Sources