§ — disclosure policy · last updated 2026-09-02
Coordinated disclosure.
Both directions.
Scope
Our work is memory-corruption vulnerabilities in open-source infrastructure — hypervisors, mail servers, ML runtimes, and the libraries underneath them. Reports about those systems are what this page exists for. Reports about hackicker.com itself, or anything else we operate, are welcome too.
How to report
Email security@hackicker.com. Include the affected component and version, a reproducer or proof of concept, and your read on impact. Plain text is fine. No forms, no portal, no ticketing queue — a human reads it.
Response timeline
We acknowledge within 48 hours. We triage — confirmed, needs more detail, or out of scope — within 7 days. Confirmed reports get a fix plan and a target disclosure date, then status updates until the issue closes.
When we report upstream
Findings from our own systems go to the maintainer privately first, with a patch where we can write one. The default disclosure window is 90 days from maintainer acknowledgment. It moves earlier or later by mutual agreement — maintainer release schedules win when they're reasonable. If a maintainer goes silent past the window, we publish the finding with a note saying so.
Safe harbor
Good-faith research that follows this policy will not draw legal action from us. Test only what you own or are authorized to test, do not access, alter, or destroy data that isn't yours, stop at proof of impact, and report promptly. That is the same courtesy we ask for when we report to you.
security.txt
The machine-readable version of this policy lives at /.well-known/security.txt, with /security.txt redirecting to it. It carries the same contact addresses and an expiry date, and it is the file scanners should trust.