Summary
A critical access control flaw in SuperAGI's agent execution controller allows an authenticated user to create or start execution records for an agent owned by another organization. The issue arises when caller-supplied agent identifiers are accepted without verifying organizational ownership.
A critical access control flaw in SuperAGI's agent execution controller allows an authenticated user to create or start execution records for an agent owned by another organization. The issue arises when caller-supplied agent identifiers are accepted without verifying organizational ownership.
Affected context
The vulnerability occurs in SuperAGI deployments using affected source snapshots up to v0.0.14, where the agent execution controller handles requests to /agentexecutions/add or /agentexecutions/add_run. Risk exists when these endpoints accept an agent identifier from an authenticated caller without enforcing that the referenced agent belongs to the caller's organization.
The vulnerability occurs in SuperAGI deployments using affected source snapshots up to v0.0.14, where the agent execution controller handles requests to /agentexecutions/add or /agentexecutions/add_run. Risk exists when these endpoints accept an agent identifier from an authenticated caller without enforcing that the referenced agent belongs to the caller's organization.
Exploit preconditions
- Attack surface: Remote HTTP API endpoints for agent execution
- Required access: A valid authenticated account in a SuperAGI organization
- Trigger point: Requests to create an agent execution or agent run
- Required condition: The caller can submit an identifier for an agent outside their organization
- Why exploitation is possible: The controller does not consistently authorize the referenced agent against the authenticated user's organization before creating or starting execution records
- Attack surface: Remote HTTP API endpoints for agent execution
- Required access: A valid authenticated account in a SuperAGI organization
- Trigger point: Requests to create an agent execution or agent run
- Required condition: The caller can submit an identifier for an agent outside their organization
- Why exploitation is possible: The controller does not consistently authorize the referenced agent against the authenticated user's organization before creating or starting execution records
Why this happens
The underlying bug is an object-level authorization failure. The controller trusts a caller-supplied agent_id and performs the requested operation without verifying ownership or organizational membership for the referenced agent. This maps to CWE-284: Improper Access Control, because authorization checks do not adequately constrain access to tenant-owned resources.
The underlying bug is an object-level authorization failure. The controller trusts a caller-supplied agent_id and performs the requested operation without verifying ownership or organizational membership for the referenced agent. This maps to CWE-284: Improper Access Control, because authorization checks do not adequately constrain access to tenant-owned resources.
Potential impact
- An attacker may create execution records associated with another organization's agent
- An attacker could start unauthorized runs for cross-tenant agents
- Confidential agent configuration or execution data could be exposed indirectly
- Unauthorized executions may consume resources or alter operational state
- Tenant isolation could be weakened across the SuperAGI deployment
- An attacker may create execution records associated with another organization's agent
- An attacker could start unauthorized runs for cross-tenant agents
- Confidential agent configuration or execution data could be exposed indirectly
- Unauthorized executions may consume resources or alter operational state
- Tenant isolation could be weakened across the SuperAGI deployment
General mitigation guidance
Mitigation generally focuses on enforcing server-side, object-level authorization for every agent execution request.
Common defensive patterns include:
- Resolve the authenticated user's organization from the server-side session or token context
- Verify that the target agent belongs to the caller's organization before any create or run operation
- Avoid treating client-supplied organization or ownership fields as authoritative
- Apply centralized authorization policies consistently across related endpoints
- Use least-privilege service identities and separate tenant-owned resources where practical
- Return uniform authorization failures without disclosing whether another tenant's resource exists
Mitigation generally focuses on enforcing server-side, object-level authorization for every agent execution request.
Common defensive patterns include:
- Resolve the authenticated user's organization from the server-side session or token context
- Verify that the target agent belongs to the caller's organization before any create or run operation
- Avoid treating client-supplied organization or ownership fields as authoritative
- Apply centralized authorization policies consistently across related endpoints
- Use least-privilege service identities and separate tenant-owned resources where practical
- Return uniform authorization failures without disclosing whether another tenant's resource exists
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review checks for database lookups using caller-supplied object identifiers without tenant predicates
- Review of controller methods that create, start, update, or delete tenant-owned resources
- API tests attempting cross-organization access with valid authenticated identities
- Authorization policy checks requiring organization ownership before service-layer operations
- Audit logging that records authenticated organization, target resource, authorization result, and operation type
- Automated review tools that flag direct object access without an associated authorization check
Organizations can look for this class of issue through:
- Static analysis and code review checks for database lookups using caller-supplied object identifiers without tenant predicates
- Review of controller methods that create, start, update, or delete tenant-owned resources
- API tests attempting cross-organization access with valid authenticated identities
- Authorization policy checks requiring organization ownership before service-layer operations
- Audit logging that records authenticated organization, target resource, authorization result, and operation type
- Automated review tools that flag direct object access without an associated authorization check
Sources
| Source | Link |
|---|---|
| gist. | gist.github.com/ |
