Security Advisory: API Credential Exposure in Sandboxes
On April 9, 2026, a security researcher reported a vulnerability in how API credentials were handled inside Daytona sandboxes. We reproduced it, patched every region, and verified the fix the same day.
What happened
When you authenticate to a sandbox with the Daytona CLI or SDK, the API credential is passed into a sandbox process and held in memory. Our default snapshot ships with passwordless sudo (a tradeoff we made early on for developer ergonomics), so anyone with a shell on the sandbox could read that credential out of memory and impersonate the account that launched it.
Sandboxes launched from custom snapshots without sudo or root were not exploitable this way.
Scope
You're affected if you used the CLI or SDK to authenticate to a sandbox from the default snapshot, or from any custom snapshot that still had sudo, at any point before April 9, 2026, 20:44 UTC.
Custom snapshots without sudo are not affected.
Impact
A stolen credential had whatever permissions the account that launched the sandbox had. In practice that means access to the rest of your org's sandboxes, file read/write, and any API call you can make. In our audit logs it would show up as ordinary activity, because to the API it was.
Timeline (UTC)
16:00 — Report received
16:30 — Escalated to security; investigation began
18:15 — Reproduced and confirmed
20:36 — Fix deployed and verified in EU
20:44 — Fix deployed and verified in US
Under five hours from disclosure to full remediation.
The fix
The Authorization header is now stripped at the proxy layer before the request ever reaches the sandbox, so the credential never gets near sandbox memory. While we were in there we also found the issue was broader than the original report. The patch covers all of it.
Was it exploited?
Not as far as we can tell. The bug came in through coordinated disclosure, not from anything we'd noticed in production.
The honest caveat is that a successful exploit would look identical to normal API traffic in our logs, so we can't actually prove the negative. If you were in scope, please rotate. Don't treat this as precautionary.
What you should do
If you used the CLI or SDK with the default snapshot (or any sudo-enabled custom snapshot) before April 9, 20:44 UTC, rotate the affected keys. That includes service accounts and anything wired into CI/CD. Rotation lives in the dashboard under Settings → API Keys.
Then go look at your audit logs for that window. You're looking for sandbox operations, key usage, or admin actions you can't tie back to a person or system you recognize. Anything that doesn't sit right, send to security@daytona.io and we'll dig in with you.
If your sandboxes only run on custom snapshots without sudo or root, you weren't exploitable through this. Rotating is fine hygiene, but you don't have to.
Thanks
The researcher who reported this did so through coordinated disclosure and gave us the time to ship a real fix instead of a band-aid. Thank you.
References
Questions: security@daytona.io