SuperAGI EUVD-2026-91703

Requires a valid authenticated account on a multi-tenant SuperAGI deployment (PR:L) - exploitation is only meaningful where more than one organization shares the same instance, since the flaw is cross-organization privilege escalation. The attacker must reach the /api/agentexecutions/schedule endpoint over the network and supply a valid agent_id belonging to another organization, implying some knowledge or enumeration of target agent identifiers. Limiting factors: single-tenant or self-hosted single-org deployments have no other organization to victimize and are effectively unaffected; an account (even low-privileged) is mandatory, so fully unauthenticated attackers cannot exploit it; and there is no indication the flaw affects availability.

This is a genuine but second-tier priority rather than an emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) describes a network-reachable, low-complexity flaw requiring only low-privileged authentication - any valid account in any tenant suffices - which maps well to the described cross-organization IDOR/BOLA on /api/agentexecutions/schedule. However, multiple real-world signals pull the risk down: EPSS is only 0.16% (4th percentile), there is NO CISA KEV listing (not actively exploited), and SSVC marks Automatable:no, meaning it cannot be trivially scaled by worms or mass scanners because it requires a valid authenticated session and knowledge/enumeration of a target agent_id. Countervailing signals that raise it: SSVC Technical Impact is 'total' and a public POC exists (SSVC Exploitation:poc, plus a referenced gist), so exploitation is well understood and reproducible. Note the tension: SSVC flags 'total' technical impact and CVSS rates C:H/I:H, yet the core defect is a tenant-isolation/authorization break whose primary consequence is unauthorized triggering/execution of another org's agents - confidentiality impact depends on whether execution results are returned to the attacker, which is not confirmed in the description. Net: a legitimate multi-tenant isolation bug worth patching promptly, but low probability of opportunistic mass exploitation given the authentication prerequisite and non-automatable nature.

An attacker registers or already holds a low-privileged account in one organization on a shared SuperAGI instance, then sends a crafted request to /api/agentexecutions/schedule supplying the agent_id of an agent owned by a different organization. Because the endpoint never verifies that the agent belongs to the caller's organization, it schedules and runs that foreign agent, breaking tenant isolation. A public proof-of-concept exists (referenced gist), lowering the skill barrier to reproduce it.