Summary
SuperAGI's agent execution scheduling endpoint does not properly verify that a requested agent belongs to the authenticated user's organization. An authenticated user may therefore schedule an existing agent from another organization by supplying its identifier.
SuperAGI's agent execution scheduling endpoint does not properly verify that a requested agent belongs to the authenticated user's organization. An authenticated user may therefore schedule an existing agent from another organization by supplying its identifier.
Affected context
The vulnerability occurs in SuperAGI deployments where authenticated users can access the agent execution scheduling endpoint at /api/agentexecutions/schedule. Risk exists when the endpoint accepts an agent_id without enforcing an organization-level ownership or tenancy check before scheduling the agent.
The vulnerability occurs in SuperAGI deployments where authenticated users can access the agent execution scheduling endpoint at /api/agentexecutions/schedule. Risk exists when the endpoint accepts an agent_id without enforcing an organization-level ownership or tenancy check before scheduling the agent.
Exploit preconditions
- Attack surface: Authenticated API access to the agent execution scheduling endpoint
- Required access: A valid user account in one organization
- Trigger point: A scheduling request containing an agent identifier
- Why exploitation is possible: The server authorizes the scheduling action without confirming that the referenced agent belongs to the authenticated user's organization
- Attack surface: Authenticated API access to the agent execution scheduling endpoint
- Required access: A valid user account in one organization
- Trigger point: A scheduling request containing an agent identifier
- Why exploitation is possible: The server authorizes the scheduling action without confirming that the referenced agent belongs to the authenticated user's organization
Why this happens
The underlying flaw is an authorization decision based on the presence of a valid authenticated session rather than on the user's relationship to the requested resource. The endpoint accepts a client-supplied agent_id but omits an organization-scoped ownership check, mapping to CWE-284: Improper Access Control. This insecure pattern can permit cross-tenant access whenever resource identifiers are accepted without server-side authorization enforcement.
The underlying flaw is an authorization decision based on the presence of a valid authenticated session rather than on the user's relationship to the requested resource. The endpoint accepts a client-supplied agent_id but omits an organization-scoped ownership check, mapping to CWE-284: Improper Access Control. This insecure pattern can permit cross-tenant access whenever resource identifiers are accepted without server-side authorization enforcement.
Potential impact
- Unauthorized scheduling of agents belonging to another organization
- Execution of workflows outside the user's authorized tenant
- Consumption of another organization's compute or operational resources
- Exposure of agent outputs, activity, or execution metadata
- Cross-organization data access or workflow disruption
- Unauthorized scheduling of agents belonging to another organization
- Execution of workflows outside the user's authorized tenant
- Consumption of another organization's compute or operational resources
- Exposure of agent outputs, activity, or execution metadata
- Cross-organization data access or workflow disruption
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the point where the requested agent is resolved and scheduled.
Common defensive patterns include:
- Deriving the organization context from the authenticated session rather than trusting client-supplied tenancy values
- Requiring a server-side ownership or membership check before scheduling any agent
- Applying consistent tenant-scoped authorization to every agent-related endpoint
- Using deny-by-default policies for cross-organization resource access
- Returning indistinguishable responses for unauthorized and nonexistent resources where appropriate
- Limiting service-account and user privileges to the minimum required scope
- Adding authorization tests for same-organization, cross-organization, and missing-resource cases
Mitigation generally focuses on enforcing authorization at the point where the requested agent is resolved and scheduled.
Common defensive patterns include:
- Deriving the organization context from the authenticated session rather than trusting client-supplied tenancy values
- Requiring a server-side ownership or membership check before scheduling any agent
- Applying consistent tenant-scoped authorization to every agent-related endpoint
- Using deny-by-default policies for cross-organization resource access
- Returning indistinguishable responses for unauthorized and nonexistent resources where appropriate
- Limiting service-account and user privileges to the minimum required scope
- Adding authorization tests for same-organization, cross-organization, and missing-resource cases
How teams detect issues like this
Organizations can look for:
- Static analysis and code review checks ensuring resource lookups include authenticated organization constraints
- API tests that attempt to reference resources owned by another tenant
- Signals where agent identifiers and organization identifiers do not match
- Audit logs showing scheduling requests for agents outside the caller's tenant
- Policy enforcement requiring centralized authorization middleware or service-layer checks
- Automated review tools that flag direct use of client-provided identifiers without ownership validation
Organizations can look for:
- Static analysis and code review checks ensuring resource lookups include authenticated organization constraints
- API tests that attempt to reference resources owned by another tenant
- Signals where agent identifiers and organization identifiers do not match
- Audit logs showing scheduling requests for agents outside the caller's tenant
- Policy enforcement requiring centralized authorization middleware or service-layer checks
- Automated review tools that flag direct use of client-provided identifiers without ownership validation
Sources
| Source | Link |
|---|---|
| gist. | gist.github.com/ |
| github. | github.com/ |
