HIGH 7.7

CVE-2026-54322: Daytona Cross-Organization Role Authorization Bypass

Daytona, an infrastructure platform for AI code execution, contains an authorization bypass vulnerability in its role management system. An authenticated attacker who owns any organization can modify or delete roles that belong to a completely different organization. The vulnerability stems from the application checking whether the caller owns the organization in the URL path, but then operating on a role based solely on its ID without confirming that role belongs to the target organization. This allows privilege escalation and lateral damage across organization boundaries. The issue affects Daytona versions prior to 0.185.0.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.7 HIGH · CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:L
Weaknesses (CWE)
CWE-639, CWE-862
Affected products
0 configuration(s)
Published / Modified
2026-06-23 / 2026-06-23

NVD description (verbatim)

Daytona is a secure and elastic infrastructure runtime for AI-generated code execution and agent workflows. Prior to 0.185.0, Daytona's organization role update and delete endpoints authorized the caller as an owner of the organization named in the request path, but resolved and mutated the target role by its identifier alone, without verifying the role belonged to that organization. An authenticated user who owns any organization (organizations are self-service) could therefore modify the permissions of, or delete, a role belonging to a different organization, given that role's identifier. This vulnerability is fixed in 0.185.0.

1 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-54322 is a cross-organization authorization flaw in Daytona's role management endpoints. When a user requests to update or delete an organization role via the API, the application validates that the caller is an owner of the organization specified in the request path. However, the backend then resolves and mutates the target role using only its identifier, without performing a secondary check to ensure that role object actually belongs to the organization in scope. Because Daytona allows self-service organization creation, an attacker needs only to own one organization to exploit this. By crafting requests to role update or delete endpoints with their own organization in the path but a role ID from another organization, an authenticated attacker can modify role permissions across organization boundaries or delete roles entirely. This violates the fundamental principle that authorization checks must cover all resources being accessed, not just the request path.

Business impact

This vulnerability enables a form of horizontal privilege escalation where an authenticated user with minimal footprint (a single self-service organization) can disrupt governance in unrelated organizations. An attacker could elevate roles to grant themselves admin access in victim organizations, degrade role permissions to disable legitimate users, or delete critical roles to disrupt operations. For multi-tenant deployments or environments where Daytona orchestrates AI agent workflows, this could allow a rogue actor to compromise AI execution policies, access controls, and operational continuity across customer or team boundaries.

Affected systems

Daytona versions prior to 0.185.0 are affected. The vulnerability requires authentication, so it does not impact unauthenticated attack surface. Any Daytona deployment where users can self-create organizations and where role-based access control is relied upon for multi-tenant isolation is at risk.

Exploitability

Exploitability requires a valid Daytona user account and knowledge or enumeration of role identifiers in target organizations. The attacker must be able to create or own an organization. Because the vulnerability is a logic flaw in authorization checks rather than a cryptographic or complex-to-trigger condition, exploitation is straightforward once an attacker has authenticated access. However, the CVSS score reflects the higher complexity needed to discover target role IDs in multi-tenant scenarios. The attack is repeatable and does not require special timing or network conditions.

Remediation

Upgrade Daytona to version 0.185.0 or later. This patch adds a verification step to confirm that the role being modified or deleted actually belongs to the organization named in the request path. Apply updates to all Daytona deployments used for production AI code execution and agent orchestration.

Patch guidance

1. Review your current Daytona version by checking deployed instances or release tags. 2. Plan an upgrade to 0.185.0 or later during a maintenance window. 3. If running a hosted or managed Daytona service, verify with your provider that the patch has been applied. 4. Test role management functionality in a staging environment before production deployment to ensure no operational impact. 5. After patching, review organization role assignments to identify any unauthorized changes that may have occurred prior to the update.

Detection guidance

Monitor Daytona API logs for suspicious patterns: repeated requests to role update or delete endpoints from a single user account with organization paths that differ from the user's own organization; role modifications or deletions in organizations where the caller has no assigned membership; and unusually rapid role permission changes. Configure alerts on cross-organization role mutations and failed role operations. Collect audit logs of role change events with source user, target organization, and timestamp information.

Why prioritize this

This vulnerability rates as HIGH (CVSS 7.7) due to the scope change (cross-organization impact) and the high integrity risk from modifying permissions. Although it requires authentication and elevated complexity to discover target role IDs, the ability to disrupt governance and elevate privileges in unrelated organizations makes it a strong candidate for rapid patching. Organizations using Daytona for production AI agent workflows should prioritize this update, as compromised roles could lead to uncontrolled code execution or data access via those agents.

Risk score, explained

The CVSS score of 7.7 reflects HIGH severity because: (1) the attack vector is network-based with no user interaction needed; (2) authentication is required but any user can exploit it (PR:L); (3) the attack complexity is higher because discovering target role IDs in a multi-tenant environment requires enumeration or side-channel knowledge (AC:H); (4) the scope changes because an actor in one organization impacts another (S:C); (5) confidentiality impact is low (information disclosure of role assignments); (6) integrity impact is high (permissions can be modified or roles deleted); (7) availability impact is low (role deletion could disrupt services but is not the primary impact). The combination of cross-organization reach and high integrity risk justifies the HIGH rating despite authentication and complexity requirements.

Frequently asked questions

Can an attacker create a new organization for free just to exploit this?

Yes, if Daytona's organization creation is self-service and unrestricted. This is the attack pattern—the attacker does not need existing privilege, only a valid account and the ability to own any organization. Rate-limiting or approval workflows on organization creation would reduce attack feasibility.

Does this vulnerability allow reading data from other organizations?

The vulnerability is primarily about modifying or deleting roles. However, the fact that role identifiers are guessable or enumerable suggests potential information disclosure about role existence in other organizations. The CVSS reflects low confidentiality impact, so data exfiltration is not the main risk vector.

What should we do if we suspect our Daytona instance was compromised before patching?

Review your organization's role assignments and member permissions for unauthorized changes. Audit which users have admin or elevated roles, especially any added or modified since Daytona deployment. Reset credentials for users with suspicious activity. Apply the patch immediately, then re-audit after patching to confirm the authorization check is now in place.

Does this affect Daytona's AI code execution security model?

Indirectly. If an attacker escalates their role permissions in a different organization, they could gain access to AI agent execution contexts, workflow configurations, or secrets managed under that organization. The primary risk is privilege escalation within Daytona's access control layer, which then cascades to the assets and workflows managed under those roles.

This analysis is provided for informational purposes to help security teams understand and prioritize vulnerability remediation. The vulnerability details and patch information are derived from CVE and vendor sources current as of the published date. Organizations should verify patch availability and compatibility with their specific Daytona deployment before applying updates. This analysis does not constitute legal advice or a guarantee of security; responsible disclosure and vendor guidance should always be followed. No exploit code or weaponized proof-of-concept is provided or supported. Source: NVD (public-domain), retrieved 2026-07-29. Analysis generated by SEC.co (claude-haiku-4-5).