Daytona vulnerabilities

In versions prior to 0.185.0, Daytona allowed organization role updates and deletions without verifying if the role belonged to the specified organization. An authenticated user owning any organization could modify permissions or delete a role belonging to another organization using that role's identifier.

In versions from 0.101.0 to 0.184.0, sandboxes switched from public to private could remain accessible without authentication for a short period after the change, due to a cached visibility state that was not invalidated.

In versions prior to 0.184.0, users could accept or decline organization invitations even if their email address was not verified. Daytona's authentication system did not require email verification for these actions, creating a risk of unauthorized access.

In versions prior to 0.186, Daytona's sandbox volume reference (volumeId) was forwarded to the runner, potentially allowing unauthorized access to paths outside the intended base directory. The use of path-traversal sequences could enable the construction of the host bind-mount source path without proper confinement.