Splunk's SVD-2026-1001 fixes log injection CVE-2026-76267 in O11y Cloud app REST API

What happened

Splunk published security advisory SVD-2026-1001 on 7 October 2026, covering a batch of vulnerabilities in Splunk Enterprise. One entry in that batch, CVE-2026-76267, is a medium-severity flaw with a CVSSv3.1 base score of 4.3, filed under CWE-117, the class for improper neutralization of output written to logs. According to a dev.to analysis that reads the advisory as a version matrix, the CVE record was assigned by Cisco PSIRT on behalf of Splunk and published the same day, and it names the REST API as the affected module.

Which versions are affected

The advisory maps Splunk Enterprise across four release branches and names a fix for each. For this CVE the position is:

• Branch 10.4: versions 10.4.0 through 10.4.2 are affected, fixed in 10.4.3.
• Branch 10.2: versions 10.2.0 through 10.2.6 are affected, fixed in 10.2.7.
• Branch 10.0: versions 10.0.0 through 10.0.9 are affected, fixed in 10.0.10.
• Branch 9.4: not affected by this CVE, even though the batch lists a 9.4.15 fix for its other issues.

The dev.to author's key observation is that the 9.4 fix line belongs to the wider batch, not to this defect. Reading the advisory as a table of branches and fixes, rather than as prose, stops administrators from treating every line as equally pressing.

How the flaw works

According to Splunk's description, the attack requires an account whose role carries the read_o11y_content capability. Through the REST API, such a user can plant forged entries in the application log. The vulnerable component is the Splunk App for Splunk O11y Cloud, which writes user-supplied SignalFlow content into the log without neutralizing it first. Two preconditions follow: the attacker needs nothing beyond valid credentials and a reachable REST API, and the app has to be installed on the instance. That second condition also explains why the CVE record points at the REST API while the advisory points at the app.

Severity and exposure

The published vector, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, describes a network-reachable flaw with low attack complexity, low privileges required and no user interaction. Confidentiality and availability are untouched; the integrity impact is low and confined to the log. In plain terms this is log forging — an authenticated user can fabricate entries that the platform records as if they were genuine.

For a sense of scale, the dev.to write-up cites a ZoomEye search that returned 114,223 assets matching Splunk Enterprise on 10 October 2026. That number says nothing about which branch any exposed instance runs, and a query for the CVE itself returned zero because scanning services have not indexed it against specific assets yet. Reliable version data has to come from internal inventory.

What administrators should do

Remediation is a version bump: move to 10.4.3, 10.2.7 or 10.0.10 depending on the branch, or a later release. No additional mitigation is recorded for this CVE. The dev.to analysis suggests a practical sequence:

• Record the branch and exact version of every instance, including search head cluster members, checking the version reported by the running product rather than a deployment manifest, since upgrades can leave some artifacts behind.
• Confirm the O11y Cloud app is present before treating an instance as in scope.
• Handle cluster members with the usual rolling upgrade discipline, and document each move from source version to target version, because the same matrix applies to the other 21 CVEs in the batch.
• Verify by confirming the running version on each host after the upgrade, not only the package version on disk.

The write-up also points to coordinated advisories from CERT-FR and the Dutch NCSC.

Why it matters

A 4.3 score invites postponement, but the context argues against it. Splunk Enterprise is frequently the system of record for security monitoring, and forged entries in that system corrupt the evidence base analysts and responders depend on — a fabricated event can misdirect an investigation or mask real activity. The bar for exploitation is low: any credentialed user with the right role can act, with little in the way of exploit complexity.

The advisory's batch structure also changes the economics of the work. The same version inventory supports triage for all 22 CVEs, so the one-off effort of a clean branch-and-version census pays off repeatedly. And the broader lesson generalises: vendor advisories that arrive in batches are most actionable when parsed as a matrix of versions and fixes, which makes both over-patching and silent under-patching easier to avoid.