Daytona: Public sandbox previews remain accessible for up to one hour after being made private

Vulnerability

In Daytona before v0.184.0, when a sandbox owner toggles a preview from public to private, the preview proxy's cached visibility state is not invalidated. As a result, the proxy continues to serve unauthenticated requests to that sandbox's ordinary preview ports for a bounded period (the time it takes for the cache to refresh). This affects only sandboxes that were previously made public and later reverted to private. Terminal, toolbox, and recording-dashboard ports were never affected because they always require authentication. [1][2]

Exploitation

An unauthenticated attacker who knows the URL of a sandbox preview that was recently changed from public to private can continue to access it without authentication until the proxy's cached visibility state refreshes. The attacker does not need any special network position; if the preview was previously accessible without authentication, the stale cache allows continued unauthorized access for a bounded window. The exact duration is determined by the proxy's cache refresh interval. [1][2]

Impact

An attacker can gain unauthorized read access to the sandbox's preview ports (the ordinary web application exposed through the preview) after the sandbox owner intended to make it private. The vulnerability results in an information disclosure of whatever data or UI the sandbox preview exposes. There is no cross-tenant access, privilege escalation, or remote code execution. [1][2]

Mitigation

The issue is fixed in Daytona v0.184.0, released on 2026-06-16 (the publication date of this CVE). The fix ensures that when a sandbox visibility is changed, the proxy's cached preview state is invalidated immediately, so the revocation of public access takes effect on the next request. Users should upgrade to v0.184.0 or later. There is no configuration-based workaround for earlier versions. [1][2]