Flaming Shield Cyber Arena CTF 2026
Challenge Technical Specification
A short, opinionated brief for the security professionals authoring Flaming Shield CTF 2026 challenges. Read it once, then build to the tier you were assigned.
Rules
1 Original content only. No recycled public challenges. Frontier models have seen every public writeup, so reuse makes a challenge instantly solvable for any team running an AI agent. If the puzzle, exploit primitive, or storyline can be found via Google or a chat-with-PDF search, it does not qualify.
2 Build the assigned tier and AI-resistance mechanism. Each accepted slot ships with a target tier (T1–T4) and, for T3 and T4, a required AI-resistance mechanism. T1 may be AI-solvable by design; T2 should resist a casual one-shot prompt; T3 must implement its declared mechanism; T4 should resist current frontier agents end-to-end.
3 Exactly one flag, format LZDK{...}. Use lowercase ASCII, digits, and underscores inside the braces. The flag must never appear in shipped source, build artefacts, attachments, or client-side code. Where possible, generate it at container build time or per player instance so it cannot be shared between teams.
4 Ship the right shape for the challenge type. A service challenge ships as a Docker image (or docker-compose.yml) that starts cleanly on a fresh host with no internet access. A download challenge ships as the file or archive players receive. An OSINT or static challenge ships as the starting prompt, URL, or image — nothing more.
5 Hand back a private intended-solution writeup in Markdown. It proves the tier and the AI-resistance mechanism work, and serves as the reference solution for organizers during testing, grading, and player support. Propose a title of your choosing at the top of the writeup.
6 Declare your dependencies and confirm no shortcuts. State pinned tool versions, any victim-bot or oracle service the challenge expects from organizers, and any inputs received from earlier challenges in a chain. Confirm that no guess step, brute-force loop, or out-of-band trick trivializes the flag.
Difficulty Tier
T1 · Easy on-ramp
Easy on-ramp
Fully AI-solvable by design. Low points. Keeps no one blocked from progressing through the event.
T2 · Medium
Medium
May need a nudge past one-shot AI. Light structure or mechanic that asks for more than a single prompt.
T3 · Hard
Hard
Must implement an AI-resistance mechanism. Not one-shot solvable. Demands a real solver loop, not just a chat session.
T4 · Insane
Insane
Designed to resist current frontier agents end-to-end. Novel, chained, live, or concealed - and intentionally rare.
AI-Resistance Mechanisms
Novel / low-writeup
Custom patch, device or ISA, or a recent-paper technique with little or no training data available. The model can describe the area confidently but cannot lift a known solution because none exists publicly.
Hands-on real-world execution
Solving requires doing something practical - processing audio or radio signals, taking live measurements, running your own tools - not just reasoning about it. An AI can describe the steps but cannot execute them inside a chat session.
No brute-forcing
The challenge resists rapid automated guessing. It limits attempt speed, rotates internal state, or only opens a brief window per try, so the solver must be precise and patient rather than spamming attempts.
Multi-stage chaining
Multiple bugs or stages that only yield the flag when solved together. Each individual step looks innocuous on its own; the chain is the difficulty, and one-shot prompts cannot see the whole picture.
Hidden internals
The challenge is built to hide how it works - it resists being read or inspected directly. The solver has to run it and observe its behavior rather than just examine the code or a decomplication.
Challenge Categories
Slots are assigned first-come, first-serve at registration. As authors sign up, we publish the current distribution; if a category fills up, we'll flag it and ask later authors to pick a different one - usually one of the AI-resistant categories where we always have room. Reverse Engineering and OSINT have historically held up best against frontier AI agents, so we especially welcome submissions there.
Challenges may absolutely be built around your company's product, service, or technology stack. If you'd like the challenge to ship with your branding visible to players, include your logo with the other deliverables - see section 05.
Submission Deliverables
Each accepted challenge ships as a single submission folder containing four things and nothing else.
01 · The challenge
The challenge itself
For service challenges this is a Docker image or docker-compose.yml that brings the challenge up cleanly on a fresh host, exposes the player-facing port(s), and runs without internet access. For download challenges this is the file or archive players will receive. For static or OSINT challenges it is the starting prompt, URL, or image — whatever the player needs to begin.
02 · The writeup
Intended-solution writeup (Markdown)
A single SOLUTION.md walking from zero knowledge to the flag along the path you designed. State the category, tier, AI-resistance mechanism, and proposed title at the top, and include the literal flag string. Note any unintended solutions you spotted during your own testing — organizers decide whether to patch them or accept them.
03 · The dependencies
Dependency declaration
A short DEPENDENCIES.md (or top section of the writeup) listing every technical dependency — pinned base images, libraries, binary tools, services the challenge needs from organizers such as victim bots or mail relays — and every soft dependency, like chained inputs from other challenges or OSINT pointing at organizer-controlled assets. If your challenge needs nothing beyond a clean Docker host, say so explicitly.
04 · Public materials
Player-facing materials & branding
A short text bundle that ships with the challenge in CTFd: a public title, a 1–3 sentence player-facing description (no spoilers, template and an example will be provided), and three progressive hints that organizers can release if the challenge stalls. If the challenge is sponsored by your company, you can include your logo in description template.
Submit & Review
Ready to build?
We will send you detailed instructions regarding submitting challenges after registration. Every submission is reviewed against your intended solution writeup. If something is unclear, missing, or doesn't line up with the declared tier we may contact you.
Our infrastructure partner MetaCTF will provide these types of infrastructure:
Container challenges
These get deployed as per-team containers in our Kubernetes cluster. guidelines, but Authors should provide one or more Docker build definitions along with a basic .toml file that describes the challenge metadata. Multiple containers per pod will be supported. These should be limited to 1 CPU core and 1 GB RAM (if more resources are needed, please write to the coordinator for approval).
Static challenges
These consist of static files that are uploaded to S3 bucket and the players/teams get links to download them.
Other
If challenge authors wish to run other types of challenges (virtual machines, cloud challenges... etc) please write to the coordinator to discuss possible options.
Changelog
Tracked here so authors and partners can see what changed between versions of this spec. Newest first.
2026-08-13
Initial publication