Splunk Enterprise CVE-2026-76267

Exploitation requires an authenticated Splunk account assigned a role that grants the read_o11y_content capability, and the deployment must have the Splunk App for Splunk O11y Cloud present/enabled, since that component performs the unneutralized write to the app log. The attack is carried out over the REST API using user-supplied SignalFlow content. Limiting factors: the attacker must already hold this specific privileged capability (not a default low-privilege or anonymous user), impact is confined to integrity of the app log with no confidentiality or availability effect, and only Splunk Enterprise versions below 10.4.3 / 10.2.7 / 10.0.10 are affected (9.4.x explicitly not affected).

This is a low-severity, authenticated log-injection issue (CWE-117) that signals are consistent about being low real-world priority. The CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, base 4.3) shows network reach but requires existing authenticated privileges (PR:L - specifically the read_o11y_content capability) and yields only limited integrity impact with no confidentiality or availability loss. No EPSS score was provided in the input, and there is no CISA KEV listing and no public exploit identified at time of analysis, so there is no evidence of active or imminent exploitation. SSVC-style framing: exploitation is not observed, technical impact is partial (log integrity only), and automation would gain little since the attacker must already hold a privileged Splunk role. No signals conflict - all point the same direction. The practical concern is integrity/trustworthiness of the app log (forged entries could mislead investigations or poison downstream log analytics), not system compromise. This is a genuine but minor hardening fix rather than an emergency; patch in normal maintenance cycles.

An authenticated Splunk user who already holds a role granting the read_o11y_content capability sends crafted SignalFlow content through the REST API; because the Splunk App for Splunk O11y Cloud does not neutralize this input before writing it, the attacker injects forged or misleading entries into the app log. No public exploit code is identified, and exploitation is bounded by the need for that specific privileged capability.