Drupal’s latest emergency patch is the kind of vulnerability window defenders cannot treat as routine maintenance. CVE-2026-9082 is a highly critical SQL injection flaw in Drupal core affecting PostgreSQL-backed deployments, and exploitation attempts were observed within two days of disclosure.
The narrow technical scope matters: this is not every Drupal site. But the operational risk is still serious because Drupal is common in public-sector, higher-education, nonprofit, media, and contractor environments where external websites often sit close to identity workflows, document repositories, and public-facing service portals.
What happened
SecurityAffairs reported that attackers began exploiting CVE-2026-9082 shortly after Drupal released patches on May 20, 2026. Imperva later reported more than 15,000 exploitation attempts against nearly 6,000 sites across 65 countries, with gaming and financial services making up almost half of observed targeting.
The vulnerability is in Drupal’s database abstraction and entity query handling for PostgreSQL-backed sites. Specially crafted requests can reach SQL injection paths without authentication. Depending on configuration and follow-on access, impact can include information disclosure, privilege escalation, remote code execution, or additional attacks.
Affected Drupal versions include several supported 10.x and 11.x branches before the patched releases. Organizations should move to one of Drupal’s fixed versions: 10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12, or 11.3.10.
Why this matters for SMBs and government contractors
For a small business or government contractor, the dangerous assumption is “we do not run PostgreSQL, so this is not our problem.” The better first move is verification. Many organizations inherit websites from vendors, subcontractors, marketing teams, or previous IT providers. The person responsible for security may not know which database backend every Drupal instance uses.
This is also a good example of why public web assets need to be managed like production infrastructure, not brochureware. A vulnerable website can become a data exposure point, credential harvesting path, staging point for phishing, or foothold for deeper compromise. Even when the initial activity is “just scanning,” widespread validation usually precedes selective exploitation.
Defensive actions to take now
- Inventory Drupal assets: confirm which public, staging, and internal Drupal instances exist, including vendor-managed sites.
- Verify the database backend: identify whether each Drupal deployment uses PostgreSQL, MySQL, MariaDB, or another backend. Do not rely on memory.
- Patch affected systems immediately: upgrade to Drupal 10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12, or 11.3.10 as applicable.
- Review web logs: look for suspicious activity against JSON:API routes,
/user/login?_format=json, unusual filter parameters, PostgreSQL error behavior, and repeated probing from scanner infrastructure. - Harden exposure: restrict unnecessary JSON:API access, place high-value sites behind a WAF where practical, and make sure alerts cover application errors as well as successful logins.
- Check adjacent secrets: if exploitation is suspected, review application configuration, database access scope, CMS administrator activity, and any credentials stored in the site environment.
Bulwark Black assessment
CVE-2026-9082 is not just a Drupal patching story. It is an asset-management test. The organizations that handle this well will be the ones that can quickly answer three questions: where are our Drupal sites, which ones use PostgreSQL, and which ones have been probed since disclosure?
If those answers require days of vendor emails and spreadsheet archaeology, the real gap is not only the vulnerability. It is the lack of current ownership, dependency visibility, and emergency patch workflow for externally exposed systems.
Source: SecurityAffairs — CVE-2026-9082: Drupal’s Highly Critical SQL Injection Flaw Is Already Under Active Attack. Additional technical reporting from Imperva and Searchlight Cyber.
