CVE-2026-45262 Splunk · SPL

Detect FacturaScripts REST API Authenticated SQL Injection via Where::sqlColumn Parenthesis Bypass (CVE-2026-45262) in Splunk

FacturaScripts prior to and including version 2026.1 contains an authenticated SQL injection vulnerability in the REST API 'filter' parameter. The Where::sqlColumn method fails to properly sanitize column/operator tokens when parentheses are used to bypass filter validation, allowing an authenticated low-privileged API user (with a valid API key) to inject arbitrary SQL via crafted filter[field][operator] query string parameters. Given CVSS 9.9 and CWE-918 (SSRF) alongside CWE-89, exploitation may extend beyond data exfiltration into internal request forgery via database-level functions (e.g., LOAD_FILE, or DB-driver network calls), enabling full compromise of the underlying MySQL/MariaDB/PostgreSQL instance and lateral movement into internal network segments reachable from the database host.

MITRE ATT&CK

Tactic
Initial Access Collection Exfiltration

SPL Detection Query

Splunk (SPL)
spl
index=web sourcetype=access_combined OR sourcetype=nginx:access uri_path="*/api/*"
| where match(uri_query, "filter\[[a-zA-Z0-9_]+\]")
| eval decoded_query=urldecode(uri_query)
| regex decoded_query="(?i)(\)\(|UNION\s+SELECT|SLEEP\(|BENCHMARK\(|OR\s+1=1|--\s|/\*)"
| table _time, clientip, method, uri_path, decoded_query, status
| sort -_time
critical severity medium confidence

Searches proxy/web access logs for FacturaScripts API filter parameters containing parenthesis-bypass or SQL injection syntax consistent with CVE-2026-45262.

Data Sources

Web Proxy LogsSplunk Stream HTTP

Required Sourcetypes

access_combinednginx:access

False Positives & Tuning

  • Analytics dashboards passing complex parenthesized filter expressions
  • Third-party integrations using legitimate compound filter logic
  • Vulnerability scanning tools probing the API with SQLi test payloads under authorization

Other platforms for CVE-2026-45262


Testing Methodology

Validate this detection against 3 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 1Simulate Parenthesis-Bypass Filter SQLi Probe

    Expected signal: HTTP access log entry showing the encoded filter parameter with '))' and 'OR 1=1--' tokens against the /api/3/clientes endpoint.

  2. Test 2Simulate UNION SELECT Injection via Filter Parameter

    Expected signal: Web access log and database general_log entries showing a UNION SELECT statement referencing fs_users table.

  3. Test 3Simulate Time-Based Blind SQLi via SLEEP()

    Expected signal: Observable response delay (~5s) in HTTP access logs plus SLEEP( token present in the decoded filter query string.


Response Playbook

Triage

  1. Confirm the affected FacturaScripts instance version is <= 2026.1 by checking the application's version endpoint or composer.lock file.
  2. Pull the raw HTTP request logs for the alerting event and manually decode the filter[] query parameter to verify presence of parenthesis-bypass or SQLi tokens.
  3. Identify the authenticated API key/user associated with the request and check its normal usage baseline (typical endpoints, request volume, source IPs).
  4. Query the database audit log (general_log / pg_stat_statements) around the alert timestamp for anomalous or malformed SQL statements correlating with the API request.

Containment

  1. Revoke or rotate the API key used in the malicious request and force re-authentication for the associated user account.
  2. Apply a temporary WAF/reverse-proxy rule blocking requests to /api/*/list or /api/*/export endpoints where the filter parameter contains unbalanced parentheses or SQL keywords, until the vendor patch is applied.
  3. Upgrade FacturaScripts to the patched release addressing GHSA-5qmh-x653-g8qj as soon as feasible.

Evidence Collection

  1. Preserve full HTTP request/response logs (including headers, source IP, API key ID) for the suspicious requests.
  2. Export database transaction/audit logs covering the incident window for forensic SQL analysis.
  3. Snapshot the affected database schema and any tables accessed (e.g., users, empresas, api_keys) to assess data exposure.
  4. Capture the application and web server error logs for stack traces or SQL error messages triggered by the injection attempts.

Escalation Criteria

  • !Evidence of successful data exfiltration from sensitive tables (users, api_keys, financial records) — escalate to incident response immediately.
  • !Indications the SSRF/CWE-918 component was used to reach internal network services or cloud metadata endpoints from the database host.
  • !Multiple distinct API keys or source IPs exhibiting the same injection pattern, suggesting broader compromise or credential reuse.

Investigation Guide

Related Techniques

Forensic Artifacts

  • >Web/application server access logs showing filter[] query parameters with parenthesis-bypass or SQL keyword patterns
  • >Database general/audit query log entries with malformed or unexpected SQL syntax originating from the API service account
  • >API key usage/audit records showing anomalous endpoint access patterns
  • >Application error logs or exception traces referencing Where::sqlColumn or SQL syntax errors

Tuning Guidance

Baseline normal filter[] usage patterns for your FacturaScripts deployment, as legitimate nested date-range or compound filters can include parentheses. Exclude known internal automation/integration IPs after validating their query syntax is benign. Tighten thresholds if the deployment exposes the API only to a small set of trusted partners, and lower detection sensitivity thresholds once the vendor patch is confirmed deployed but keep monitoring for post-patch bypass attempts.


Hunting Queries

Hunts for repeated bursts of anomalous filter parameter usage from a single client IP over a rolling one-hour window, indicating automated SQLi probing or exploitation attempts.

Hunting — KQL
kql
AppServiceHTTPLogs
| where CsUriStem has "/api/"
| extend q=url_decode(CsUriQuery)
| where q has "filter" and q has_any ("'", "--", "UNION", "))")
| summarize count() by CIp, bin(TimeGenerated, 1h)
| where count_ > 5
Hunting — SPL
spl
index=web uri_path="*/api/*"
| eval decoded=urldecode(uri_query)
| where match(decoded, "filter") AND match(decoded, "(--|UNION|\)\()")
| stats count by clientip, bucket=_time span=1h
| where count > 5

Atomic Red Team Tests

Test 1 Simulate Parenthesis-Bypass Filter SQLi Probe
linux

Sends a crafted GET request to a lab FacturaScripts API instance with a filter parameter containing parenthesis-bypass SQL injection syntax to validate detection coverage.

Command

bash
curl -s -G 'http://lab-facturascripts.local/api/3/clientes' --data-urlencode "filter[nombre][))=OR 1=1--]" -H "Authorization: Bearer $LAB_API_KEY"

Cleanup

bash
No persistent changes made; clear shell history entry containing the lab API key if reused.

Expected Telemetry

HTTP access log entry showing the encoded filter parameter with '))' and 'OR 1=1--' tokens against the /api/3/clientes endpoint.

Expected Detection

KQL/SPL rules alert on the filter parameter containing parenthesis-bypass and SQLi tokens.

Test 2 Simulate UNION SELECT Injection via Filter Parameter
linux

Attempts a UNION-based SQL injection through the filter parameter to test data exfiltration detection paths in a lab environment.

Command

bash
curl -s -G 'http://lab-facturascripts.local/api/3/productos' --data-urlencode "filter[referencia][)) UNION SELECT nick,password,3 FROM fs_users-- -]" -H "Authorization: Bearer $LAB_API_KEY"

Cleanup

bash
No persistent state changes; rotate the lab API key after test completion as good hygiene.

Expected Telemetry

Web access log and database general_log entries showing a UNION SELECT statement referencing fs_users table.

Expected Detection

SIEM detections flag the UNION SELECT and parenthesis-bypass pattern in the request URI; database audit log correlation confirms anomalous query execution.

Test 3 Simulate Time-Based Blind SQLi via SLEEP()
linux

Issues a time-based blind SQL injection payload using SLEEP() through the filter parameter to validate detection of blind exploitation techniques.

Command

bash
curl -s -G 'http://lab-facturascripts.local/api/3/albaranclientes' --data-urlencode "filter[idalbaran][)) OR SLEEP(5)-- -]" -H "Authorization: Bearer $LAB_API_KEY" -w 'time_total: %{time_total}\n'

Cleanup

bash
No persistent changes; verify lab database performance returns to normal after test.

Expected Telemetry

Observable response delay (~5s) in HTTP access logs plus SLEEP( token present in the decoded filter query string.

Expected Detection

Detection rules matching SLEEP( pattern in filter parameters trigger; response latency anomaly can be cross-referenced for confirmation.

Related Detections