CVE-2026-76277 in Splunkinfo

Summary

by MITRE • 10/07/2026

In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user that holds a role with the edit_user capability could create a native Splunk username that ends with a period. The vulnerability is possible because username validation does not reject a trailing period before the username is used for a user directory. This can cause distinct native Splunk usernames to share per-user configuration data, and user-management operations can affect the wrong account or fail. For more information see 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) and 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) in the Splunk documentation.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 10/07/2026

In versions of Splunk Enterprise prior to 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a critical input validation flaw exists within the native authentication subsystem that permits users with edit_user capabilities to register usernames containing trailing periods. This vulnerability stems from an insufficient sanitization mechanism in the user creation workflow, where the system fails to reject or normalize username strings ending with a dot character before they are committed to the internal user directory. The absence of strict alphanumeric and special character filtering for this specific edge case allows administrators or privileged users to bypass standard naming conventions that typically enforce clean identifiers without trailing punctuation marks.

The operational impact of this flaw is significant because it leads to ambiguity in identity resolution within the Splunk platform. When a username with a trailing period is created, the system may treat distinct usernames as identical during certain configuration lookups due to how underlying file systems or database backends handle string normalization. This results in per-user configuration data being shared between accounts that should remain isolated. Consequently, actions taken by one user can inadvertently affect another account if their identifiers are resolved to the same internal entity, leading to potential unauthorized access to sensitive configurations or unintended modification of security settings belonging to other users.

From a security architecture perspective, this issue represents a classic case of improper input validation where edge cases in string handling lead to identity confusion. It aligns with CWE-20 Improper Input Validation and specifically relates to CWE-643 Improper Mitigation for Canonicalization Problems since the system fails to properly canonicalize or reject non-standard username formats before processing. In terms of attack vectors, this could be leveraged in conjunction with other vulnerabilities to escalate privileges or disrupt service availability by corrupting user-specific data stores. It also touches upon ATT&CK technique T1078 Valid Accounts if an attacker uses a crafted account name to bypass monitoring tools that rely on strict username matching for audit trails.

To mitigate this risk, organizations running affected versions of Splunk Enterprise must upgrade immediately to version 10.4.3 or later where the validation logic has been corrected to reject usernames with trailing periods. For environments unable to patch instantly, administrators should implement rigorous role-based access control policies that restrict edit_user capabilities only to trusted senior personnel and actively audit user creation events for anomalies such as unusual characters in identifiers. Additionally, regular reviews of user directories can help identify any previously created accounts with malformed names that could be exploited to manipulate configuration data or impersonate other users within the platform.

Responsible

Cisco

Reservation

08/19/2026

Disclosure

10/07/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Want to stay up to date on a daily basis?

Enable the mail alert feature now!