CVE-2026-51904 in SuperAGI
Summary
by MITRE • 10/02/2026
SuperAGI up to v0.0.14 contains an improper access control vulnerability in the agent execution controller. In affected source snapshots, create_agent_execution and create_agent_run in superagi/controllers/agent_execution.py accept a caller-supplied agent_id and fail to verify that the referenced agent belongs to the authenticated user's organization. A remote authenticated attacker from one organization can create or start execution records for agents owned by another organization through /agentexecutions/add or /agentexecutions/add_run.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in SuperAGI versions up to 0.0.14 represents a critical failure in multi-tenant isolation, specifically manifesting as an improper access control flaw within the agent execution controller logic. This issue stems from insufficient validation of ownership relationships between authenticated users and the resources they attempt to manipulate. In typical enterprise-grade artificial intelligence platforms or automated agent frameworks, strict separation of duties and data is paramount to ensure that one tenant cannot interfere with another's operations. The specific code paths involved are located in superagi/controllers/agent_execution.py, where two primary endpoints facilitate interaction with agents: create_agent_execution for initiating new execution records and create_agent_run for starting the actual run process. Both functions accept an agent_id parameter directly from caller-supplied input without performing a necessary integrity check to verify that this specific agent ID is associated with the organization of the currently authenticated user.
From a technical perspective, the root cause lies in the absence of authorization middleware or explicit checks within these controller methods. When a request reaches /agentexecutions/add or /agentexecutions/add_run, the system trusts the provided agent_id as valid for the current context without cross-referencing it against an organizational ownership table or verifying that the user has permissions to execute actions on that specific resource ID. This design oversight allows any authenticated user who possesses a valid session token to arbitrarily specify an agent identifier belonging to a different organization. By doing so, the attacker bypasses logical access controls that are typically enforced at the database query level or through dedicated authorization layers, effectively treating all agents as globally accessible within the scope of execution commands rather than restricting them to their respective organizational boundaries.
The operational impact of this vulnerability is severe for organizations relying on SuperAGI for automated workflows and AI-driven tasks. An attacker can force the execution of agents owned by other tenants, potentially leading to unauthorized consumption of computational resources such as API calls, processing power, or data access privileges associated with those external agents. If these agents have permissions to interact with sensitive internal systems, databases, or third-party services, the attacker could indirectly trigger actions that compromise confidentiality, integrity, or availability for another organization. This scenario constitutes a clear violation of multi-tenant security principles and can result in significant financial loss due to resource abuse, as well as potential data leakage if the executed agents have access to proprietary information belonging to other entities within the same SuperAGI instance.
This vulnerability aligns with CWE-269, which describes Improper Privilege Assignment, specifically where a user is granted privileges that they should not possess for a specific resource context. Furthermore, it maps directly to MITRE ATT&CK technique T1078, Valid Accounts, as the exploitation relies on legitimate authentication credentials but abuses them to access resources outside their intended scope. The attack vector also reflects aspects of CWE-639, Authorization Bypass Through User-Controlled Key, since the attacker controls the key (agent_id) used to determine resource accessibility without proper validation against user ownership records.
To mitigate this vulnerability, immediate patching to a version newer than 0.0.14 is required if such updates address these access control checks. In the interim or for custom deployments where patches are not immediately available, developers must implement strict authorization logic within the create_agent_execution and create_agent_run functions. This involves querying the database to confirm that the agent_id provided in the request belongs to an organization associated with the authenticated user's account before allowing any execution-related operations to proceed. Additionally, implementing a centralized middleware for resource-level authorization checks can prevent similar oversights across other endpoints. Regular security audits focusing on multi-tenant isolation and input validation of foreign keys are essential to maintain robust access control policies in complex AI orchestration environments.