CVE-2026-76405 in On-Call
Summary
by MITRE • 08/19/2026
In Splunk On-Call (VictorOps) app versions below 1.0.43 on Splunkbase, a user who does not hold the "admin" or "power" Splunk roles could read a partially masked Application Programming Interface (API) key from the App Key Value Store (KV Store). The exposure is possible because the Splunk On-Call (VictorOps) app does not fully mask the API key before storing it in a KV Store collection that the user can read. For more information see About the app key value store (https://help.splunk.com/en/data-management/splunk-enterprise-admin-manual/9.2/administer-the-app-key-value-store/about-the-app-key-value-store) in the Splunk documentation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in Splunk On-Call, formerly known as VictorOps, versions prior to 1.0.43 represents a significant information disclosure flaw rooted in improper access control and insufficient data masking within the application's integration with Splunk Enterprise infrastructure. This issue specifically affects users who lack elevated privileges such as admin or power roles on the underlying Splunk platform. The core of the problem lies in how the application handles sensitive credentials, particularly API keys required for communication with external services like VictorOps. When these credentials are stored within a Splunk App Key Value Store (KV Store), which is designed to securely manage app-specific secrets, the implementation fails to apply complete obfuscation or masking before persistence. Consequently, while the system may attempt to hide parts of the key from standard views, the underlying data structure retains enough information that allows unauthorized users with read access to specific KV store collections to reconstruct or partially retrieve the sensitive API key.
From a technical perspective, this flaw aligns closely with CWE-200: Exposure of Sensitive Information to an Unauthorized Actor and CWE-798: Use of Hard-coded Credentials if the masking logic is bypassed entirely in certain contexts. The vulnerability exploits the trust model inherent in Splunk's KV Store mechanism, which assumes that applications will correctly enforce security boundaries when writing data. By not fully sanitizing or encrypting the API key at rest within a collection accessible to lower-privileged users, the application creates an attack vector where credential theft becomes feasible without requiring privilege escalation on the main Splunk instance. This is particularly dangerous because KV stores are often used for configuration and integration purposes, meaning they may be exposed through various administrative interfaces or APIs that do not strictly enforce role-based access control at the individual key level.
The operational impact of this vulnerability is severe due to the nature of API keys in enterprise environments. An attacker who successfully exploits this flaw can obtain a partially masked but potentially usable API key for the Splunk On-Call integration. Depending on the specific implementation details and the extent of masking, an attacker might be able to use brute-force techniques or pattern analysis to recover the full secret if the unmasked portion is small enough. Possession of a valid API key allows unauthorized access to the associated VictorOps account, potentially leading to alert manipulation, denial of service by flooding systems with fake alerts, or further lateral movement within the organization's monitoring infrastructure. This undermines the integrity and availability of critical incident response workflows that rely on accurate and secure notification channels.
Mitigation strategies primarily involve upgrading the Splunk On-Call app to version 1.0.43 or later, where this masking issue has been addressed by the vendor. In environments where immediate patching is not possible, administrators should review KV store permissions and ensure that collections containing sensitive credentials are restricted to only those users with explicit admin-level access rights. Additionally, implementing strict role-based access control policies within Splunk Enterprise can limit which roles have read access to specific data models or key-value stores. Regular auditing of API keys and rotating them periodically reduces the window of opportunity for attackers who might capture partial secrets through this vulnerability. Monitoring logs for unusual access patterns to KV store collections can also help detect potential exploitation attempts in real-time, aligning with ATT&CK technique T1530: Data from Cloud Storage Object or T1078: Valid Accounts if the attacker uses stolen credentials to maintain persistence.