Platform
Security
RatCTF is a deliberately vulnerable training platform. That makes our own security posture a fair question to ask, so here is a straight answer: what we assess, how we assess it, and what the last assessment found.
Assessment summary — 13 September 2026
A technical security assessment was carried out against the RatCTF application, its supporting infrastructure, and the containment boundary that separates the vulnerable training machines from everything else. It followed NIST SP 800-115, the US standard for security testing, through all three execution phases — including live exploitation against production.
| Severity | Found | Open today |
|---|---|---|
| Critical | 0 | 0 |
| High | 2 | 0 |
| Medium | 6 | 0 |
| Low / Informational | 5 | 1 (accepted) |
Every finding above Low was fixed and then re-tested by re-running the original attack — not by reviewing the patch. Nothing found, at any point, allowed unauthenticated access to user data, administrative functions, or the Kubernetes control plane.
What was assessed
- The portal application — authentication, session handling, administrative and moderator routes, the public and internal APIs, and payment integration points.
- Supporting infrastructure — the Kubernetes clusters, network policies, access control, secrets handling, ingress and TLS, and the in-browser Pwnbox.
- The lab containment boundary — not the labs' deliberate vulnerabilities, which are the product, but whether a player who gets root inside a lab can reach the cluster, other labs, or the open internet.
Third-party services we use but do not operate — our payment processors, email provider, CDN and hosting control plane — were explicitly excluded. We cannot authorise testing of systems we do not run.
What changed as a result
Without publishing a roadmap of how to attack us, the remediation covered:
- Lab containment. Every deliberately vulnerable machine is now covered by a network policy that blocks outbound internet access. A rooted lab cannot be used to attack anyone else. This was the most important fix and it was verified by testing the exact escape that previously worked.
- Brute-force protection. Sign-in, password reset and verification codes are now rate limited.
- Browser hardening. A content security policy, clickjacking protection, and strict cookie transport are now enforced on every response.
- Credential handling. All generated codes now use a cryptographically secure random source, and password hashing was standardised at a higher work factor.
- Error handling and secrets. The application no longer runs in development mode, no longer returns internal errors to users, and refuses to start at all if a required secret is missing rather than falling back to a default.
Controls that were tested and held
- Every privileged route rejected unauthenticated access.
- Every internal API endpoint rejected both missing and invalid credentials.
- All lab containers running with elevated privileges — including the container-escape labs, where escaping is the whole point — were already correctly network-isolated.
- Cluster access control returned no permissions to lab workloads.
- Passwords are hashed, never stored in plaintext; reset tokens are random, hashed at rest, and expire.
- No credentials are committed to source control.
- Modern TLS with strict transport security.
- The Pwnbox runs unprivileged, with all Linux capabilities dropped, network-isolated, and on a hard time limit.
What this does not claim
An assessment is a point in time, not a guarantee. Specifically:
- The content security policy currently allows inline scripts, because the site uses many. It protects against clickjacking and restricts where scripts may load from, but it is not full cross-site-scripting mitigation. Moving to per-request script nonces is planned.
- One of our vulnerable side-projects is a news reader that genuinely needs to fetch external feeds, so it keeps outbound access by design. It is tracked as an accepted risk rather than quietly ignored.
- Our other subdomains were outside the scope of this assessment and will be covered separately.
- We use Google Analytics. That is a third-party tracker; it is disclosed on our Terms & Privacy page and it is not joined to your progress or submissions.
How we keep doing this
Assessments are not a one-off. The process — who runs them, what is in scope, what testing is permitted, how fast findings must be fixed, and the requirement to re-test every fix — is written down and published:
Read the Security Assessment Policy →
Found something?
The vulnerable machines on /challenges are fair game — that is what they are for. The portal, the cluster and other players' accounts are not; see Rules & Acceptable Use for the boundary.
If you find a real issue in the platform itself, report it to info@thexssrat.com. We will confirm receipt, fix it, and credit you if you would like to be credited. See also our security.txt.
Last assessment: 13 September 2026 · Accountable: Wesley Thijs, CEO & CTO, The XSS Rat · Detailed findings are held internally while any remediation is outstanding.