Splunk Enterprise CVE-2026-76277

Exploitation requires an authenticated user who holds a role granting the edit_user capability on Splunk Enterprise using the native Splunk authentication scheme, and the actor must create a native username that ends with a trailing period. The core limiting factor is the high privilege prerequisite (edit_user is an administrative user-management capability), which confines abuse to trusted/insider operators or a compromised admin-level account; external LDAP/SAML-only deployments that do not use native usernames are not in scope. Impact is further bounded because it manifests as configuration-data collisions and misdirected or failing user-management operations rather than code execution or direct data exfiltration. Affected: Splunk Enterprise below 10.4.3, 10.2.7, 10.0.10, and 9.4.15.

This is a low-priority, low-real-risk issue despite affecting a widely deployed enterprise product. The CVSS 3.1 vector (CVSS:3.1/AV:N/AC:H/PR:H/UI:N, base 4.1 MEDIUM) is internally consistent with the description: exploitation requires an already-privileged user holding the edit_user capability (PR:H), and the high attack complexity (AC:H) reflects the narrow, non-deterministic condition of crafting a username with a trailing period that collides with another user's directory. No EPSS score, CISA KEV entry, POC, or SSVC data was provided in the input. Exploitation status is therefore 'no public exploit identified at time of analysis.' All three impact metrics are only Low (C:L/I:L/A:L), consistent with the described effect - distinct accounts sharing per-user config data and user-management operations affecting the wrong account or failing - rather than full compromise. The vulnerability is essentially a privilege-boundary/data-integrity defect usable almost exclusively by a trusted administrator-level role, so the realistic threat is insider misuse or accidental collision rather than external attack. The CVSS data and the description do not conflict.

A user granted a role with the edit_user capability creates a native Splunk username ending in a trailing period (e.g. 'analyst.'), which username validation fails to reject. Because the stored username maps to a user directory that collides with another account, the two distinct usernames share per-user configuration data, and subsequent user-management actions silently affect the wrong account or fail. No public exploit code was identified in the provided data.