The blog without the vendor fog

Why we killed client-selected flag registration

A generated challenge used to let the browser register the answer it expected the server to accept. That sounds tidy until you notice the browser is controlled by the visitor. Worse, predictable shared challenge IDs meant one visitor could overwrite verification state for everybody else.

We retired that endpoint with HTTP 410. Generated challenges now verify locally and are explicitly unranked. The durable replacement will use server-issued challenge instances and signed solve receipts. Security work is frequently less glamorous than the landing page. It is also where trust comes from.

Your first flag: what the hell are you looking for?

A flag is a proof string such as THTB{your_answer}. The challenge gives you a deliberately limited target, an objective, and evidence. Your job is to understand the weakness and recover the proof—not spray random systems on the internet like a raccoon with nmap.

Start with the firewall challenge. Read the objective before touching tools, write down what you know, and use the first hint when you stop making progress. A hint that teaches you the next move is training. Copying an answer from shipped JavaScript is just robbing yourself with extra steps.

start the guided route

What is live, what is next, and what is not secretly finished

Today you can use browser exercises, daily challenges, downloadable artifacts, local gamification, optional account sync, and the forum. Hosted vulnerable VMs, paid subscriptions, team billing, verified rankings, and certifications are not live.

The next meaningful milestone is not twenty more decorative cards. It is one properly isolated hosted lab with server-proven completion, followed by signed receipts that make progress portable and defensible. Catalog size looks good in screenshots. Integrity creates a product.