> ## 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.
# Quickstart
> Sign in, finish your first lab, and earn your first XP.
About ten minutes from cold start to your first completed lab. The goal here is not to teach you a class of vulnerability. It is to get you familiar with the loop so the next lab is muscle memory.
## Before you start
You need a browser. That is it. Email and a password (or any social login Auth0 offers) will create your account.
## Step 1. Sign in and claim a handle
Open [app.cveplayground.com](https://app.cveplayground.com) and click sign in. Auth0 takes over for the credentials. You come back to a small modal that asks you to pick a handle.
The handle is your public identity on the platform. It shows up on the leaderboard, on lab first blood records, and at `/u/your-handle`. You can change the display name later in settings, but the handle is harder to change, so pick one you can live with.
The handle picker suggests three variants based on your email. If you do not like any of them, type your own. Availability is checked in real time.
## Step 2. Pick a starter lab
Once you land on the dashboard, click **Labs** in the sidebar. The catalog opens with every lab visible.
For your first one, look for a lab marked **Easy** or one with a low XP value. The point of the first lab is not the difficulty. It is the flow.
A few that work well as a first lab:
* Anything tagged path traversal. Easy to see, easy to verify, easy to patch.
* Older Spring or Flask CVEs. The reproduction is usually a single curl command.
* Simple SQL injection labs. Familiar territory, even if you have only read about it.
## Step 3. Read the brief
Click into the lab. You will see five steps across the top: **brief, locate, reproduce, patch, harden**. You start on brief.
Read the brief end to end before doing anything else. It tells you what broke, where it is, and what is at stake. Two minutes here saves twenty later.
## Step 4. Launch the sandbox
On the lab page, find the sandbox card and click **Launch sandbox**. A spinner appears with a status label.
Cold start usually takes 30 to 60 seconds. When it is ready, the card shows a URL and an **Open** button. That URL is private to you. Nobody else can reach your sandbox.
If the sandbox does not come up within 90 seconds, the card shows an error. Click retry. Cold starts can occasionally miss; a retry almost always works.
## Step 5. Work the exploit
Open the sandbox URL in a new tab. You are now looking at the vulnerable app.
Switch back and forth between the sandbox and the lab page. The **reproduce** step is the one to focus on first time round. It walks you through the exact request or input that triggers the bug. Run it. Watch what happens.
## Step 6. Answer the questions
Each step has a five choice question at the bottom. The submit button is locked for three seconds after the question loads. That is on purpose. The platform wants you to read.
You earn XP the first time you answer correctly. Wrong answers do not cost you anything. The explanation appears after you submit, so even a wrong answer teaches.
Move through all five steps. When the fifth question is answered, the lab is done.
## Step 7. Stop the sandbox
Back on the lab page, click **Stop** on the sandbox card. The container is destroyed within a few seconds. You can also let it expire on its own; it will be cleaned up automatically.
## What you just did
You spun up a real vulnerable app in an isolated container, exploited a real bug, read the patch that closed it, and answered five questions that verified you understood the chain. That is the loop. Every other lab works the same way.
A closer look at the five step structure.
How the isolated environment works and what to expect.