EUVD-2026-38563
GHSA-qxvm-pcfm-qc39
Severity by source
AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:L
Network-reachable API (AV:N); requires out-of-band knowledge of victim role ID (AC:H); attacker must be an org owner, trivially self-served (PR:L); cross-tenant breach changes scope (S:C); primarily integrity impact on victim org with limited disclosure and availability loss.
Primary rating from Vendor (https://github.com/daytonaio/daytona).
CVSS VectorVendor: https://github.com/daytonaio/daytona
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:L
Lifecycle Timeline
2DescriptionCVE.org
Summary
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.
Impact
This is a cross-tenant broken access control (IDOR) issue affecting multi-tenant deployments, including the managed Daytona platform. Using a target role's identifier, an attacker with owner rights over their own organization could:
- Overwrite the target role's name and permission set, escalating or stripping privileges for every member and API key in the victim organization that holds that role.
- Delete the target role, removing the associated permissions from its holders.
- Observe the victim role's current permission set returned in the update response (limited information disclosure).
Exploitation requires knowledge of the target role's identifier, which is not enumerable across organizations and is not exposed to non-members through the API.
Affected versions
All versions up to and including 0.184.0.
Patches
Fixed in 0.185.0. The role update, delete, and role-assignment lookups are now scoped to the caller's organization, so a role belonging to another organization resolves to "not found" before any read or mutation. The managed Daytona platform was updated on release of 0.185.0.
Workarounds
None. Upgrade to 0.185.0. Single-organization self-hosted deployments are not exploitable, as the issue requires a second organization to target.
Credit
Reported by @vnth4nhnt.
AnalysisAI
Cross-tenant privilege escalation in Daytona (versions ≤0.184.0) allows any authenticated user who owns an organization to modify or delete roles belonging to other organizations on the same instance, including the managed Daytona platform. The role update and delete endpoints only validated owner-level access to the path-named organization while resolving the target role by its global identifier, enabling tenant-boundary bypass. No public exploit identified at time of analysis, and exploitation requires knowing the victim role's non-enumerable identifier.
Technical ContextAI
Daytona is an open-source development environment manager (Go package github.com/daytonaio/daytona) with multi-tenant organization support and self-service org creation. The flaw is a classic CWE-639 Authorization Bypass Through User-Controlled Key (IDOR): the REST handlers for organization role update and delete trusted the org identifier in the request path for the authorization check but performed the actual lookup and mutation against the role identifier without an intersecting WHERE clause tying the role back to the caller's organization. The fix in 0.185.0 scopes role update, delete, and role-assignment lookups to the caller's organization so out-of-scope role IDs resolve to 'not found' before any read or mutation occurs.
RemediationAI
Vendor-released patch: upgrade to Daytona 0.185.0 or later, where the role update, delete, and role-assignment lookups are scoped to the caller's organization (advisory: https://github.com/daytonaio/daytona/security/advisories/GHSA-qxvm-pcfm-qc39). The managed Daytona platform was updated on 0.185.0 release and requires no customer action. The vendor explicitly states there are no workarounds; if upgrade is temporarily blocked on a self-hosted multi-tenant instance, the only meaningful compensating controls are to disable self-service organization creation (reducing the pool of users who can become owners) and to audit organization creation and role mutation events for anomalies - both narrow rather than eliminate the attack surface. Single-org self-hosted deployments may defer the upgrade with low immediate risk since exploitation requires a second organization.
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today