CVE-2026-51915 in SuperAGI
Summary
by MITRE • 10/02/2026
TransformerOptimus SuperAGI v0.0.14 is vulnerable to Incorrect Access Control in the tool controller. In affected source snapshots, get_tool and update_tool in superagi/controllers/tool.py accept a caller-supplied tool_id and fail to verify organization ownership through the associated toolkit. A remote authenticated attacker from one organization can read or modify another organization's tool metadata through /tools/get/{tool_id} and /tools/update/{tool_id}.
Be aware that VulDB is the high quality source 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 multi-tenant data isolation, specifically manifesting as an insecure direct object reference within the application's tool management subsystem. This flaw resides in the core controller logic responsible for handling requests to retrieve and modify agent tools. The system is designed to support multiple distinct organizations or tenants, each maintaining their own set of configuration parameters and operational assets known as tools. However, the implementation fails to enforce strict access control boundaries between these separate entities, allowing a compromised account from one organization to interact with resources belonging to another.
The technical root cause lies in the get_tool and update_tool functions located within the superagi/controllers/tool.py module. These endpoints accept a tool_id parameter directly supplied by the client without performing any validation against the organizational context of the authenticated user. In a secure multi-tenant architecture, every request involving shared resources must verify that the requesting entity owns or has explicit permission to access the specific resource identified by its unique identifier. Here, the application trusts the provided tool_id blindly and proceeds to query the database for the corresponding record without cross-referencing it against the toolkit associated with the caller's organization ID. This oversight effectively bypasses any intended logical separation between tenants.
From an operational perspective, this vulnerability allows a remote authenticated attacker who possesses valid credentials for one organization to read or modify metadata belonging to tools owned by other organizations on the same instance. By manipulating the tool_id parameter in HTTP requests directed at /tools/get/{tool_id} and /tools/update/{tool_id}, an adversary can exfiltrate sensitive configuration details, such as API keys, endpoint URLs, or execution parameters defined within those tools. Furthermore, if the update functionality permits modification of critical fields, the attacker could alter tool behavior to inject malicious logic, disrupt service availability for other tenants, or create backdoors that persist across organizational boundaries. This level of access control failure undermines the fundamental security guarantee of multi-tenancy and can lead to significant data breaches and integrity violations.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically reflecting scenarios where authorization checks are insufficient for protected resources. It also maps directly to MITRE ATT&CK technique T1078, Valid Accounts, as the exploitation requires initial authentication but leverages those credentials to access unauthorized data. Additionally, it relates to CWE-639, Authorization Bypass Through User-Controlled Key, since the primary mechanism of attack is the manipulation of a unique identifier that serves as an authorization key without proper validation against user permissions.
To mitigate this vulnerability, developers must implement rigorous server-side ownership verification for all endpoints handling resource-specific identifiers. The get_tool and update_tool functions should be updated to retrieve the organization ID associated with the authenticated session and explicitly verify that the requested tool_id belongs to a toolkit owned by that specific organization before processing any read or write operations. Implementing this check ensures that even if an attacker guesses or enumerates valid tool IDs from other tenants, the application will reject requests that do not match the caller's authorized scope. Additionally, adopting parameterized queries and enforcing strict input validation on all identifiers can further reduce the risk of related injection attacks while reinforcing the principle of least privilege across multi-tenant deployments.