CVE-2026-76267

Executive Summary

CVE-2026-76267 is a log injection (log forging) vulnerability in the Splunk App for Splunk O11y Cloud, shipped with Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10. An authenticated user holding a role that includes the read_o11y_content capability can write forged entries into the application log via the Representational State Transfer (REST) API, because user-supplied SignalFlow content is not neutralized before being written to the app log. The impact is limited to integrity of log data (CVSS 4.3, I:L only), with no direct confidentiality or availability impact, but forged log entries can corrupt auditing, monitoring, and downstream detection pipelines that trust Splunk's own internal logs.

Technical Analysis

The vulnerability class is CWE-117, Improper Output Neutralization for Logs — commonly referred to as log injection or log forging. The root cause described by the vendor is that the Splunk App for Splunk O11y Cloud "does not neutralize user-supplied SignalFlow content before writing it to the app log." SignalFlow is Splunk's streaming analytics query language used by the Observability Cloud (O11y) integration. When a user submits SignalFlow content that is subsequently written into a log record, characters such as newlines, carriage returns, or other control/record-separator sequences are not escaped or stripped. Because log records are delimited by newlines, an attacker who can embed newline characters in the logged value can cause the logging subsystem to emit what appears to be one or more additional, attacker-controlled log records.

The attack surface is the Splunk REST API. The description explicitly states that the forged entries are injected "through the Representational State Transfer (REST) API," and that the triggering capability is read_o11y_content. This means the vulnerability is reachable by an authenticated principal with a low-privilege role — it is not pre-authentication. The read_o11y_content capability name indicates an operations that is nominally a read-style capability for Observability content, which lowers the privilege barrier: an operator, analyst, or integration account granted this capability for legitimate O11y dashboarding purposes can also reach the vulnerable write-to-log path.

Two properties of the flaw constrain and shape the threat:

• The injected content is written to the application log, not to indexed event data. This is significant because the app log is exactly the artifact that administrators and SOC tooling rely on for platform-internal auditing (e.g., who queried what, search activity, configuration changes log lines). Poisoning it undermines the trust anchor used for Splunk's own self-monitoring rather than the data Splunk ingests as log sources.
• The scope of the write is limited. Per the CVSS vector (S:U, unchanged), the vulnerable component does not confer privileges or impact beyond its security authority — the attacker gains no code execution, no file write beyond the log stream, and no lateral movement through this flaw by itself.

The CVSS v3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N maps to a score of 4.3 and is internally consistent: network-reachable (AV:N), no special preconditions beyond credentials (AC:L), requires low privileges (PR:L), no user interaction (UI:N), scoped impact (S:U), zero confidentiality, low integrity, zero availability. The low integrity impact reflects that log content is the only modified asset and that recovery is a matter of log hygiene, not data restoration.

Splunk explicitly notes that 9.4.x branches are not affected, which narrows the affected population and suggests the vulnerable code path was introduced in the 10.0 line (with the described fix points at 10.0.10, 10.2.7, and 10.4.3). No public proof-of-concept, exploit code, or Nuclei template is known, and EPSS is 0.00166 (approximately the 5.3rd percentile), indicating the community assigns a low probability of near-term exploitation in the wild. The patch confidence here is 0/4: no patch evidence was recovered from tracked sources, so the version boundaries above should be treated as the vendor-stated fixed releases rather than as a confirmed, independently verified remediation artifact.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class and the information in the NVD description. No function names, API paths, or parameter names are asserted beyond those stated by the vendor.

1. Reconnaissance / target identification. The attacker identifies an internet- or intranet-exposed Splunk Enterprise instance running an affected 10.x release (a version below 10.4.3, 10.2.7, or 10.0.10) with the Splunk App for Splunk O11y Cloud installed and the O11y REST API surface reachable. Banner, login page, or API response fingerprints can confirm version and app presence. The attacker needs a valid account, or must obtain one, whose role includes read_o11y_content — a capability plausibly granted to monitoring and dashboarding users, so credential reuse or an over-provisioned service account is a realistic path.

2. Triggering the flaw class. The attacker issues a REST API request that carries SignalFlow content. Because the app does not neutralize the supplied content before writing it to the app log, the attacker embeds control characters — most importantly newline/carriage-return sequences — inside the SignalFlow content. The logging subsystem honors those sequences as record delimiters, so a single request produces additional, forged log records that the attacker fully controls in content.

3. Payload / execution method (vulnerability-class level). The "payload" is not executable code; it is fabricated log text. Typical forged entries claim events such as successful or failed authentications, configuration changes, or administrative actions attributed to other users or source addresses. The objective of log forging is to create plausible deniability, misattribute activity, or plant content that downstream log consumers (SIEM rules, alerting, compliance exports) will treat as genuine platform telemetry. Attackers may also target log parsers that process the app log, attempting denial of logging or downstream parser confusion — though the CVSS vector assigns no availability impact, so parser disruption is opportunistic rather than guaranteed.

4. Post-exploitation impact. The attacker gains the ability to pollute the platform's own audit trail. Real attacker activity elsewhere in the environment can be masked by inserting noise or by overwriting narrative context; conversely, forged entries can be used to frame a legitimate user or system. Because the app log frequently feeds monitoring, alerting, and forensic review, corrupted log integrity can degrade incident response confidence. No privilege escalation, code execution, or broader system compromise is conferred by this CVE alone.

Impact Assessment

Business impact is concentrated in log and audit integrity, which is the raison d'être of an enterprise SIEM. CVSS v3.1 scores this 4.3 (Medium) with the breakdown: Confidentiality None (0.0), Integrity Low (0.1 contribution to the composite — I:L), Availability None. The S:U scope means the vulnerability's effects stay within the Splunk O11y app component; the attacker cannot leverage it to affect resources outside that security authority. PR:L confirms an authenticated low-privilege account is required, and UI:N means no victim interaction or trickery is needed — exploitation is direct once the required capability is held.

Blast radius is bounded by the fact that only the app log is written. However, in practice this can extend indirectly: any SOC workflow, compliance control, or automation rule that ingests the Splunk app log inherits poisoned data. Detection content tuned to the app log may false-positive or false-negative as a result. Regulatory frameworks that require trustworthy audit logs (e.g., logging controls under common compliance regimes) could be undermined in a targeted attack, even though the raw CVSS score is modest. Given EPSS 0.00166 and no KEV listing, mass exploitation is not expected; the most credible scenarios are insider-threat-adjacent, red-team persistence-of-noise, or an attacker who already holds credentials and wants to degrade forensic reliability.

Detection Guidance

Detection for this CVE is challenging because the vulnerability manifests as anomalous content inside legitimate logs rather than as an obviously malicious network signature. Defenses therefore combine (a) monitoring of the REST API access path by principals holding read_o11y_content, (b) structural anomaly detection on the app log itself (unexpected fields, embedded control characters, malformed records), and (c) correlation of log-write events with the submitting principal. The rules below are illustrative and must be tuned to the local Splunk deployment, app log sourcetype naming, and field extraction in use.

Sigma Rule

title: Suspected Splunk O11y App Log Injection via REST API (CVE-2026-76267)
id: 8f2a4c11-7b3e-4d92-9c5a-762670000001
status: experimental
description: Detects REST API access involving O11y content by low-privileged principals, and app
  log records containing embedded control characters indicative of log forging.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-76267
author: valtersit.com Threat Intelligence
date: 2026/01/01
tags:
  - attack.t1565.001
logsource:
  product: splunk
  service: app
detection:
  selection_api:
    cs-uri-stem|contains:
      - '/services/'
  selection_capability:
    user|contains: 'o11y'
  selection_control_chars:
    message|contains:
      - '\\r'
      - '\\n'
  condition: selection_api and selection_capability and selection_control_chars
falsepositives:
  - Legitimate multi-line SignalFlow queries logged verbatim
  - Application debug logging
level: medium

YARA Rule

rule CVE_2026_76267_Splunk_O11y_LogInjection
{
    meta:
        author = "valtersit.com Threat Intelligence"
        description = "Detects forged or control-character-laden entries in Splunk app logs consistent with CVE-2026-76267"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-76267"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $sig1 = "SignalFlow" ascii nocase
        $sig2 = "read_o11y_content" ascii nocase
        $sig3 = "o11y" ascii nocase
        $crlf = { 0D 0A }
        $ctrl = { 0A 0A }

    condition:
        (
            any of ($sig1, $sig2, $sig3)
        )
        and
        (
            #crlf > 3 or #ctrl > 3
        )
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-76267 Possible Splunk O11y Log Injection via REST API"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/services/"; http.uri; content:"o11y"; nocase; http.header; content:"Authorization"; content:"|0d 0a|"; within:2048; classtype:attempted-user; reference:cve,2026-76267; sid:7626701; rev:1;)

Elastic Detection

sequence by user.name with maxspan=5m
  [ network where process.name : "*" and url.path : "/services/*" and url.path : "*o11y*" ]
  [ file where file.name : "*.log" and file.path : "*splunk*app*" and file.name : "*o11y*" ]

Splunk SPL Query

index=_internal sourcetype=splunkd_ui_access OR sourcetype=splunk_web_access
| where match(uri_path, "(?i)/services/.*o11y")
  AND match(user, "(?i)")
| stats count min(_time) as firstTime max(_time) as lastTime values(uri_path) as paths by user, src
| where count > 5

| tstats count from datamodel=Authentication where Authentication.user="*" by _time, Authentication.user, Authentication.src

Note: the definitive detection is on the app log content. Search the O11y app log sourcetype for records containing embedded CR/LF or unexpected field counts, then pivot to the authenticated principal via _internal REST access data. Replace index=_internal and the sourcetype names with the deployment-local equivalents.

Wazuh OSSEC Rule

<group name="splunk,web,attack">
  <rule id="100762" level="6">
    <if_sid>31100</if_sid>
    <field name="url">/services/.*o11y</field>
    <field name="method">POST|PUT</field>
    <description>CVE-2026-76267: Splunk O11y REST API content submission by authenticated user - potential log injection attempt</description>
    <mitre>
      <id>T1565.001</id>
    </mitre>
    <group>log_injection,data_manipulation,</group>
  </rule>

  <rule id="100763" level="8">
    <if_sid>100762</if_sid>
    <regex type="pcre2">(?i)(\r|\n|%0a|%0d).*?(SignalFlow|o11y)</regex>
    <description>CVE-2026-76267: Control characters detected in O11y SignalFlow submission - likely log forging payload</description>
    <mitre>
      <id>T1565.001</id>
    </mitre>
    <group>log_injection,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix URL or workaround was supplied in the intelligence data; the fixed version boundaries cited throughout this report come from the NVD description and require verification against Splunk's official advisory before operational use.

1. Immediate mitigations (compensating controls, applied now):

   • Reduce the population of accounts holding read_o11y_content. Treat this capability as administrative-adjacent: audit which roles include it and remove it from general analyst, dashboard, or integration accounts that do not strictly need O11y content access.
   • Enforce least privilege and strong, unique credentials for any account with the capability; require MFA for interactive logins.
   • Restrict network reachability to the Splunk REST API (management port and web port) using firewall rules, reverse proxies, or Splunk's own IP allowlisting, so that only trusted management networks can reach the API surface.
   • Forward the Splunk app log (O11y) to an immutable, independently controlled log sink (a separate syslog/WORM destination or a separate logging cluster) so that forged entries can be compared against a clean copy and integrity can be attested.
   • Add integrity monitoring on the app log — e.g., alert on records with embedded control characters, unusual field counts, or anomalies in write rate.

2. Patch / upgrade steps:

   • The NVD description identifies fixed behavior in Splunk Enterprise 10.4.3, 10.2.7, and 10.0.10. Upgrade affected 10.x deployments to the corresponding fixed release on the deployed maintenance branch, or to the latest available 10.4.x.
   • Validate before upgrading that the Splunk App for Splunk O11y Cloud is updated in lockstep, since the impacted component is the app, not merely the core server.
   • Because patch confidence is 0/4 (no independently corroborated patch evidence in tracked sources), confirm the fixed versions and any additional hotfixes directly against Splunk's official security advisory and release notes before relying on the upgrade as sole remediation.
   • Splunk Enterprise 9.4.x is not affected; no action is required on that branch for this specific CVE.

3. Long-term hardening:

   • Implement and continuously monitor a formal capability-to-role mapping; flag any role that combines an O11y content capability with log-write authority.
   • Treat platform-internal logs as a high-value integrity asset: ship them off-host, hash/chain them, and periodically reconcile.
   • Add log-injection awareness to secure coding review for any custom app that writes user-supplied query language (SignalFlow or otherwise) into logs — escaping newline/CR and control characters before logging is the standard CWE-117 remediation.
   • Maintain an asset inventory that ties app versions to official advisories so that future Splunk O11y fixes are applied promptly.

References

• NVD — CVE-2026-76267: https://nvd.nist.gov/vuln/detail/CVE-2026-76267
• Splunk Security Advisories portal: https://advisory.splunk.com/
• Splunk Enterprise release notes / download page (fixed versions 10.4.3, 10.2.7, 10.0.10): https://www.splunk.com/en_us/download/splunk-enterprise.html
• CWE-117 — Improper Output Neutralization for Logs: https://cwe.mitre.org/data/definitions/117.html
• MITRE ATT&CK T1565.001 — Stored Data Manipulation: https://attack.mitre.org/techniques/T1565/001/

Threat actor campaigns / exploit-in-the-wild evidence: none available. CVE-2026-76267 is not listed in CISA KEV, no public PoC or exploit code is known, no Nuclei template exists, and EPSS is 0.00166 (5.3rd percentile), indicating a low assessed likelihood of near-term exploitation. All detection content above is defensive-inference and requires local tuning and validation.