Security

Reporting a security issue

How to report a security issue in the Web Hack List website or tooling: use GitHub private security advisories. Open source, no bug bounty, no payment.

Where to report

Report privately through GitHub security advisories on the repository that runs this site:

Open a private security advisory ↗

That form is private between you and the maintainer until an advisory is published. Please use it rather than a public issue for anything exploitable. If you cannot use GitHub at all, open a normal issue that says only that you have a security report and asks for a contact route — do not put the details in it.

Please read this first

• This is a volunteer open-source project. There is no bug bounty and no payment of any kind. Reports are welcome on those terms and credited in the published advisory if you want the credit.
• The site is a static archive. It has no accounts, no login, no database and no server-side code — it serves files. Findings that assume a backend usually do not apply here.
• Automated scanner output pasted without a working proof of concept will be closed. So will missing-header reports that have no exploitable consequence on a static, cookieless, credential-free origin.

In scope

• webhacklist.com and its published assets.
• The site code in the repository — the app shell, the archive reader, the PDF viewer and the build and reference tooling.
• Anything that lets preserved content escape its context: script execution from an archived document, the PDF reader, or the content-security policy.

Out of scope

• Vulnerabilities in the preserved research itself. The archive stores copies of published security research; exploit code and payloads inside a preserved document are the evidence, are meant to be there, and are served as inert text.
• Findings against the original websites the archive links to. Those belong to their own owners — report to them.
• Denial of service, volumetric testing, and anything that would degrade the service for others.
• Social engineering, physical attacks, and reports about the maintainer's personal accounts.

Testing rules

Test only against your own copy where you can — the whole site builds and runs locally from the repository. Against the live site, keep it to what a single browser can do by hand. Do not run scanners or floods against it, and do not attempt to reach anything beyond the public files.

What to expect

This is maintained in spare time, so a first reply may take a couple of weeks. Valid issues are fixed and published as a GitHub advisory with credit to the reporter unless you ask otherwise. Not every report will be treated as a vulnerability, and the reasoning will be explained when it is not.

Other kinds of report

A wrong byline, a bad capture, a dead link or a misattributed technique is not a security issue and is very welcome as a normal GitHub issue. If you are an author who wants a preserved copy of your own work changed or removed, open an issue and say so — that is honoured.