CVE-2026-76391 in AI Toolkit
Summary
by MITRE • 08/20/2026
In Splunk AI Toolkit versions below 6.0.0, a user who does not hold the "admin" or "power" Splunk roles could run searches with system-level privileges, access all relevant data, affect system integrity, and read or delete search jobs belonging to other users through Agent Run History. The improper privilege management is possible because the Agent Run History handler replaces the calling user session key with a system authentication token before it performs search operations. For more information see AI Toolkit Agent Launchpad (https://help.splunk.com/en/splunk-enterprise/apply-machine-learning/use-ai-toolkit/6.0.0/ai-toolkit-connections-containers-and-agents/ai-toolkit-agent-launchpad) in the Splunk documentation.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in Splunk AI Toolkit versions prior to 6.0.0 represents a critical failure in access control mechanisms, specifically classified under CWE-269 Improper Privilege Management. This flaw allows users with minimal or no administrative privileges to escalate their rights within the Splunk Enterprise environment. The core technical issue resides in the Agent Run History handler, which is responsible for managing and displaying records of agent executions. When a user interacts with this feature, the system incorrectly replaces the calling user's session key with a system-level authentication token before executing search operations. This substitution effectively bypasses standard role-based access controls, granting the requesting user the same level of authority as an administrator or power user, despite lacking those specific roles in the Splunk configuration.
The operational impact of this vulnerability is severe and multifaceted. By obtaining system-level privileges through this flaw, a malicious actor can execute searches that are normally restricted to high-privileged accounts. This capability allows the attacker to access sensitive data across the entire platform, including information intended for other users or protected by strict data isolation policies. Furthermore, the ability to affect system integrity means an attacker could potentially modify configurations or disrupt normal operations. The vulnerability also enables lateral movement and disruption of service, as attackers can read or delete search jobs belonging to other users via the Agent Run History interface. This not only compromises confidentiality but also impacts availability and accountability within the Splunk environment.
From a threat modeling perspective, this behavior aligns with ATT&CK techniques related to privilege escalation and unauthorized access. The exploitation of system tokens by lower-privileged entities is a classic indicator of broken authentication logic that adversaries can leverage to gain deeper footholds in an organization's infrastructure. The specific mechanism described highlights how improper handling of session contexts during API or internal handler calls can lead to significant security breaches. It underscores the importance of ensuring that privilege escalation paths are rigorously tested and that system tokens are never exposed to user-controlled inputs without proper validation checks against role permissions.
To mitigate this vulnerability, organizations running Splunk AI Toolkit must upgrade immediately to version 6.0.0 or later, where these access control issues have been addressed by the vendor. Until an upgrade is performed, administrators should monitor for unusual search activities originating from low-privileged accounts and restrict access to the Agent Run History feature if possible through network-level controls or role restrictions that limit visibility of this specific interface. Additionally, implementing strict monitoring on system token usage can help detect attempts to exploit similar flaws in other components. Regular audits of user roles and permissions are essential to ensure that no unnecessary privileges are assigned, reducing the potential blast radius should such vulnerabilities be discovered in future updates.