A sandbox is a private container running the vulnerable application for the lab you opened. It is yours for the session, reachable at a URL the platform gives you, and destroyed when you stop it or when the session ends. The whole point of a sandbox is that you can do anything inside it that an attacker would do, and none of it affects anybody else.Documentation Index
Fetch the complete documentation index at: https://docs.cveplayground.com/llms.txt
Use this file to discover all available pages before exploring further.
The launch flow
The sandbox card lives on the right side of the lab detail page. The button it shows depends on the phase.Starting
Click launch and the card flips to a loading state. A spinner and a status label say what is happening. Cold start usually takes 30 to 60 seconds.
Ready
A URL appears with an Open button. The URL is private to you. Open it in a new tab to see the vulnerable app.
Time and reachability
Sandboxes have a time budget. The exact limit is shown on the card while one is running. When the budget runs out, the container is destroyed and your view of the URL stops working. If you reload the lab page while a sandbox is running, the card picks up where it left off. The platform polls every couple of seconds to keep the status fresh. The sandbox URL is only reachable from the browser you launched it in. Sharing the URL with somebody else does not work; the platform binds the session to your account.What lives inside a sandbox
One vulnerable application. Sometimes a small support service it depends on (a database, a cache, a downstream API), packaged together. No real user data. No outbound network access to anything other than the platform itself, except where a lab specifically needs it. You cannot SSH into the container. You cannot pull a shell. The point is to exploit the bug through the same interface a real attacker would: HTTP, the file upload form, the search box, whatever the bug needs. If a lab needs you to inspect logs or files from inside the container, the lab tells you how, usually by giving you a small endpoint that reads them safely.When a sandbox does not come up
The cold start has a hard ceiling of 90 seconds. If the container is not ready by then, the card shows an error. The most common reasons:- The platform is under unusual load and a build is queueing.
- A transient infrastructure hiccup. Almost always resolved by retrying.
- The lab is being updated. Less common, but it happens.
Stopping early
Click Stop on the card. The container is destroyed within a few seconds. You can launch it again from idle as many times as you want during the lab. Each new launch is a fresh container. Anything you wrote, uploaded, or modified in the previous one is gone. That is on purpose: it means a sandbox that gets into a weird state is one click away from being clean again.What you can and cannot do
You can:- Run any payload, any tooling, any exploit chain against the vulnerable app.
- Use Burp, curl, sqlmap, ffuf, your own scripts. Anything that talks HTTP.
- Try the exploit as many times as you want. There is no rate limiting on you specifically.
- Use the sandbox as a free VPS. The platform watches for that.
- Attack other sandboxes. They are firewalled from each other.
- Persist anything across launches. Containers are ephemeral by design.
Stuck or weird behaviour
If the sandbox is running but does not respond, the first thing to try is stopping it and launching a new one. The new container is fresh, and most stuck states do not survive a restart. If the new container has the same problem, the lab itself might be the issue. Drop a note to support with the lab CVE ID. Lab issues are usually fixed within a day or two.Troubleshooting
Sandbox stuck, sign in failing, lost progress.
Challenges
Live challenge sandboxes work the same way.