Cross-Organization Agent Lifecycle Actions 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 controller endpoints (/api/agents/create, /api/agents/schedule, /api/agents/delete, /api/agents/edit_schedule, /api/agents/stop_schedule) allow authenticated users from one organization to create, schedule, edit, stop, and delete agents belonging to a different organization's project. The endpoints accept a project_id parameter but do not verify that the project belongs to the authenticated user's organization.

Affected Endpoints:

• POST /api/agents/create - create_agent_with_config at superagi/controllers/agent.py:89
• POST /api/agents/schedule - create_and_schedule_agent at superagi/controllers/agent.py:183
• DELETE /api/agents/delete/{agent_id}
• PUT /api/agents/edit_schedule
• PUT /api/agents/stop_schedule

Vulnerability Type: Improper Access Control (CWE-284)

How to replicate your Issue?

Prerequisites:

1. Deploy SuperAGI instance with multi-organization support
2. Create two organizations: Organization A (victim) and Organization B (attacker)
3. Create user accounts in both organizations
4. Set up Burp Suite proxy at 127.0.0.1:8080

Reproduction Steps:

1. Setup victim data:

   • Log in to SuperAGI as Organization A user
   • Create a project and note the project_id (visible in browser network requests)
   • Create an agent under this project and note the agent_id

2. Capture baseline request:

   • Log in to SuperAGI as Organization B user (attacker)
   • Navigate to the agent creation page
   • Open browser developer tools (Network tab) or use Burp Suite
   • Start creating a new agent to capture the request to /api/agents/create

3. Exploit the vulnerability:

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

4. Verify the impact:

   • The request succeeds with HTTP 200 response
   • Log back in as Organization A user
   • Navigate to the project - the unauthorized agent now appears under Organization A's project
   • Organization B user successfully created an agent in Organization A's project without authorization

Similar exploitation applies to:

• Scheduling agents: POST /api/agents/schedule with victim agent_id
• Deleting agents: DELETE /api/agents/delete/{victim_agent_id}
• Modifying schedules: PUT /api/agents/edit_schedule with victim agent_id

Upload Error Log Content

No error logs - the vulnerability allows successful unauthorized operations.​Expected behavior: The API should return HTTP 403 Forbidden when attempting to access resources from another organization.​Actual behavior: The API returns HTTP 200 and performs the requested operation on the victim organization's resources.​Security Impact: This is a horizontal privilege escalation vulnerability allowing cross-organization access control bypass.