The CVSS 6.5 score for CVE-2026-76343 badly misrepresents the actual risk. Yes, it's a SQL injection in Splunk's Data Orchestration feature — but the injection is merely the mechanism that exposes a structural failure in how Splunk handles credential stewardship. A user with any authenticated role can reach an endpoint that accepts user-controlled job filter values and constructs database queries from them. That's not a coding oversight; it's a fundamental breakdown in Splunk's role-based access model, where authorization is checked at the API boundary but untrusted input is allowed to flow straight into query construction logic regardless of who is calling it. The RBAC model treats authenticated users as trusted inputs, which collapses the moment any injection vector exists.
The more critical issue is what those queries return: stored connection credentials. Data Orchestration doesn't just hold Splunk's own secrets — it's designed to store database passwords, API keys, and service account tokens that Splunk uses to connect to external systems. Those credentials aren't secrets Splunk is hiding from users; they're secrets Splunk is stewarding on behalf of the infrastructure it integrates with. An attacker exploiting this vulnerability isn't just reading Splunk's internal store — they're harvesting credentials that can pivot to production databases, message queues, and APIs that almost certainly have weaker access controls than Splunk itself. That's lateral movement, and it's unbounded in a way CVSS is structurally incapable of scoring.
The patch versioning across 9.x, 10.0.x, 10.2.x, and 10.4.x tells you this code has been in production for years. The fact that Splunk is still shipping patches for 9.4.14 confirms long-tail exposure through enterprise customers on extended support cycles — this vulnerability will persist in production environments for years regardless of what the EPSS score suggests. The low 0.00276 EPSS reflects the technical complexity of the attack chain (specific role + specific endpoint + specific payload + credential pivot), not the severity of what happens when it succeeds. Automated scanners won't easily find this, but targeted reconnaissance of Splunk deployments will.
Prioritize remediation based on which systems Data Orchestration connects to, not just the injection severity. If Splunk holds credentials for production databases or cloud services, treat this as a critical infrastructure pivot point — the injection is the door, but the credentials are what an attacker is actually after.