Releases are cut as repo-level tags (v0.1.0, v0.2.0, v0.3.0, …), but only the latest release and the main branch are supported — fixes land on main and ride the next tag; nothing is backported. Please report issues against the latest commit on main.

If you are standing this kit up rather than reporting an issue with it, walk the organizer security checklist first. Every item on it is a deployment decision the kit cannot make for you, and most have no visible symptom when they are wrong.

Please use GitHub's private vulnerability reporting for this repository rather than opening a public issue:

1. Go to the repository's Security tab.
2. Click Report a vulnerability.
3. Describe the issue, the affected component, and steps to reproduce.

This opens a private advisory visible only to maintainers, so the report stays confidential while a fix is worked out.

Do not report vulnerabilities through public GitHub issues, discussions, or pull requests.

OWASP CTF in a Box is a deliberately-vulnerable-by-design training kit. The target applications it hosts (Juice Shop, DVWA, WebGoat, Security Shepherd, VulnerableApp, VAmPI, and any future module targets) are intentionally vulnerable — finding and patching their flaws is the point of the exercise. Please do not report vulnerabilities in the target apps themselves here; those belong with the respective upstream projects.

What we do want reports on is the kit's own infrastructure — the code that operates the event, not the practice targets it hosts:

• scorer/ — the judge and leaderboard scoring engine
• sync/ — the poll scoring transport
• apps/web/ — the contestant web app (auth, teams, admin panel)
• setup/ — ctf-setup.sh and event provisioning
• deploy/ — the optional cloud deploy modules (IAM roles, security groups, secrets handling, task definitions and deploy scripts)
• patches/ — the reference patches shipped for the targets
• scripts/, .github/workflows/ — CI, smoke tests, and automation

Examples of what's in scope: authentication or authorization bypass in the web app, a way to forge or replay a score submission, a way to escalate outside your own team's data, secrets handling issues, or a supply-chain concern in the kit's own build/CI pipeline.

• Jeopardy-module flags and quiz answer keys are stored in plaintext in Redis (ctf:classic:flag, ctf:quiz:key) and are readable by every /admin user — the admin edit forms return them verbatim, deliberately, so an organizer can fix a typo'd flag mid-event. Contestant-facing code paths never read either key. The secrecy boundary is /admin membership and Redis access, not encryption; organizers should grant admin accordingly. A bypass that exposes these keys to a non-admin is very much in scope.
• The scorer runs contestant-submitted code inside sandboxed containers — judging submitted code is the product. An escape from that sandbox is in scope; the fact that it executes submissions is not.

We aim to:

• Acknowledge a new report within 5 business days.
• Provide an initial assessment (confirmed, needs more info, or out of scope) within 10 business days.
• Keep the reporter updated as a fix is developed, and credit them in the advisory unless they ask to remain anonymous.

This is a community-maintained project run on a best-effort basis; response times may vary.