CVE-2026-9082: Critical Drupal SQL Injection Under Attack on Thousands of Sites

CVE-2026-9082 (a critical unauthenticated SQL injection — a class of attack where an attacker injects malicious database commands into application queries — in Drupal Core's database abstraction layer, targeting sites that use PostgreSQL as their database backend) is under active attack. Within hours of Drupal publishing security advisory SA-CORE-2026-004, security monitoring firms reported exploitation attempts against thousands of websites. Patches are available across all supported Drupal branches; sites running Drupal on PostgreSQL must upgrade immediately.

// 01 CVE-2026-9082: Technical Details

CVE-2026-9082 (CWE-89: Improper Neutralization of Special Elements Used in an SQL Command) is rooted in Drupal Core's database abstraction API — a layer of PHP code that allows Drupal modules to write database-agnostic queries that run on MySQL, PostgreSQL, and SQLite. The vulnerability is specifically in how this abstraction layer constructs parameterized queries for PostgreSQL. Insufficient sanitization of certain input allows an attacker to inject arbitrary SQL statements that the PostgreSQL server then executes with the privileges of the Drupal database user.

Critically, the flaw requires no authentication. An attacker can send a specially crafted HTTP request to a publicly accessible Drupal page — no login, no session cookie, no credentials — and trigger the injection.

SQL injection against a CMS database can cascade into several distinct harm classes:

• Information disclosure: Extract the full contents of the Drupal database, including hashed user passwords, session tokens, private content, configuration data, and stored API keys.
• Data manipulation: Modify or delete Drupal content, user roles, or configuration tables — including promoting arbitrary accounts to administrator privilege.
• Privilege escalation: Insert a new Drupal administrator account directly into the users and users_roles tables, bypassing the normal registration flow entirely.
• Remote Code Execution (RCE — the ability for an attacker to run arbitrary system commands on the server): PostgreSQL supports a COPY TO/FROM PROGRAM mechanism that allows executing shell commands from SQL. If the Drupal database user has been granted pg_execute_server_program or superuser privileges, an attacker can achieve OS-level command execution from CVE-2026-9082 alone.

Only sites running Drupal on PostgreSQL are affected. Drupal deployments using MySQL, MariaDB, or SQLite are not vulnerable to CVE-2026-9082. This is not a blanket "all Drupal sites" emergency — but identifying your backend is step one.

Affected Drupal core version ranges:

| Branch | Affected Versions | Patched Version | |——–|——————-|—————–| | 8.9.x / 9.5.x | 8.9.0 – 8.9.19 / 9.5.0 – 9.5.10 | 8.9.20 / 9.5.11 | | 10.4.x | 10.4.0 – 10.4.9 | 10.4.10 | | 10.5.x | 10.5.0 – 10.5.9 | 10.5.10 | | 10.6.x | 10.6.0 – 10.6.8 | 10.6.9 | | 11.1.x | 11.0.0 – 11.1.9 | 11.1.10 | | 11.2.x | 11.2.0 – 11.2.11 | 11.2.12 | | 11.3.x | 11.3.0 – 11.3.9 | 11.3.10 |

Drupal 10.3 and earlier branches have reached end-of-life and are not receiving security updates. Sites on unsupported branches should migrate to a supported release before patching.

// 02 Exploitation Status and Threat Landscape

CVE-2026-9082 followed the now-familiar "Drupalgeddon pattern": patch published, PoC derived within hours, mass exploitation begins the same day.

PoC derivable from patch diff. Drupal uses a public git repository for its codebase. The security fix was committed to the repository before the advisory was published — a necessary part of Drupal's release process. Attackers routinely monitor Drupal's git repository and derive functional PoC (Proof-of-Concept — working exploit code demonstrating the vulnerability) exploits by diffing the pre- and post-patch commits. Security researchers confirmed this happened within minutes of the SA-CORE-2026-004 commit landing.

Thousands of sites under attack. Both SecurityWeek and BleepingComputer reported that security monitoring firms — with visibility into honeypots, WAF logs, and endpoint telemetry — began detecting exploitation attempts at scale within hours of disclosure. The attacks appear opportunistic and automated: attackers are mass-scanning IP space for vulnerable Drupal endpoints and running exploitation tooling against any hit.

No threat actor named yet. Early-window mass exploitation of CMS vulnerabilities is typically carried out by financially motivated actors using automated tooling, followed by more targeted actors who purchase access to already-compromised sites. No named threat group has been attributed to CVE-2026-9082 exploitation at the time of writing.

CVE-2026-9082 is not currently listed on the CISA KEV (Known Exploited Vulnerabilities) catalog, but confirmed active exploitation of a critical unauthenticated flaw at this scale typically results in a KEV addition within days.

// 03 Who Is Affected

The practical exposure profile for CVE-2026-9082 is:

• Database backend is PostgreSQL — confirmed in sites/default/settings.php where $databases['default']['default']['driver'] equals pgsql.
• Running an affected Drupal version (any 8.9, 10.x, or 11.x release prior to the patched versions in the table above).
• Publicly accessible — the vulnerable endpoint must be reachable from the internet or the attacker's network position.

PostgreSQL is significantly less common than MySQL as a Drupal backend in shared hosting environments, but it is the default database choice in many enterprise, government, and higher-education Drupal deployments — sectors that also tend to run longer update cycles. The combination of PostgreSQL preference and slower patching cadence in these sectors creates an elevated real-world risk profile disproportionate to the raw percentage of PostgreSQL-backed Drupal sites.

Drupal powers an estimated 1.5 million websites globally. Even if 10% run PostgreSQL, the exposure pool is substantial — and the targets among that 10% are often among the most sensitive: government portals, university research sites, healthcare organizations.

// 04 What You Should Do Right Now

• Determine your database driver. Open sites/default/settings.php and find the $databases array. If you see 'driver' => 'pgsql', your site is vulnerable and must be patched immediately.

• Apply SA-CORE-2026-004 patches. Download and install the patched release for your Drupal branch from Drupal's release downloads. Use Drush or Composer for managed upgrades:

“bash composer update drupal/core --with-dependencies drush updatedb drush cache:rebuild “

• Check PostgreSQL logs for injection patterns. Review pg_log (or your configured PostgreSQL log destination) for anomalous query patterns:

“sql SELECT query, calls, total_exec_time FROM pg_stat_statements WHERE query ILIKE '%UNION%SELECT%' OR query ILIKE '%COPY%PROGRAM%' OR query ILIKE '%;%INSERT%' ORDER BY total_exec_time DESC LIMIT 20; “

• Audit Drupal administrator accounts. List all administrator-role accounts and compare against your known user base:

“bash drush user:list --roles=administrator “ Any unrecognized account with administrator role should be treated as an attacker backdoor and disabled immediately pending investigation.

• Review recent configuration changes. Check Drupal's built-in configuration history (admin/config/development/configuration) and the config_revisions table for changes you did not authorize. Attackers with database write access may have modified Drupal's configuration to enable PHP evaluation in fields or install malicious modules.

• Deploy WAF virtual patches. If immediate patching is blocked by change-management processes, apply emergency WAF (Web Application Firewall) rules. Cloudflare, AWS WAF, Fastly, and Akamai all publish CVE-specific rules within hours of disclosure for high-severity CMS vulnerabilities.

// 05 Background: Understanding the Risk

Drupal is one of the three most widely deployed open-source content management systems in the world. Unlike WordPress, which skews heavily toward small-to-medium websites and personal blogs, Drupal's modular architecture and fine-grained access control system have made it the preferred CMS for government agencies, universities, and large enterprises. This means a critical unauthenticated Drupal vulnerability has an unusually high concentration of high-value targets in its blast radius.

The history of Drupal exploitation under the "Drupalgeddon" moniker is instructive. SA-CORE-2014-005 (Drupalgeddon) — a critical SQL injection — was exploited within 7 hours of disclosure, and Drupal issued an extraordinary advisory warning that any unpatched site should be considered compromised. CVE-2018-7600 (Drupalgeddon2) followed a similar pattern: PoC within 24 hours, mass exploitation within 48, cryptocurrency miners and web shells installed across hundreds of thousands of sites within a week.

CVE-2026-9082 is tracking the same curve. The speed of exploitation — mass scanning observed within hours of the advisory — means that organizations checking this article days or weeks after publication should assume that unpatched sites running PostgreSQL have already been probed, and many have been compromised. The forensic investigation question is not "did someone try?" but "did someone succeed, and what did they do after?"

A SQL injection into a modern Drupal database extracts far more than just article content. Drupal stores Argon2-hashed user passwords, active session tokens that can be replayed without password, SMTP and API credentials in the configuration tables, and in many deployments, personally identifiable information of registered users. Full database exfiltration from a government or university Drupal site can enable credential-stuffing attacks against internal SSO systems, session hijacking of currently logged-in administrators, and social engineering using private user data.

// 06 Conclusion

CVE-2026-9082 is an unauthenticated SQL injection in Drupal Core that affects every PostgreSQL-backed Drupal site running versions 8.9 through 11.3.9 — and thousands of sites are already under automated attack. Administrators running Drupal on PostgreSQL must identify their exposure, apply SA-CORE-2026-004 patches immediately, and review database logs and administrator accounts for signs of compromise that may have already occurred.