What Happened
CVE-2026-9082, a SQL injection vulnerability in Drupal Core with a CVSS score of 6.5, moved from patch release to active exploitation faster than most security teams could deploy fixes. Imperva observed over 15,000 attack attempts targeting almost 6,000 sites globally. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog, setting a remediation deadline of May 27, 2026, for federal agencies—a timeline that should inform your own patching cadence.
The vulnerability affects all supported versions of Drupal Core. Attackers didn't wait to see if organizations would patch. They began probing immediately.
Timeline
Day 0: Drupal Security Team releases patches for all supported versions.
Day 1-3: Attack attempts begin appearing in web application firewall logs.
Days 4-7: Volume escalates to over 15,000 attempts across nearly 6,000 sites.
Week 2: CISA adds CVE-2026-9082 to the KEV catalog with a federal remediation deadline.
The pattern here matters more than the specific dates. Your patch window is measured in days, not weeks. If you're running monthly patch cycles, you're operating on an incompatible timeline.
Which Controls Failed or Were Missing
Vulnerability Scanning Cadence
Organizations hit by this vulnerability likely ran vulnerability scans on a schedule that didn't account for actively exploited CVEs. Monthly scans miss the window. Weekly scans might catch it before exploitation, but only if your scanner's signature database updates faster than attackers move.
Patch Deployment Process
A multi-week change control process becomes a liability when exploitation begins within days of disclosure. If your Drupal instances require three approval layers and a maintenance window two weeks out, you're structurally vulnerable to this attack pattern.
Web Application Firewall Rules
SQL injection is a known attack vector. Organizations without WAF rules blocking common SQL injection patterns—or with rules in detection-only mode—gave attackers a clear path to the database layer. Gaming and financial services sites were primary targets, suggesting attackers knew where valuable data lived.
Asset Inventory
You can't patch what you don't know you have. Shadow IT Drupal instances, forgotten staging environments, and contractor-deployed sites all present attack surfaces. If your asset inventory relies on quarterly manual audits, you're missing instances.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.1 mandates that security vulnerabilities are identified and addressed based on a defined risk ranking methodology. SQL injection vulnerabilities in internet-facing applications handling cardholder data demand immediate attention. The standard doesn't specify "within 30 days"—it requires risk-based prioritization. A CISA KEV listing signals maximum priority.
OWASP Top 10 2021: A03 Injection places injection vulnerabilities third in its risk ranking. The OWASP ASVS v4.0.3 goes further, requiring parameterized queries (V5.3.4) and input validation (V5.1.1) as baseline controls. If your Drupal modules use dynamic SQL construction, you're violating fundamental secure coding requirements.
NIST 800-53 Rev 5 SI-2 (Flaw Remediation) requires organizations to install security-relevant software updates within organization-defined time periods. For systems processing federal data, that time period is now explicitly defined: CISA's KEV deadline. For your systems, define it based on exploitation likelihood—and a KEV listing means exploitation is not just likely but confirmed.
ISO/IEC 27001:2022 Control 8.8 (Management of Technical Vulnerabilities) requires timely action on technical vulnerabilities. "Timely" isn't calendar-based—it's threat-based. When Imperva reports 15,000 exploitation attempts, you're past the "timely" window if you haven't patched.
Lessons and Action Items for Your Team
1. Separate Your Patch Tracks
Create an emergency patch process that bypasses normal change control for CISA KEV additions. Your monthly patch cycle can handle routine updates. Actively exploited vulnerabilities need a 48-72 hour track with pre-approved deployment authority.
Document the criteria: CISA KEV listing, CVSS 7.0+, or confirmed exploitation in your industry vertical. When any of these trigger, your emergency process activates.
2. Automate Vulnerability Correlation
Don't rely on manual checks of the CISA KEV catalog. Configure your vulnerability scanner to flag any CVE that appears in KEV, regardless of CVSS score. CVE-2026-9082 rated 6.5—below many organizations' "critical" threshold—but active exploitation makes it critical by definition.
Build a script that pulls the KEV JSON feed daily and cross-references your asset inventory. Alert when you find matches.
3. Implement WAF Virtual Patching
Deploy WAF rules for OWASP Top 10 attack patterns in blocking mode, not just detection. Virtual patching buys you time when you can't immediately deploy code fixes. For SQL injection specifically, block requests containing common SQL metacharacters in unexpected input fields.
Test these rules in detection mode first, but move to blocking within a week. False positives are manageable. Successful SQL injection isn't.
4. Map Your Drupal Attack Surface
Run a scan across your entire network range looking for Drupal indicators: /core/misc/drupal.js, /CHANGELOG.txt, or HTTP headers revealing Drupal version. Include all environments—production, staging, development, and contractor VPCs.
Update this inventory weekly. New Drupal instances appear faster than you think, especially in organizations with multiple development teams.
5. Define Your Patch SLA by Threat Intelligence
Stop using calendar-based patch schedules as your only mechanism. Add threat-intelligence-based triggers:
- CISA KEV addition: 72 hours
- CVSS 9.0+ with public exploit code: 7 days
- CVSS 7.0-8.9 with no known exploitation: 30 days
- CVSS <7.0: next regular maintenance window
Document these SLAs in your vulnerability management policy. Share them with application owners so they understand the urgency when you escalate.
6. Test Your Emergency Process Now
Don't wait for the next KEV listing to discover your emergency patch process doesn't work. Pick a non-critical Drupal module, simulate a critical vulnerability disclosure, and run your emergency process end-to-end.
Time each step. Identify bottlenecks. Get sign-off from change control that your emergency criteria are valid.
The 15,000 exploitation attempts targeting 6,000 sites weren't random scanning. Attackers knew Drupal's deployment patterns and moved fast. Your patch process needs to move faster.
