CVE-2026-9082

Drupal Core SQL Injection Exploitation (CVE-2026-9082)

Initial Access Credential Access Lateral Movement Last updated:

Detects exploitation attempts targeting CVE-2026-9082, a SQL injection vulnerability in Drupal Core. This KEV-listed vulnerability allows attackers to inject malicious SQL via crafted HTTP requests, potentially leading to unauthorized data access, credential theft, or remote code execution via stacked queries. Active exploitation has been observed in the wild.

Vulnerability Intelligence

KEV — Known Exploited

Affected Software

Vendor
Drupal
Product
Core

Weakness (CWE)

CWE-89

Timeline

Disclosed
May 22, 2026

CVSS

9.8
Critical (9.0–10)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Write-up coming soon

What is CVE-2026-9082 Drupal Core SQL Injection Exploitation (CVE-2026-9082)?

Drupal Core SQL Injection Exploitation (CVE-2026-9082) (CVE-2026-9082) maps to the Initial Access and Credential Access and Lateral Movement tactics — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for Drupal Core SQL Injection Exploitation (CVE-2026-9082), covering the data sources and telemetry it touches: W3CIISLog, AppServiceHTTPLogs, AzureDiagnostics. The queries below are rated critical severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access Credential Access Lateral Movement
Microsoft Sentinel / Defender
kusto 
union W3CIISLog, AppServiceHTTPLogs
| where TimeGenerated > ago(7d)
| where csUriQuery has_any ("UNION", "SELECT", "INSERT", "DROP", "UPDATE", "DELETE", "EXEC", "CAST(", "CONVERT(", "CHAR(", "CONCAT(", "0x", "--", "/*", "*/")
| where csUriStem has_any ("/node", "/user", "/admin", "/api", "/jsonapi", "/views")
| where scStatus in (200, 301, 302, 500, 403)
| extend DecodedQuery = url_decode(csUriQuery)
| extend SQLPatterns = extract_all(@"(?i)(union\s+select|select\s+.*from|insert\s+into|drop\s+table|exec\s*\(|xp_cmdshell|information_schema|sleep\s*\(|benchmark\s*\(|waitfor\s+delay)", DecodedQuery)
| where array_length(SQLPatterns) > 0
| project TimeGenerated, cIP, csHost, csUriStem, csUriQuery, DecodedQuery, SQLPatterns, scStatus, csUserAgent, csMethod
| summarize AttackCount=count(), Methods=make_set(csMethod), StatusCodes=make_set(scStatus), Paths=make_set(csUriStem) by cIP, bin(TimeGenerated, 5m)
| where AttackCount > 1
| sort by AttackCount desc

Detects SQL injection patterns in HTTP query strings targeting common Drupal URL paths, using IIS and App Service HTTP logs. Aggregates attempts per source IP within 5-minute windows.

critical severity high confidence

Data Sources

W3CIISLog AppServiceHTTPLogs AzureDiagnostics

Required Tables

W3CIISLog AppServiceHTTPLogs

False Positives

  • Security scanners or vulnerability assessment tools running authorized scans against Drupal instances
  • Penetration testing activities with SQL injection payloads in query parameters
  • Legitimate applications using URL parameters that contain SQL-like keywords (e.g., column names with 'select' in descriptive text)
  • WAF testing or red team exercises generating SQLi patterns
  • Search functionality that may include SQL reserved words in user queries

Sigma rule & cross-platform mapping

The detection logic for Drupal Core SQL Injection Exploitation (CVE-2026-9082) (CVE-2026-9082) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  product: azure

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for CVE-2026-9082 Sigma rules on detection.fyi

Platform-specific guides for CVE-2026-9082

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-06-19 Research depth: standard
References (2)

Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Drupal SQLi - Boolean-Based Blind Injection via Node Path

    Expected signal: Web server access logs will show two requests to /node/1 with URL-encoded SQL payloads (AND 1=1 and AND 1=2). First request should return 200, second may return 200 or 404 depending on injection success. SIEM should capture both entries with decoded URI showing SQL keywords.

  2. Test 2Drupal SQLi - Time-Based Blind Injection via User Login

    Expected signal: Web server logs capture POST to /user/login with SLEEP(5) in POST body. PHP error logs may show PDO exception. Response time of approximately 5+ seconds visible in access log timing field. Database slow query log will show the injected SLEEP query.

  3. Test 3Drupal SQLi - UNION-Based Schema Enumeration via JSON:API

    Expected signal: Access logs show GET request to /jsonapi/node/article with UNION SELECT and information_schema in URL parameters. Response code will be 200 or 500 depending on injection success. Database logs may show the injected UNION query. PHP error logs may expose column count mismatches.

  4. Test 4Drupal SQLi - Error-Based Injection for Database Version Fingerprinting

    Expected signal: Web server logs record GET request to /views/ajax with EXTRACTVALUE and VERSION() payloads. HTTP 500 response likely with MySQL XPATH syntax error in response body revealing database version. SIEM captures 0x hex encoding and VERSION() function in URI.

Response Playbook

Triage

  1. Identify the source IP(s) generating SQL injection patterns and determine if they are external (internet-facing attack) or internal (compromised host/lateral movement). Cross-reference against known threat intelligence feeds and your IP reputation service.
  2. Examine the specific SQLi payloads in the URI query strings: determine if payloads are blind SQLi (boolean/time-based), error-based, or UNION-based. Time-based payloads (SLEEP/WAITFOR) with corresponding HTTP response delays indicate successful injection.
  3. Check Drupal application and database logs for corresponding errors, unusual query patterns, or signs of data exfiltration. Look for database error messages returned in HTTP 500 responses that may reveal schema information.
  4. Determine the Drupal version and confirm patch status against CVE-2026-9082. Check if the Drupal Security Advisory SA-CORE-2026-004 patch has been applied. Review installed modules for versions listed as vulnerable.
  5. Assess whether any HTTP 200 responses were returned to SQLi requests, which may indicate successful injection. Compare baseline query response times against observed times if time-based blind injection is suspected.

Containment

  1. Immediately block the attacking source IP(s) at the perimeter firewall and WAF. If a CDN or load balancer is in use, apply IP blocks at that layer. For distributed attacks, consider temporarily enabling strict WAF rulesets blocking all SQLi pattern traffic.
  2. If exploitation is confirmed or strongly suspected, take the Drupal instance offline or into maintenance mode immediately to prevent further data access or exfiltration while remediation is performed. Notify stakeholders per your incident response plan.
  3. Rotate all Drupal database credentials, Drupal admin account passwords, and any API keys or secrets stored in the Drupal database. Revoke active sessions via the database (truncate the sessions table) to force re-authentication.

Evidence Collection

  1. Capture and preserve complete web server access logs (Apache/Nginx/IIS) covering the attack window. Include error logs and database slow query logs. Hash all collected log files for chain-of-custody integrity.
  2. Extract and document all unique SQL injection payloads observed, including URL-decoded versions. Record the targeted endpoints, HTTP methods, response codes, response sizes, and timing data. This supports forensic analysis and legal proceedings if required.
  3. Collect Drupal watchdog/dblog entries for the attack period, database audit logs if enabled, and any WAF or IDS alert logs. If database auditing was not enabled, note this gap for post-incident remediation.

Escalation Criteria

  • ! Escalate immediately to senior incident response and management if HTTP 200 responses with anomalous payload sizes were returned to SQLi requests — this indicates confirmed data exfiltration and triggers breach notification obligations.
  • ! Escalate if the Drupal database contains PII, payment card data, health records, or other regulated data categories, as successful SQLi may trigger GDPR, PCI-DSS, or HIPAA breach notification requirements within mandated timeframes.

Investigation Guide

Forensic Artifacts

  • > Web server access logs containing SQLi patterns in URI query strings (Apache access_log, Nginx access.log, IIS W3C logs)
  • > Drupal watchdog database table (watchdog) entries showing PHP errors or database exceptions triggered by malformed queries
  • > MySQL/PostgreSQL/SQLite slow query logs or general query logs showing injected SQL statements
  • > WAF and IDS/IPS alert logs corresponding to the attack timeframe
  • > PHP error logs showing database PDO/DBI exceptions that may reveal injection success
  • > Filesystem artifacts: newly created files in Drupal webroot (web shells) if INTO OUTFILE payloads were used

Tuning Guidance

Start by baselining normal Drupal URL query parameter patterns in your environment — Drupal Views and Search API can generate complex URL parameters that may contain keywords like 'field' or 'type'. Exclude known scanner IPs and internal monitoring subnets. For high-traffic sites, increase the aggregation window from 5 minutes to 15 minutes and raise the attempt threshold from 2 to 5 to reduce volume without losing signal. Enable URL decoding in your SIEM pipeline to catch encoded payloads (%27 for quote, %20 for space). If Drupal is behind a reverse proxy or CDN, ensure the source IP field reflects the originating client IP (X-Forwarded-For) rather than the proxy IP. Consider adding a whitelist for known vulnerability scanners in your authorized scanning program.

Hunting Queries

Hunt for database reconnaissance patterns in Drupal URLs — queries targeting information_schema or database metadata functions indicate an attacker mapping the database schema after initial injection, a strong indicator of active exploitation rather than mere scanning.

Hunting — KQL
kql 
union W3CIISLog, AppServiceHTTPLogs
| where TimeGenerated > ago(30d)
| where csUriQuery has_any ("information_schema", "table_name", "column_name", "schema_name", "user()", "version()", "database()")
| where csUriStem has_any ("/node", "/user", "/admin", "/api", "/jsonapi")
| project TimeGenerated, cIP, csUriStem, csUriQuery, scStatus, scBytes
| sort by TimeGenerated desc
Hunting — SPL
spl 
index=web sourcetype=access_combined OR sourcetype=iis
| where match(uri_query, "(?i)(information_schema|table_name|column_name|user\(\)|version\(\)|database\(\))")
| where match(uri_path, "(?i)(/node|/user|/admin|/api|/jsonapi)")
| eval decoded=urldecode(uri_query)
| table _time, src_ip, uri_path, decoded, status, bytes
| sort -_time

Hunt for confirmed time-based blind SQL injection by correlating time-delay functions in query strings with abnormally high HTTP response times (>5 seconds). A match between a SLEEP/WAITFOR payload and a corresponding response delay is high-confidence evidence of successful blind SQLi exploitation.

Hunting — KQL
kql 
union W3CIISLog, AppServiceHTTPLogs
| where TimeGenerated > ago(30d)
| where csUriQuery has_any ("sleep(", "waitfor delay", "benchmark(", "pg_sleep(")
| where csUriStem has_any ("/node", "/user", "/api", "/jsonapi", "/views")
| extend ResponseTime = scTimeTaken
| where ResponseTime > 5000
| project TimeGenerated, cIP, csUriStem, csUriQuery, scStatus, ResponseTime
| sort by ResponseTime desc
Hunting — SPL
spl 
index=web sourcetype=access_combined
| where match(uri_query, "(?i)(sleep\s*\(|waitfor\s+delay|benchmark\s*\(|pg_sleep\s*\()")
| where response_time > 5000
| table _time, src_ip, uri_path, uri_query, status, response_time
| sort -response_time

Atomic Red Team Tests

Test 1 Drupal SQLi - Boolean-Based Blind Injection via Node Path
linux

Simulates a boolean-based blind SQL injection attempt against a Drupal node endpoint, a common technique to enumerate database contents without visible error output.

Command

bash 
curl -sk 'http://TARGET_DRUPAL/node/1?field_data=1%27%20AND%201%3D1--%20-' -o /dev/null -w '%{http_code}\n' && curl -sk 'http://TARGET_DRUPAL/node/1?field_data=1%27%20AND%201%3D2--%20-' -o /dev/null -w '%{http_code}\n'

Cleanup

bash 
No cleanup required — HTTP request only, no persistence created.

Expected Telemetry

Web server access logs will show two requests to /node/1 with URL-encoded SQL payloads (AND 1=1 and AND 1=2). First request should return 200, second may return 200 or 404 depending on injection success. SIEM should capture both entries with decoded URI showing SQL keywords.

Expected Detection

Both queries trigger the SQL injection detection rule due to UNION/SELECT/AND patterns in the URI query string targeting a /node path.

Test 2 Drupal SQLi - Time-Based Blind Injection via User Login
linux

Simulates time-based blind SQL injection against the Drupal user login endpoint to confirm database injection and measure response delay as proof of execution.

Command

bash 
time curl -sk -X POST 'http://TARGET_DRUPAL/user/login' --data 'name=admin%27%20AND%20SLEEP(5)--%20-&pass=test&form_id=user_login_form' -o /dev/null

Cleanup

bash 
No cleanup required — POST request only, no server-side changes if injection fails at authentication.

Expected Telemetry

Web server logs capture POST to /user/login with SLEEP(5) in POST body. PHP error logs may show PDO exception. Response time of approximately 5+ seconds visible in access log timing field. Database slow query log will show the injected SLEEP query.

Expected Detection

Triggers detection on SLEEP pattern in request URI/body targeting /user path. Time-based hunting query will correlate the SLEEP payload with the >5000ms response time, providing high-confidence confirmation of successful injection.

Test 3 Drupal SQLi - UNION-Based Schema Enumeration via JSON:API
linux

Simulates a UNION-based SQL injection attempting to enumerate database schema via Drupal's JSON:API endpoint, targeting the information_schema to extract table names.

Command

bash 
curl -sk 'http://TARGET_DRUPAL/jsonapi/node/article?filter[field_name][value]=1%27%20UNION%20SELECT%201,table_name,3,4,5,6,7%20FROM%20information_schema.tables%20WHERE%20table_schema%3Ddatabase()--%20-' -H 'Accept: application/vnd.api+json'

Cleanup

bash 
No cleanup required — read-only HTTP GET request.

Expected Telemetry

Access logs show GET request to /jsonapi/node/article with UNION SELECT and information_schema in URL parameters. Response code will be 200 or 500 depending on injection success. Database logs may show the injected UNION query. PHP error logs may expose column count mismatches.

Expected Detection

Triggers high-confidence detection on both UNION SELECT and information_schema keywords in URI targeting /jsonapi path. Also triggers the schema reconnaissance hunting query.

Test 4 Drupal SQLi - Error-Based Injection for Database Version Fingerprinting
linux

Simulates error-based SQL injection to extract database version information through Drupal's Views endpoint, leveraging verbose error responses.

Command

bash 
curl -sk 'http://TARGET_DRUPAL/views/ajax?view_name=frontpage&view_display_id=page_1&view_args=1%27%20AND%20EXTRACTVALUE(1,CONCAT(0x7e,VERSION()))--%20-'

Cleanup

bash 
No cleanup required — read-only HTTP GET request.

Expected Telemetry

Web server logs record GET request to /views/ajax with EXTRACTVALUE and VERSION() payloads. HTTP 500 response likely with MySQL XPATH syntax error in response body revealing database version. SIEM captures 0x hex encoding and VERSION() function in URI.

Expected Detection

Triggers detection on hex-encoded payload (0x7e) and SQL function patterns in URI targeting /views path. Error-based injection typically returns 500 status which can be correlated in status-code-based detection rules.

Related Detections

Tactic Hubs

TA0001Initial AccessTA0006Credential AccessTA0008Lateral Movement

Related Techniques

T1190Exploit Public-Facing ApplicationT1213Data from Information RepositoriesT1078Valid AccountsT1505.003Web Shell

Same Tactic: Initial Access

Popular Detections