CVE-2026-51914 in SuperAGI
Summary
by MITRE • 10/02/2026
TransformerOptimus SuperAGI v0.0.14 is vulnerable to Incorrect Access Control in the agent template controller. In affected source snapshots, save_agent_as_template and publish_template in superagi/controllers/agent_template.py accept caller-supplied agent_id or agent_execution_id values and do not verify that the referenced agent or execution belongs to the authenticated user's organization.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in TransformerOptimus SuperAGI version 0.0.14 represents a critical failure in server-side access control mechanisms, specifically within the agent template management subsystem. This flaw allows an attacker with valid authentication credentials for one organizational tenant to manipulate resources belonging to another tenant or unauthorized users. The core of the issue lies in how the application handles identifiers passed by clients during specific API operations. When a user interacts with the system to save an existing agent as a new template or publish an existing template, the backend processes requests containing caller-supplied values for agent_id and agent_execution_id. These parameters are used to locate specific data objects within the database without performing adequate authorization checks to ensure that the authenticated user has ownership or appropriate permissions over those specific resources.
From a technical perspective, this is a classic example of an Insecure Direct Object Reference (IDOR) vulnerability. The application relies on client-supplied identifiers to determine which agent template should be modified but fails to enforce vertical access controls. Vertical privilege escalation occurs because the system does not verify that the resource being accessed belongs to the authenticated user's organization or tenant context. By simply changing the ID values in the HTTP request payload, an attacker can target agents and executions associated with other users within the same multi-tenant environment. This lack of object-level authorization means that any authenticated user can potentially read, modify, or publish templates belonging to colleagues or competitors if they are aware of valid identifier formats or can enumerate them through brute-force techniques.
The operational impact of this vulnerability is significant in a multi-tenant SaaS architecture where data isolation between organizations is paramount. An attacker could exploit this flaw to steal sensitive configuration details embedded within agent templates, such as API keys, system prompts, or integration credentials configured for other users' agents. Furthermore, the ability to publish unauthorized templates can lead to supply chain attacks within the platform, where maliciously crafted templates are distributed and executed by unsuspecting users, potentially leading to further compromise of their systems or data exfiltration. This undermines the fundamental trust model of the application, as authenticated access does not guarantee isolation between distinct organizational units.
This vulnerability maps directly to CWE-284, which describes Improper Access Control, specifically highlighting failures in verifying user authorization for specific objects. It also aligns with MITRE ATT&CK technique T1078, Valid Accounts, where attackers use legitimate credentials to access resources they are not authorized to view or modify. Additionally, the mechanism of manipulating object identifiers corresponds to CWE-639, Injection of Critical Data Objects via Indirect Reference Manipulation. The absence of server-side validation against a session-bound context or explicit ownership checks is the root cause that enables this unauthorized data exposure and modification.
To mitigate this vulnerability, developers must implement strict authorization checks at the controller level for all endpoints involving resource manipulation. Every request to save_agent_as_template or publish_template should include a verification step that queries the database to confirm the agent_id or agent_execution_id belongs to an entity owned by the authenticated user's organization ID stored in their session token. Implementing row-level security policies within the database can also provide an additional layer of defense, ensuring that even if application logic fails, the underlying data store enforces isolation boundaries. Regular code audits focusing on access control patterns and automated testing using tools designed to detect IDOR vulnerabilities are recommended to prevent similar issues in future releases.