What Drupal is warning about#
Drupal says it is already seeing attempts to exploit CVE-2026-9082, a highly critical vulnerability patched this week.
The issue sits in an API used to sanitize database queries and prevent SQL injection. According to Drupal, the flaw allows an attacker to send specially crafted requests that can result in arbitrary SQL injection on sites using PostgreSQL databases.
That scope matters. This is not described as a universal Drupal exposure across every database backend. The reported impact is tied to Drupal sites backed by PostgreSQL. Drupal estimates that less than 5% of sites are affected, even though the CMS itself powers hundreds of thousands of websites.
The vulnerability can be exploited by unauthenticated attackers. Drupal’s advisory says exploitation may allow information disclosure and, in some cases, privilege escalation and remote code execution. Those outcomes are not equivalent in every environment. The worst-case path depends on the affected site’s configuration and what the attacker can reach after injection.
Drupal had already warned that exploit code for CVE-2026-9082 could appear within hours or days of disclosure. That prediction appears to have been directionally correct. The advisory was later updated to reflect active exploit attempts in the wild.
Why the risk score changed#
Drupal uses the NIST CMSS scoring system for vulnerabilities, where the maximum risk rating is 25. The advisory for CVE-2026-9082 was updated on March 22, raising the risk score from 20 to 23.
The reason given was simple: exploit attempts are now being detected in the wild.
That does not automatically mean widespread successful compromise. It does mean the vulnerability has moved out of the purely theoretical phase. Once scanners and opportunistic attackers start testing a bug at internet scale, defenders lose the benefit of obscurity and timing.
This is especially important for CMS vulnerabilities. Public-facing CMS instances are easy to enumerate. Attackers can often test large numbers of sites quickly. If a reliable exploit path exists, the gap between disclosure, scanning, and compromise can be short.
SecurityWeek also notes the broader Drupal context. Highly critical vulnerabilities have not been patched in Drupal in years, and recent Drupal bugs have not commonly been reported as exploited in the wild. Older Drupal flaws before 2019 became high-profile because they were used to compromise many websites. That history is not proof that CVE-2026-9082 will follow the same pattern, but it explains why early exploitation signals around a highly critical Drupal issue get attention.
What Imperva saw#
Imperva reported more than 15,000 exploitation attempts against nearly 6,000 sites across 65 countries.
Almost half of the attacks observed by Imperva targeted gaming and financial services websites. The report does not establish that all targeted sites were vulnerable or compromised. Imperva’s interpretation is more cautious: the activity appears dominated by reconnaissance and validation.
That means attackers and scanners may be trying to answer basic questions first:
- Is this site running Drupal?
- Is it using a vulnerable version?
- Is the backend PostgreSQL?
- Does the crafted request produce a useful response?
This phase still matters. Reconnaissance is how attackers build target lists. A site that responds in a way that confirms exposure can be fed into a later exploitation pipeline. For SQL injection bugs, that later phase may shift from probing into data extraction, account takeover paths, privilege escalation, or attempts to reach code execution where the environment allows it.
Imperva’s warning is therefore measured but serious: the current activity may be mostly scanning, but the nature of the bug means successful exploitation could escalate quickly.
What site owners should check first#
The highest-priority question is whether your Drupal deployment uses PostgreSQL.
If it does not, the specific exposure described in the advisory may not apply in the same way. That should still be verified against Drupal’s own guidance and your actual deployment, not assumed from memory or old documentation.
For teams running Drupal, the practical checklist is direct:
- Confirm the Drupal version and whether the relevant patch has been applied.
- Confirm the database backend for each public-facing Drupal site.
- Prioritize PostgreSQL-backed Drupal instances for immediate review.
- Check web application firewall, CDN, and application logs for suspicious requests around the disclosure window.
- Look for signs of SQL injection probing, unusual database errors, or unexpected privilege changes.
- Review administrator accounts and recently changed roles or permissions.
- Treat internet-facing, unpatched PostgreSQL-backed sites as urgent.
For managed environments, ask the hosting provider or application owner for explicit confirmation. “Drupal is managed” is not the same as “this vulnerability is patched.” The operational question is whether the vulnerable code path exists and whether the patch is deployed on the running system.
What not to overclaim#
There are several points worth keeping separate.
First, active exploit attempts are not the same as confirmed mass compromise. The source material reports exploitation attempts and large-scale targeting activity. It does not say that thousands of sites have been successfully breached.
Second, Drupal estimates less than 5% of sites are affected because the flaw is tied to PostgreSQL-backed configurations. That lowers the broad population at risk, but it does not lower urgency for sites inside that slice.
Third, the possible impact includes remote code execution in some cases, but that does not mean every vulnerable site is automatically exposed to RCE. SQL injection impact depends on database permissions, application behavior, configuration, and what secondary paths are reachable.
Fourth, scanner traffic can still be dangerous. Early reconnaissance often looks noisy and low-skill. It can still identify the subset of systems that later receive more focused exploitation.
The practical read#
CVE-2026-9082 is narrow enough to avoid panic and serious enough to demand fast checks.
If you run Drupal with PostgreSQL, patching and log review should not wait. If you run Drupal without PostgreSQL, confirm that fact and track the advisory, but keep the risk in proportion. If you manage many Drupal sites, inventory is the first control: database backend, patch state, exposure, and owner.
The key signal is not just the vulnerability rating. It is the timing. Drupal expected exploit development quickly. The advisory risk score rose after exploit attempts were detected. Imperva then reported broad scanning across thousands of sites.
That is the normal shape of a CMS bug moving into attacker workflows. The useful response is not drama. It is fast verification, patch deployment, and evidence-based review of the systems most likely to be exposed.