Summary
SuperAGI contains an access-control weakness in the agent execution configuration endpoint. An authenticated user from one organization may retrieve another organization's agent execution configuration when they know or obtain the relevant agent and execution identifiers.
SuperAGI contains an access-control weakness in the agent execution configuration endpoint. An authenticated user from one organization may retrieve another organization's agent execution configuration when they know or obtain the relevant agent and execution identifiers.
Affected context
The issue occurs in SuperAGI's agent execution configuration retrieval flow, specifically where an API request selects an agent and execution by identifier. Risk is present when the endpoint is reachable by authenticated users across organizational boundaries and the service does not verify that the selected resources belong to the requester's organization.
The issue occurs in SuperAGI's agent execution configuration retrieval flow, specifically where an API request selects an agent and execution by identifier. Risk is present when the endpoint is reachable by authenticated users across organizational boundaries and the service does not verify that the selected resources belong to the requester's organization.
Exploit preconditions
- Attack surface: Authenticated HTTP API endpoint for agent execution configuration details
- Required access: A valid account capable of reaching the endpoint
- Trigger point: A request containing an agent identifier and agent execution identifier
- Why exploitation is possible: The resource lookup is not followed by an effective organization-ownership check, allowing identifiers associated with another organization to be used for retrieval
- Attack surface: Authenticated HTTP API endpoint for agent execution configuration details
- Required access: A valid account capable of reaching the endpoint
- Trigger point: A request containing an agent identifier and agent execution identifier
- Why exploitation is possible: The resource lookup is not followed by an effective organization-ownership check, allowing identifiers associated with another organization to be used for retrieval
Why this happens
The underlying bug is an authorization failure in a multi-tenant resource access path. The endpoint appears to authorize the request at the general authentication level but does not enforce an object-level relationship between the requester, the selected agent, its execution, and the requester's organization. This maps to CWE-284: Improper Access Control, because access decisions do not adequately restrict protected resources to their authorized organizational scope.
The underlying bug is an authorization failure in a multi-tenant resource access path. The endpoint appears to authorize the request at the general authentication level but does not enforce an object-level relationship between the requester, the selected agent, its execution, and the requester's organization. This maps to CWE-284: Improper Access Control, because access decisions do not adequately restrict protected resources to their authorized organizational scope.
Potential impact
- An authenticated user may read agent execution configuration belonging to another organization
- Exposed configuration may reveal operational details, workflow settings, or sensitive metadata
- The issue could undermine tenant isolation and organizational confidentiality
- Disclosed configuration could support further targeted attacks against affected deployments
- An authenticated user may read agent execution configuration belonging to another organization
- Exposed configuration may reveal operational details, workflow settings, or sensitive metadata
- The issue could undermine tenant isolation and organizational confidentiality
- Disclosed configuration could support further targeted attacks against affected deployments
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the resource boundary rather than relying only on authentication or identifier secrecy.
Common defensive patterns include:
- Check organization ownership for the agent and execution before returning configuration data
- Derive the organization scope from the authenticated session or token rather than request parameters
- Apply consistent object-level authorization to every read and write operation
- Return the minimum configuration data required by the caller
- Use least-privilege service identities and deny access by default
- Add tenant-isolation tests covering valid, invalid, and cross-organization resource combinations
Mitigation generally focuses on enforcing authorization at the resource boundary rather than relying only on authentication or identifier secrecy.
Common defensive patterns include:
- Check organization ownership for the agent and execution before returning configuration data
- Derive the organization scope from the authenticated session or token rather than request parameters
- Apply consistent object-level authorization to every read and write operation
- Return the minimum configuration data required by the caller
- Use least-privilege service identities and deny access by default
- Add tenant-isolation tests covering valid, invalid, and cross-organization resource combinations
How teams detect issues like this
Organizations can assess for this class of weakness through:
- Static analysis and code review checks for resource queries that omit tenant or organization predicates
- Review of controller methods that accept direct object identifiers from clients
- API tests that attempt access to resources belonging to a different organization
- Authorization policy checks requiring ownership validation before serialization or response generation
- Audit-log monitoring for repeated cross-organization identifier access attempts or unusual configuration reads
Automated application-security testing and policy-based API review tools may help identify missing object-level authorization checks.
Organizations can assess for this class of weakness through:
- Static analysis and code review checks for resource queries that omit tenant or organization predicates
- Review of controller methods that accept direct object identifiers from clients
- API tests that attempt access to resources belonging to a different organization
- Authorization policy checks requiring ownership validation before serialization or response generation
- Audit-log monitoring for repeated cross-organization identifier access attempts or unusual configuration reads
Automated application-security testing and policy-based API review tools may help identify missing object-level authorization checks.
Sources
| Source | Link |
|---|---|
| gist. | gist.github.com/ |
| github. | github.com/ |
