CVE-2026-51867 in AgentGPT
Summary
by MITRE • 10/01/2026
agentgpt v.1.0.0 is vulnerable to Incorrect Access Control in next/src/server/api/routers/agentRouter.ts. An externally reachable path accepts a caller-selected object or tenant identifier and reaches a data-access operation without a visible owner, tenant, workspace, or membership binding on that object.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/01/2026
The vulnerability identified in AgentGPT version 1.0.0 represents a critical failure in server-side access control mechanisms within the application's API layer. Specifically located in the next/src/server/api/routers/agentRouter.ts file, this flaw allows an externally reachable endpoint to accept user-supplied identifiers for objects or tenants without enforcing proper authorization checks. The core technical issue is that the data-access operation proceeds based solely on the provided identifier, lacking any binding verification against the authenticated caller's owner identity, tenant context, workspace membership, or other relevant security boundaries. This architectural oversight effectively bypasses multi-tenant isolation and role-based access controls, creating a direct path for unauthorized data manipulation.
From a technical perspective, this vulnerability is classified as an Insecure Direct Object Reference (IDOR), which aligns with CWE-639 in the Common Weakness Enumeration standard. The root cause lies in the application's reliance on client-supplied input to determine resource access without validating that the requesting user has explicit permission for that specific resource instance. By accepting a caller-selected object or tenant identifier and immediately executing data operations, the system fails to implement an intermediate authorization layer. This design pattern assumes trust in the integrity of the request parameters rather than verifying them against server-side session state or database ownership records. Consequently, any authenticated user can potentially access, modify, or delete resources belonging to other users or tenants simply by altering the identifier parameter in their API requests.
The operational impact of this vulnerability is severe, particularly for applications handling sensitive data across multiple organizations or workspaces. Attackers with valid credentials can exploit this flaw to perform horizontal privilege escalation, accessing confidential information from competitors or colleagues within a multi-tenant environment. This could lead to significant data breaches involving proprietary algorithms, user personal identifiable information, or critical business logic stored in agent configurations. Furthermore, the ability to modify tenant identifiers may allow attackers to overwrite or delete resources belonging to other entities, resulting in denial of service conditions and loss of data integrity. The lack of visible owner binding means there is no audit trail linking actions to legitimate ownership during the initial exploitation phase, complicating forensic analysis and incident response efforts.
This vulnerability maps directly to several techniques within the MITRE ATT&CK framework, most notably T1078 Valid Accounts for lateral movement or data access using stolen credentials, and T1530 Data from Cloud Storage if the affected resources are stored in external cloud buckets. The exploitation path typically involves intercepting API traffic via a proxy tool such as Burp Suite, identifying the specific parameter controlling resource identity, and systematically testing different identifiers to discover accessible objects outside the attacker's authorized scope. This behavior is characteristic of broken object level authorization attacks where the application logic fails to enforce proper access controls at the data layer rather than just the UI or session management layers.
Mitigation strategies must focus on implementing robust server-side validation for all resource access requests. Developers should refactor the agentRouter.ts module to ensure that every data-access operation verifies the relationship between the authenticated user's identity and the requested resource ID before proceeding. This involves querying a central authorization service or database table to confirm ownership, tenant membership, or workspace permissions associated with the target object identifier. Additionally, implementing principle of least privilege ensures that API endpoints only expose necessary fields and operations based on verified roles. Regular security code reviews focusing on access control logic and automated static analysis tools configured to detect CWE-639 patterns can help prevent similar flaws in future development cycles. Enforcing strict input validation and using indirect reference maps instead of direct object identifiers further reduces the attack surface by decoupling user-facing IDs from internal database keys, making it significantly harder for attackers to enumerate or guess valid resource references.