What Happened
The Cybersecurity and Infrastructure Security Agency (CISA) has added CVE-2026-9082, a critical SQL injection vulnerability in Drupal, to its Known Exploited Vulnerabilities (KEV) catalog. Federal agencies have been ordered to patch by midnight on May 27. This vulnerability allows attackers to execute arbitrary SQL commands on sites running Drupal with PostgreSQL databases. Imperva observed over 15,000 attack attempts targeting almost 6,000 individual sites across 65 countries, confirming active exploitation.
Timeline
While the exact disclosure timeline isn't publicly documented, the sequence is familiar: vulnerability discovery, patch release by Drupal, exploitation begins, and CISA issues a binding directive. The May 27 deadline gives federal agencies a narrow window to identify affected systems, test patches, and deploy them across production environments.
CISA's KEV catalog exists because organizations often fail to patch known vulnerabilities before attackers exploit them. The binding operational directive (BOD 22-01) requires federal civilian agencies to remediate KEV-listed vulnerabilities within prescribed timeframes—typically 14-21 days for critical flaws.
Which Controls Failed or Were Missing
This incident highlights failures across several control domains:
Asset Inventory Failure. Without knowing which systems run Drupal or their database backends, you can't patch them within a two-week window. The 6,000 sites hit across 65 countries suggest many organizations lack accurate application inventories.
Vulnerability Scanning Gaps. Organizations running authenticated scans against their Drupal instances should have detected this vulnerability immediately after the patch release. The fact that thousands of sites remained vulnerable indicates scanning either didn't happen, didn't cover these assets, or generated findings that were not acted upon.
Patch Management Process Breakdown. A two-week remediation window is tight but achievable with a functioning patch management process. The scramble suggests many organizations lack pre-approved change windows, tested rollback procedures, or designated patch owners for critical applications.
Third-party Risk Management. Many vulnerable Drupal instances likely run on hosting providers or are managed by external vendors. If your vendor relationship doesn't include SLAs for critical security patches, you're exposed.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.1 states: "Security vulnerabilities are identified and addressed as follows: High-risk and critical vulnerabilities are resolved based on the risk they pose to the environment." SQL injection vulnerabilities that allow arbitrary database access qualify as critical. The requirement explicitly calls for risk-based prioritization and timely remediation.
PCI DSS v4.0.1 Requirement 6.3.2 requires organizations to maintain an inventory of system components in scope for PCI DSS. If you're processing payment data through a Drupal site and can't immediately identify whether it's vulnerable to CVE-2026-9082, you're non-compliant before the vulnerability even matters.
NIST 800-53 Rev 5 SI-2 (Flaw Remediation) requires organizations to identify, report, and correct system flaws, test software and firmware updates for effectiveness and potential side effects, and install security-relevant updates within an organization-defined time period. For federal agencies, CISA has now defined that time period: two weeks.
ISO/IEC 27001:2022 Annex A.8.8 (Management of Technical Vulnerabilities) requires organizations to obtain timely information about technical vulnerabilities, evaluate exposure to such vulnerabilities, and take appropriate measures to address the associated risk. Waiting until CISA issues a binding directive doesn't meet "timely."
The OWASP Top 10 2021 lists injection attacks (including SQL injection) as the third most critical web application security risk. If your organization runs public-facing Drupal sites without a process to patch injection vulnerabilities within weeks of disclosure, you're ignoring a well-documented threat category.
Lessons and Action Items for Your Team
Build an Application Inventory That Includes Database Backends. Your CMDB should tell you within five minutes which applications run Drupal and which use PostgreSQL. If you can't answer that question right now, start with a discovery scan. Tag each application with its framework, database type, and business owner.
Subscribe to Vendor Security Advisories Directly. Don't wait for CISA to inform you about Drupal vulnerabilities. Subscribe to Drupal's security mailing list and create a ticketing workflow that automatically generates remediation tasks for critical and high-severity issues.
Establish Patch Windows for Different Risk Tiers. Critical vulnerabilities with active exploitation need emergency change procedures. Define what "emergency" means (severity + exploitability + asset criticality), who can approve emergency changes, and what testing is required versus waived.
Test Your Patch Process Under Time Pressure. Run a tabletop exercise where you give your team two weeks to patch a critical vulnerability across production. Identify where you get stuck—approvals, testing, deployment tooling—and fix those bottlenecks before the next real incident.
Map Your Applications to Compliance Requirements. If a Drupal site processes payment data, handles PHI, or stores customer PII, document which compliance frameworks apply. When a vulnerability drops, you'll know immediately whether you're facing a compliance deadline in addition to a security risk.
Define SLAs with Hosting Providers and Vendors. If a third party manages your Drupal infrastructure, your contract should specify response times for critical security patches. "Best effort" isn't acceptable for actively exploited vulnerabilities.
Automate Vulnerability Detection. Configure your vulnerability scanner to run authenticated scans against all web applications weekly at minimum. Route critical findings to a security queue with automatic escalation if they're not acknowledged within 24 hours.
The 15,000+ attack attempts Imperva observed didn't target sophisticated zero-days or nation-state toolkits. Attackers went after a published vulnerability with a known patch. Your patch management process is your primary defense against this entire class of threat. If you can't patch a critical SQL injection vulnerability within two weeks of disclosure, fix your process before you fix the next CVE.
