CVE-2026-76277

Executive Summary

CVE-2026-76277 is an input validation weakness in Splunk Enterprise in which the platform fails to reject native usernames ending with a trailing period before that username is used to derive a per-user directory. An authenticated user holding a role with the edit_user capability can create such a username, causing distinct native accounts to collide on the same per-user configuration data and causing user-management operations to target the wrong account or fail. Affected versions are Splunk Enterprise below 10.4.3, 10.2.7, 10.0.10, and 9.4.15; the flaw maps to CWE-20 and carries a CVSS v3.1 base score of 4.1.

Technical Analysis

The vulnerability is rooted in improper neutralization of input during user-account creation, classified under CWE-20 (Improper Input Validation). According to the NVD description, username validation "does not reject a trailing period before the username is used for a user directory." This means the validation routine and the downstream filesystem/configuration layer disagree about the canonical form of the username.

The mechanism described is a path-canonicalization collision effect:

• A native Splunk username is accepted in a form that ends with a period (e.g., a name whose final character is .).
• The username is then used as, or mapped to, a per-user directory location.
• Because of how the trailing period is handled when that name is resolved into a directory path, two logically distinct usernames can resolve to the same per-user configuration namespace.

The result, per the description, is that "distinct native Splunk usernames share per-user configuration data," and "user-management operations can affect the wrong account or fail." This is a state-confusion / identity-collision condition rather than memory corruption, injection, or remote code execution.

Attack surface and preconditions:

• The attacker must be authenticated and must hold a role that includes the edit_user capability.
• No user interaction is required.
• The attack is network-reachable (AV:N) but requires high privilege (PR:H) and has high attack complexity (AC:H), consistent with the narrow precondition set and the environment-dependent nature of the collision.

Impact to confidentiality, integrity, and availability are each assessed as Low (C:L/I:L/A:L) with scope unchanged (S:U): the flaw does not grant privilege escalation on its own, but it can cause configuration bleed between accounts and misdirect administrative actions.

The precise directory naming convention, the validation code path, and the exact string-normalization behavior are not enumerated in the NVD description; the analysis above is limited to the mechanism the description explicitly states. No function names, endpoints, or file paths are asserted here because none are provided in the source data.

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template is available for CVE-2026-76277. The attack chain below is inferred from the vulnerability class and the NVD description, and does not rely on any fabricated implementation details.

1. Reconnaissance / target identification The adversary first identifies a Splunk Enterprise deployment running an affected version (below 10.4.3, 10.2.7, 10.0.10, or 9.4.15). This is achievable through standard web fingerprinting of the Splunk web interface and version disclosure. The attacker must also determine that their own account holds a role that includes the edit_user capability — an administrative capability explicitly named in the description that governs whether a user can create or modify user accounts.

2. Triggering the flaw Having established an account with edit_user, the attacker creates a native Splunk username that ends with a trailing period. Because username validation does not reject the trailing period before the name is used for a user directory, the creation succeeds. This is the core of the CWE-20 weakness: the input is accepted in a state that the downstream directory-naming logic does not treat as distinct from its canonicalized form.

3. Execution / collision effect Once the malformed username exists, it is used to resolve a per-user directory. Distinct native usernames that should be separate can therefore share per-user configuration data. The attacker does not need a crafted payload in the injection sense; the malformed username itself is the trigger. Any subsequent read or write that flows through that shared configuration namespace operates on the wrong account's data.

4. Post-exploitation impact The observable consequences, again per the description, are that distinct usernames share configuration data and that user-management operations either affect the wrong account or fail. This produces integrity impact (configuration belonging to one account is exposed to or modified via another), limited confidentiality impact (one account's per-user configuration may be observed through the shared namespace), and availability impact (user-management operations may fail). The flaw does not by itself yield privilege escalation; the attacker's effective privilege remains bounded by the role they already hold.

Because no exploit code exists publicly, this scenario is a low-maturity, insider-adjacent or malicious-admin abuse case rather than a remote unauthenticated attack. It is most relevant to environments with delegated user administration, where the edit_user capability has been granted more broadly than strictly necessary.

Impact Assessment

The CVSS v3.1 base score is 4.1 (Medium). The vector CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L indicates:

• Network reachable, but high attack complexity and high privileges required.
• No user interaction.
• Scope unchanged: the exploit affects only the Splunk deployment's own user/configuration space, not beyond its security authority.
• Low confidentiality, integrity, and availability impact.

Business impact is centered on the integrity of identity and configuration data within Splunk Enterprise. Splunk is typically a security operations and log-aggregation platform; per-user configuration frequently holds saved searches, app preferences, dashboard state, alerting configuration, and role-adjacent settings. If two accounts share a per-user configuration namespace, an operator may:

• observe or alter another account's saved objects and preferences,
• have administrative actions (password resets, role assignments, deactivation) applied to the wrong account,
• experience failed user-management operations that complicate incident response and access reviews.

Blast radius is bounded by the population of accounts with the edit_user capability and by the number of colliding usernames created. In environments where user administration is delegated to many roles, or where self-service account operations are exposed, the exposure grows. However, the required privileges and high complexity keep this from being a mass-exploitation candidate. The EPSS score is 0.00183 (7.2nd percentile), and the CVE is not listed in CISA KEV, indicating no observed exploitation in the wild as of the data provided.

Because Splunk is a security-monitoring platform, any integrity issue in its user and configuration model also carries a secondary risk: misdirected configuration could degrade log onboarding, alert delivery, or audit fidelity, indirectly affecting detection coverage.

Detection Guidance

Sigma Rule

title: Splunk Native Username Created With Trailing Period (CVE-2026-76277)
id: 6f2c1d9a-7b4e-4c33-9a11-2f0d5c7e8b41
status: experimental
description: Detects creation or modification of a Splunk native user account whose username ends with a period, which can cause per-user configuration collisions per CVE-2026-76277.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-76277
author: valtersit.com
date: 2026-01-01
tags:
  - attack.persistence
  - attack.t1078
  - cve.2026.76277
logsource:
  product: splunk
  service: audit
detection:
  selection_action:
    action:
      - 'edit_user'
      - 'create_user'
      - 'new_user'
  selection_trailing_period:
    user|endswith: '.'
  condition: selection_action and selection_trailing_period
fields:
  - user
  - action
  - src_ip
  - actor
falsepositives:
  - Legitimate usernames with unusual punctuation that are subsequently corrected
level: medium

YARA Rule

rule CVE_2026_76277_Splunk_TrailingPeriod_Username
{
    meta:
        author = "valtersit.com"
        description = "Detects Splunk authentication or configuration artifacts referencing native usernames ending with a trailing period (CVE-2026-76277)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-76277"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $splunk = "splunk" nocase
        $users_cfg = "passwd" nocase
        $auth_cfg = "authentication.conf" nocase
        // usernames ending with a period inside common config/token separators
        $trailing_period = /(name|username|user)\s*[=:]\s*[A-Za-z0-9_.\-]+\.\s*$/ nocase

    condition:
        filesize < 5MB and
        ($users_cfg or $auth_cfg) and
        $trailing_period
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-76277 Splunk native username with trailing period submission"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/services/authentication/users"; nocase; http.request_body; content:"name="; nocase; pcre:"/name=[^&]*\.(?:&|$)/Ri"; reference:cve,2026-76277; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-76277; classtype:attempted-admin; sid:202676277; rev:1;)

Elastic Detection

sequence by user.name with maxspan=5m
  [ authentication where event.action == "user-created" or event.action == "user-updated" ]
  [ authentication where endsWith(user.name, ".") and event.action in ("user-created", "user-updated", "user-deleted") ]

Splunk SPL Query

index=_audit action IN ("edit_user","edit_user_roles","create_user","new_user")
| eval suspicious_trailing_period=if(match(user,"\.$"),1,0)
| where suspicious_trailing_period=1
| table _time, user, action, src, actor, info
| sort - _time

Wazuh OSSEC Rule

<group name="splunk,web,">
  <rule id="100877" level="10">
    <decoded_as>json</decoded_as>
    <field name="action">edit_user|create_user|new_user</field>
    <field name="user" type="pcre2">\.$</field>
    <description>Splunk native user created or edited with a trailing period username (CVE-2026-76277)</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>cve_2026_76277,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations

• Restrict the edit_user capability to the smallest possible set of accounts and roles. Per the vendor documentation referenced by NVD ("Define roles on the Splunk platform with capabilities"), remove edit_user from any role that does not strictly require delegated user administration.
• Audit existing native Splunk accounts for usernames ending with a period and remediate any found, since such names are the necessary precondition for the collision.
• Review user-management activity for misdirected or failed account operations, which the description identifies as the observable symptom.
• Because the flaw affects per-user configuration separation, verify that no two accounts are resolving to a shared configuration namespace by reviewing per-user configuration state for unexpected overlap.

2. Patch / upgrade steps

• Upgrade Splunk Enterprise to 10.4.3 or later, 10.2.7 or later, 10.0.10 or later, or 9.4.15 or later, per the fixed versions referenced by the NVD description. These are the versions in which the trailing-period validation gap is addressed.
• Track the Splunk advisory for CVE-2026-76277 for the authoritative fixed build list and any interim guidance before scheduling the upgrade.
• No vendor workaround is published in the provided data (Workarounds: N/A); the capability restriction above is the practical compensating control until the upgrade is applied.

3. Long-term hardening

• Enforce a naming policy for native Splunk accounts that normalizes and rejects trailing periods, whitespace, and other characters that create ambiguous directory names.
• Integrate Splunk account provisioning with a central identity source and apply input validation at the provisioning layer so malformed names never reach the platform.
• Periodically reconcile the Splunk user list against the authoritative identity source to catch orphaned, duplicated, or malformed accounts.
• Monitor the audit index for user-management failures, which may indicate a collision condition.
• Maintain a patch cadence that applies Splunk maintenance releases promptly, since user and role subsystems are security-relevant infrastructure.

References

• NVD — CVE-2026-76277: https://nvd.nist.gov/vuln/detail/CVE-2026-76277
• Splunk documentation — Set up native Splunk authentication: https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/use-the-native-splunk-platform-authentication-scheme/set-up-native-splunk-authentication
• Splunk documentation — Define roles on the Splunk platform with capabilities: https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities
• CWE-20 — Improper Input Validation: https://cwe.mitre.org/data/definitions/20.html
• MITRE ATT&CK T1078 — Valid Accounts: https://attack.mitre.org/techniques/T1078/

Exploit-in-the-wild evidence: None. CISA KEV: NO. EPSS: 0.00183 (7.2nd percentile). No public PoC, exploit code, or Nuclei template is available for this CVE, and no threat actor campaign has been associated with it in the provided data.