Every guided lab has the same five steps. The order matters; the platform expects you to move top to bottom, but the steps are not locked. You can jump between them with the step nav at the top of the page, or by clicking the hash links (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.
#brief, #locate, #reproduce, #patch, #harden).
Each step has two parts: a piece of writing on the bug, and one multiple choice question that checks whether you actually read it. The five questions together unlock the XP.
Step 01: Brief
What broke and why it matters. The brief is two or three paragraphs. It sets up the application, names the bug class, says what an attacker could do with it, and gives a sense of who was affected when the CVE landed. No code yet. No commands. Just context. The brief question is usually about scope: which versions are vulnerable, what the impact is, or what the attacker needs to pull the bug off. If you read the brief carefully, the question is easy. If you skipped it, the question will tell you.Step 02: Locate
The vulnerable function. This is where the source code appears. The platform shows the exact file and the exact lines that are wrong, with syntax highlighting. There is no hunting. The point is to read the code and understand why it is wrong, not to play hide and seek. Sometimes the locate section also shows nearby helpers or the call site, because the bug only makes sense in context. Read the whole block, not just the highlighted lines. The locate question is about what is wrong with this code. It might ask which variable is tainted, which validation is missing, or which assumption the function makes that does not hold.Step 03: Reproduce
Trigger the bug. This is the hands on part. The sandbox card on the right has a Launch button. Click it, wait for the container to come up, and follow the reproduction steps. The reproduction usually fits in one or two commands. A curl, a small Python script, a single URL. The platform avoids the sort of multi step reproduction where you need to set up half a CTF infrastructure to get a single shell. If a bug needs that much setup to demonstrate, the lab simplifies it. The reproduce question checks that you understood the trigger, not that you typed the command. It might ask what the payload achieves, what the response looks like when the bug fires, or what changes between a benign and a malicious request.Step 04: Patch
How the fix landed. The platform shows the actual upstream patch as a diff. Red lines are gone, green lines are new. You can read the original commit message if the lab links it. This is the step most people skim and most people lose XP on. The brief and the reproduce sections are flashier, but the patch is where the real lesson sits. Vendors fix bugs in specific ways for specific reasons, and reading those choices is most of what makes you good at this over time. The patch question is about the fix. It might ask what the new check guards against, why a slightly different patch would not have worked, or what the patched version returns in a previously vulnerable case.Step 05: Harden
What to take away. The defense section is short. It pulls back from this specific CVE and talks about the class of bug. What to look for in your own code, what tools catch it, which lint rules exist, what design choice would have prevented it in the first place. The harden question is the most opinionated of the five. It checks that you can apply the lesson to a different piece of code, not just recognise it in this one.Navigation between steps
The step nav at the top of the lab page shows you progress at a glance. A filled circle means the question is answered correctly. An empty circle means it is unanswered or wrong. You can move freely between steps. The platform does not force a strict order. If you want to peek at the patch before working through the reproduction, nothing stops you. (Be honest with yourself about whether that is actually how you learn.) If you leave the lab and come back, the page loads at the first unanswered question. If everything is answered, it loads at the brief.Markdown rendering and code blocks
Every step is rendered from markdown. Code blocks are highlighted in the language the original code was written in. The renderer strips anything that could execute (no scripts, no inline event handlers, nojavascript: links), so the page is safe to read even when the lab content itself describes attack payloads.
If a code block does not render the way you expect, it is almost certainly because the language tag is missing from the markdown source. The fallback is plaintext.
Sandboxes
How the container behind the reproduce step works.
Questions and XP
Scoring, dwell time, streaks.