Reports
Every incident gets an identifier in the form HXL-<year>-<number> and keeps it for good. Reports are
versioned rather than quietly edited: if something turns out to be wrong or new facts arrive, the version number goes up and the
change is stated in the report.
-
HXL-2026-001 Incident 24 Oct – 4 Nov 2026 · published 4 Nov 2026 · version 1
A deleted server, and six days of someone else’s spam on labs.hackxpert.com
A contractor account with full administrator rights deleted the server hosting the labs by mistake. The DNS record for
Read the full reportlabs.hackxpert.comkept pointing at the old IP address, the hosting provider handed that address to someone else, and their catch-all server answered our hostname with a generated spam blog for six days. No personal data was involved. The labs were rebuilt on a new server and back on their usual address nineteen minutes after we noticed.
That is the complete list. Nothing has been removed from this page since it was created.
What we publish, and what we don’t
HackXpert Labs is a deliberately vulnerable practice environment. Labs break, labs get exploited, and labs get rebuilt — that is the product working as intended, and none of it is an incident. What gets a report is anything that affected the service around the labs, or the people using it.
We publish a report when
- a public service was unavailable, or served content that was not ours, for more than an hour;
- anyone reached a system, account or credential they should not have;
- data belonging to a user was exposed, altered or lost;
- we lost a production host, a backup, or control of a hostname;
- we had to revoke credentials or remove access in a hurry.
We don’t publish a report for
- a single lab being broken, offline, or exploited the way it was designed to be;
- planned maintenance and rebuilds;
- scanner traffic, brute forcing and other background noise against a site whose entire purpose is to be attacked;
- vulnerabilities reported to us in the lab content itself — those get fixed, not written up.
The commitments behind each report.
- Published within a week of resolution. HXL-2026-001 went up the same evening the labs came back.
- Named root cause. If we do not know yet, the report says that instead of implying we do.
- A real timeline, including the embarrassing gaps. The first report states plainly that a deleted server went unnoticed for six days.
- Corrective actions with a status. Not intentions — a list with each item marked done, in progress or planned.
- Indicators where they help others. If a third party was involved, the report carries the details you need to check whether you saw the same thing.
- Versions, never silent edits. Corrections bump the version and say what changed.
How we rate impact
Rev. 3 of SP 800-61 leaves the impact scheme to each organisation. We use the three categories from Rev. 2, because they separate three things that are genuinely different: how much stopped working, what happened to data, and how hard it was to come back.
| Level | Meaning |
|---|---|
| None | No effect on anyone using the service. |
| Low | Minimal effect; a secondary feature degraded. |
| Medium | A service was unavailable to some or all users. HXL-2026-001 sits here. |
| High | No longer able to provide a critical service to any user. |
| Level | Meaning |
|---|---|
| None | No information was exposed, changed, deleted or otherwise compromised. HXL-2026-001 sits here. |
| Privacy breach | Personal data was accessed or exfiltrated. |
| Proprietary breach | Unpublished material — exam content, source, internal documents — was accessed. |
| Integrity loss | Information was changed or destroyed. |
| Level | Meaning |
|---|---|
| Regular | Recovered with the resources on hand, in the expected time. |
| Supplemented | Recovery needed extra resources or a rebuild from elsewhere. HXL-2026-001 sits here: the host and its hosting backups were gone, so the labs were rebuilt from source. |
| Extended | Recovery took far longer than it should have. |
| Not recoverable | Recovery is not possible; the response shifts to limiting the damage. |
Every report also carries a status: Open while it is still happening, Contained once it cannot get worse, Resolved once the cause is confirmed and the corrective actions are in place, and a monitoring window after that.
Standing rules that came out of incidents
Corrective actions from a report are not finished when the box is ticked — several of them became permanent rules for how this infrastructure is run. They live here so they outlive the report that produced them.
| # | Rule | From |
|---|---|---|
| 1 | A DNS record is removed or repointed before the host it points to is deleted or rebuilt. A hostname never outlives its server. | HXL-2026-001 |
| 2 | Contractors get restricted accounts with only the permissions the work needs. Nobody holds standing rights to delete production. | HXL-2026-001 |
| 3 | Deleting or rebuilding a server needs approval and a written record first. | HXL-2026-001 |
| 4 | API tokens need a named purpose, minimum scopes and an expiry, reviewed monthly. Automation and AI assistants never get delete rights. | HXL-2026-001 |
| 5 | Backups live outside the hosting account, because hosting backups are deleted along with their server. | HXL-2026-001 |
| 6 | Deletions, rebuilds and user changes raise a notification. | HXL-2026-001 |
| 7 | Each vulnerable lab runs in its own container with a read-only filesystem and no write access to the public homepage, so an exploit stays inside that lab. | HXL-2026-001 |
| 8 | Key pages are monitored from several regions and user agents, because cloaked content is invisible from our own browsers. | HXL-2026-001 |
| 9 | Secrets stay out of git, with secret scanning on every push. | HXL-2026-001 |
| 10 | One offboarding checklist covering hosting, GitHub, Kubernetes, password manager, email and social accounts — removing one account does not remove copied credentials. | HXL-2026-001 |
Found something? Tell us
Mail wesley@thexssrat.com with what you did, what you saw, and roughly when. Include the hostname. A rough description beats no report, and you will get an answer from a person.
Worth reporting
- Anything on our infrastructure rather than inside a lab: the hosting, DNS, certificates, the exam platform, the course platform, our GitHub organisation.
- Content on one of our hostnames that is not ours — that is what the first incident turned out to be.
- A lab that writes outside its own container, reaches another lab, or changes anything a different visitor sees.
- Secrets, tokens or credentials of ours that you found anywhere, including in a lab bundle where they should not be.
- Anything that lets you reach data belonging to another user on any of our services.
Not a finding here
- The labs being vulnerable. That is the entire point: XSS, SQLi, IDOR, CSRF and the rest are placed there on purpose, with flags behind them.
- Missing security headers, cookie flags or TLS niceties on the lab hosts themselves, unless they let you affect something outside your own session.
- Automated scanner output with no demonstrated impact.
- Lab flags. Keep them, enjoy them, do not report them.
There is no bounty programme. This is a free training site run by one person. What we can offer is a fast reply, a fix, credit in the resulting report if you want it, and our genuine thanks. Please do not run denial-of-service tests, do not attack the exam or course platforms, and do not go after other users’ data to prove a point — describe it and we will look.
If you just want the labs
They are at labs.hackxpert.com, free, and need no account. The labs are rebuilt and extended often, so an individual lab being down is normal rather than alarming — this page is for the times the whole service, or something around it, went wrong.
Questions about an incident, an exam booking or a certificate go to wesley@thexssrat.com.