Drupal issued a highly critical security patch on May 20 for CVE-2026-9082, a SQL injection vulnerability that allows unauthenticated attackers to compromise sites running PostgreSQL databases. The project maintainers warned ahead of the release that exploits could surface within hours or days. That prediction was accurate; exploitation attempts started almost immediately, and within 48 hours, security firms were tracking thousands of attacks in the wild.
The vulnerability sits in an API designed to sanitize database queries and prevent SQL injection. A flaw in that API means an attacker can send specially crafted requests and inject arbitrary SQL commands on sites using PostgreSQL. As Drupal put it in its advisory.
“A vulnerability in this API allows an attacker to send specially crafted requests, resulting in arbitrary SQL injection for sites using PostgreSQL databases. This can lead to information disclosure, and in some cases privilege escalation, remote code execution, or other attacks.” reads the advisory. “This vulnerability can be exploited by anonymous users.”
The result can range from information disclosure to privilege escalation and, in some configurations, remote code execution.
Not every Drupal site is affected, the flaw only impacts those running PostgreSQL as the database backend, which Drupal estimates at under 5 percent of all installations. That still translates to thousands of potentially vulnerable sites given that Drupal powers hundreds of thousands of websites globally, many of them in government, higher education, media, and enterprise environments.
The advisory for CVE-2026-9082 was updated on May 22, two days after the patch released, with a detail that confirmed what many had already suspected:
“The risk score has been updated to reflect that exploit attempts are now being detected in the wild.” reads the updated advisory.
Drupal uses the NIST CVSS scoring system where the maximum possible rating is 25, so a score of 23 puts this firmly in the “drop everything and patch” category.
Imperva researchers published data showing just how quickly attackers moved. The security firm reported observing over 15,000 exploitation attempts targeting nearly 6,000 sites across 65 countries in the first two days after disclosure. Almost half of those attacks were aimed at gaming and financial services websites, sectors where both credential theft and financial data access have immediate monetization paths.
“Since CVE-2026-9082 was released, Imperva has observed over 15,000 attack attempts targeting almost 6,000 individual sites across 65 countries. Attacks are primarily targeting Gaming and Financial Services sites so far, at collectively almost 50% of all attacks.” states Imperva. “This pattern suggests attackers and scanners are primarily attempting to identify exposed Drupal sites running vulnerable PostgreSQL-backed configurations. While the activity is currently dominated by reconnaissance and validation, the nature of the vulnerability means successful exploitation could quickly move from probing to data extraction or privilege escalation.”
Top targeted countries are the U.S. (61.8%), Singapore (6.6%), and Australia (6.3).
That is the detail that matters most for defenders right now. What is being observed at scale is still largely reconnaissance, attackers mapping out which sites are vulnerable, testing exploits, and confirming they work. The fact that it has not yet escalated to widespread data theft or system compromise is not a reason to wait. It is a window that will close.
For administrators running Drupal sites on PostgreSQL, the action is straightforward: apply the patch immediately. For those running MySQL or MariaDB, the vulnerability does not apply, but verifying which database backend a site is using is worth doing rather than assuming. And for anyone managing Drupal infrastructure who has not patched yet and is seeing unusual database query patterns or failed authentication attempts in logs, it is worth treating those as potentially hostile and investigating promptly.
The pattern Imperva is observing, widespread reconnaissance followed by selective exploitation, is how these campaigns typically unfold. The current phase is mapping. The next phase is harvesting. The window to get ahead of that transition is narrow and shrinking.
The last time Drupal saw active exploitation of a highly critical flaw was back in 2019, when a remote code execution bug was hit within days of the patch going live. Before that, the flaws known as Drupalgeddon and Drupalgeddon2 made headlines for being weaponized at scale to compromise tens of thousands of sites. Since 2019, Drupal’s track record has been notably cleaner, highly critical vulnerabilities have been rare, and when they do appear, widespread exploitation has not followed.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Drupal)
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。