Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A sandbox volume reference (volumeId, which may also be a volume name) was forwarded to the runner and used to build the host bind-mount source path without confinement. A reference containing path-traversal sequences could in principle resolve the mount source outside the intended per-volume base directory. Impact Had the traversal been reachable, an authenticated user could have caused the runner to bind-mount an unintended host path into their sandbox, with a worst-case impact of read and write access to other tenants' volume data (per-volume FUSE mounts are world-readable and writable). Important: this path was not exploitable in any released version. A volume reference is validated against the database before it reaches the runner, and the volume id column is a UUID type, so a reference containing traversal sequences is rejected at validation time and the request fails before any mount is constructed. We could not reproduce cross-tenant access or an out-of-base host…
Recommended action: Upgrade to 0.186.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A cross-tenant authorization flaw in Daytona's notification WebSocket gateway allowed any authenticated user to subscribe to another organization's realtime notification channel and passively receive that organization's events. Impact The notification gateway's JWT handshake joined a client-supplied organization identifier to the corresponding notification room without verifying that the authenticated user was a member of that organization. As a result, an authenticated user could receive another organization's realtime sandbox, snapshot, volume, and runner events, including data carried in those events. This is a cross-tenant confidentiality break. It required a valid account and knowledge of the target organization id (a non-secret UUID); no elevated privileges were needed. The API-key authentication path was not affected. The affected component is the Daytona API service (the apps/api NestJS application). It is distributed through Daytona's repository releases and…
Recommended action: Upgrade to 0.185.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.185.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/daytonaio/daytona >= 0.101.0, <= 0.183.0
Fixed in
0.184.0· Vendor fix available
Issue
Sandbox previews that were switched from public to private could remain reachable without authentication for a short period after the change, due to a cached visibility state that was not invalidated when the sandbox's visibility changed. Impact When a sandbox owner changed a preview from public to private, the preview proxy could continue serving unauthenticated requests to that sandbox's ordinary preview ports for a bounded period before the change took effect. Only sandboxes that had been made public and were later set back to private were affected, and only until the proxy's cached visibility state was refreshed. Terminal, toolbox, and recording-dashboard ports were never affected, as those always require authentication. The issue did not involve cross-tenant access, privilege escalation, or remote code execution. Patches Fixed in v0.184.0. Sandbox visibility changes now invalidate the proxy's cached preview state immediately, so revoking a public preview takes effect on…
Recommended action: Upgrade to 0.184.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.