Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach Splunk Web over network
-
DeliverySend crafted request to JS logger endpoint
-
ExploitOversized headers bypass parsing limits
-
ExecutionExhaust web resources
-
ImpactSplunk Web hangs until restart
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource consumption limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires network access to the Splunk Web interface and the ability to send a single crafted request to the Splunk Web JavaScript logger endpoint; no authentication, credentials, or user interaction are needed (PR:N/UI:N), and default configurations of Splunk Enterprise in affected versions are vulnerable because Splunk Web does not limit request-header parsing before processing. The practical limiting factor is reachability: impact is confined to instances whose Splunk Web port is exposed to the attacker (internet-facing or attacker-adjacent networks). Only Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16 are affected, and the impact is limited to availability - recovery requires a restart of Splunk Enterprise but no data loss or compromise is implied. |
| Impact | This is a genuine but bounded operational risk, not a catastrophic one. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5 HIGH) is credible: a remote, unauthenticated attacker can trigger the condition over the network with low complexity and no user interaction. However, impact is availability-only (C:N/I:N) - this is a CWE-400 uncontrolled resource consumption / denial-of-service flaw, not a data-breach or code-execution bug, so the 7.5 is driven entirely by A:H. Mitigating signals: no EPSS score was provided, the CVE is NOT in CISA KEV, and no public exploit code was referenced (only the vendor advisory SVD-2026-1007), so there is no public exploit identified at time of analysis. The absence of EPSS/KEV data means exploitation-probability cannot be quantified from the input and is UNKNOWN rather than low. SSVC-style reasoning: exploitation is technically easy and 'automatable' in principle (single crafted request, no auth), but the technical impact is partial (availability loss, recoverable by restart), which argues for 'track/attend' rather than 'act' unless the Splunk Web instance is internet-exposed. Net: prioritize patching for externally reachable Splunk Web deployments; lower urgency for internal-only instances behind access controls. |
| Exploit ScenarioDerived | An unauthenticated attacker with network reachability to Splunk Web sends a single crafted HTTP request to the JavaScript logger endpoint whose headers are not bounded before parsing, exhausting resources and hanging the web interface. Splunk Web then stops responding to all requests and remains down until Splunk Enterprise is restarted, denying analysts and automation access to dashboards, search, and alerting. No public proof-of-concept was identified in the provided data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Splunk Enterprise deployments running Splunk Web in versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16 can be taken offline by a single unauthenticated request to the Splunk Web JavaScript logger endpoint, which parses request headers without any limit and can be driven into an unresponsive state. Recovery requires a full restart of Splunk Enterprise, making this an easy-to-repeat availability attack against any instance whose Splunk Web port is reachable by the attacker. The assessed vector (AV:N/AC:L/PR:N/UI:N, availability-only) is consistent with a low-complexity denial of service; no public exploit code or confirmed active exploitation was identified at time of analysis, and the risk is bounded to service availability with no implied data loss or compromise.
RemediationAI
Upgrade Splunk Enterprise to 10.4.4, 10.2.8, 10.0.11, or 9.4.16 (or later) on the matching release branch; these are vendor-released fixed versions and the only complete remediation. Until the upgrade can be scheduled, reduce reachability of the Splunk Web listener: restrict the Splunk Web port (default 8000/TCP) with host or network firewalls and security groups so only trusted administrative subnets can connect - the trade-off is that administrators and any integrations using Splunk Web must be re-homed onto that trusted path. If an internet-facing or broadly reachable Splunk Web is unavoidable, front it with a reverse proxy that enforces strict request-header count and size limits and drops malformed or oversized header blocks before forwarding, noting that a proxy which blindly relays arbitrary headers provides no protection and adds another component to keep patched. Because a successful attack leaves Splunk Web hung rather than self-healing, monitor for Splunk Web health-check failures and unexpected restarts and treat them as potential exploitation evidence; restarting Splunk Enterprise restores service but does not remove the exposure. Full details and any vendor-supplied workarounds are in advisory SVD-2026-1007 at https://advisory.splunk.com/advisories/SVD-2026-1007.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is CWE-400 (Uncontrolled Resource Consumption) in Splunk Web's HTTP request handling layer, specifically the JavaScript logger endpoint, which accepts and parses client-supplied request headers without enforcing any cap on header count or size before the request is processed. Because header parsing occurs ahead of authentication or routing checks, an unauthenticated remote client can submit one crafted request whose header set exhausts the resources (worker threads, memory, or connection-handling capacity) backing the Splunk Web front end, leaving it unable to answer subsequent requests. The failure mode is persistent rather than transient - the service does not self-recover and stays unavailable until the Splunk Enterprise instance is restarted - which suggests the parsing path blocks or deadlocks a shared component of Splunk Web rather than merely slowing a single request. Affected CPE data identifies the impacted product as splunk_enterprise across all platform variants; only builds below the fixed maintenance levels contain the unbounded header parsing logic.
Know when Splunk gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Single unauthenticated network request reliably hangs Splunk Web, so AV:N/AC:L/PR:N/UI:N; impact is availability-only recoverable by restart, so C:N/I:N/A:H.
Primary rating from Vendor (cisco).
CVSS VectorVendor: cisco
Lifecycle Timeline
2DescriptionCVE.org
In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, an unauthenticated user could send a single crafted request to the Splunk Web JavaScript logger endpoint and cause Splunk Web to stop responding to requests. Splunk Web remains unavailable until Splunk Enterprise is restarted. The vulnerability is possible because Splunk Web does not limit request-header parsing before processing the request.
Executive ViewAI
Splunk Enterprise instances reachable over the network can be forced offline by a single unauthenticated request, disrupting security monitoring and log analysis until a full restart is performed. The condition is trivial to repeat and affects any exposed Splunk Web interface, so teams relying on Splunk for detection and incident response could lose visibility during a critical event. Leadership should prioritize reducing exposure of Splunk Web and preparing for vendor remediation because repeated outages undermine confidence in a core security platform.
No vendor-released patch identified at time of analysis; no public exploit identified at time of analysis. Restrict network access to Splunk Web, disable Splunk Web where not needed, deploy a reverse proxy or WAF with header-size and rate limits, segment Splunk from untrusted networks, and monitor for abnormal requests to the JavaScript logger endpoint.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
Unauthenticated arbitrary file write in Splunk Enterprise (below 10.2.4 and 10.0.7) and Splunk Cloud Platform (below 10.
curl 7.75.0 through 7.76.1 suffers from a use-after-free vulnerability resulting in already freed memory being used when
curl < 7.84.0 supports "chained" HTTP compression algorithms, meaning that a serverresponse can be compressed multiple t
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10, a low-privileged user that does not hold the admin or powe
In Splunk Enterprise versions below 9.0.7 and 9.1.2, Splunk Enterprise does not safely sanitize extensible stylesheet la
In versions of Splunk Enterprise below 9.0.5, 8.2.11, and 8.1.14, and Splunk Cloud Platform below version 9.0.2303.100,
In Splunk Enterprise versions below 8.2.9, 8.1.12, and 9.0.2, an authenticated user can execute arbitrary code through t
When curl < 7.84.0 saves cookies, alt-svc and hsts data to local files, it makes the operation atomic by finalizing the
SQLite 1.0.12 through 3.39.x before 3.39.2 sometimes allows an array-bounds overflow if billions of bytes are used in a
A vulnerability exists in curl <7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Rated high seve
When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data t
EUVD-2026-107663
GHSA-hcwv-2x2x-8285
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB