Cross-Organization Agent Scheduling Without Authorization Check

⚠️ Check for existing issues before proceeding. ⚠️

• I have searched the existing issues, and there is no existing issue for my problem

Where are you using SuperAGI?

Linux

Which branch of SuperAGI are you using?

Main

Do you use OpenAI GPT-3.5 or GPT-4?

GPT-4

Which area covers your issue best?

Agents

Describe your issue.

SuperAGI's agent execution controller endpoint /api/agentexecutions/schedule allows authenticated users from one organization to schedule existing agents belonging to a different organization without proper authorization checks. The endpoint accepts an agent_id parameter but does not verify that the agent belongs to the authenticated user's organization.

Affected Endpoint:

• POST /api/agentexecutions/schedule - schedule_existing_agent at superagi/controllers/agent_execution.py:258

Vulnerability Type: Improper Access Control (CWE-284)

How to replicate your Issue?

Environment:

1. Deploy an affected SuperAGI version from source.
2. Use a browser and Burp Suite, or a browser with Developer Tools Network tab.
3. Create two organizations: Organization A as the victim and Organization B as the attacker.
4. Create one normal user account in each organization.
5. If the deployment uses an /api reverse-proxy prefix, use the exact path captured by the browser. The backend route in source is /agentexecutions/schedule.

Steps:

1. Log in as the Organization A user.
2. Create a normal agent in Organization A.
3. Open the browser Network tab while viewing or scheduling the agent and record the Organization A agent_id.
4. Log in as the Organization B user in a separate browser profile.
5. In the Organization B UI, schedule any existing Organization B agent so the browser sends POST /agentexecutions/schedule.
6. Send that request to Burp Repeater.
7. Keep the Organization B Cookie or Authorization header unchanged.
8. Replace only the JSON agent_id value with the Organization A agent_id.
9. Set a benign future start_time and harmless recurrence settings.
10. Forward the modified request.
11. Expected secure behavior: the request is rejected because the target agent belongs to Organization A.
12. Vulnerable behavior: the request succeeds and returns a schedule_id for the Organization A agent.
13. Confirm the effect by logging back in as Organization A and checking that the victim agent now has the attacker-selected schedule, or by querying the schedule data for the victim agent through the application UI.

Reproduction Steps:

1. Setup victim data:

   • Log in to SuperAGI as Organization A user
   • Create a project and an agent
   • Note the agent_id (visible in browser network requests or URL)

2. Capture baseline request:

   • Log in to SuperAGI as Organization B user (attacker)
   • Navigate to agent scheduling functionality
   • Open browser developer tools (Network tab) or use Burp Suite
   • Attempt to schedule one of your own agents to capture the request format to /api/agentexecutions/schedule

3. Exploit the vulnerability:

   • In Burp Suite Repeater (or modify the request):
   • Keep the Organization B user's authentication token/cookie
   • Modify the agent_id field in the request body to Organization A's agent ID
   • Send the request

4. Verify the impact:

   • The request succeeds with HTTP 200 response
   • Log back in as Organization A user
   • Check the agent's execution history - a new scheduled execution appears
   • Organization B user successfully scheduled Organization A's agent without authorization

Upload Error Log Content

No error logs