A security company should be tested too. If you find a vulnerability in a HackIndex system, please report it. There is no bug bounty, but you get a personal message and, if you like, a mention. This page describes how that works and what you can expect, and also how HackIndex handles vulnerabilities it finds in other people's software. The policy follows the Coordinated Vulnerability Disclosure guideline of the Dutch NCSC.
Version 1.2, 11 November 2026.
Email your report to the address in security.txt, preferably encrypted with the PGP key. Include:
which system or URL it concerns
what you did and what you saw
how to reproduce it, with a screenshot if useful
Do not send along any data you came across. Reporting under a pseudonym is fine.
This policy covers hackindex.nl and its subdomains.
It does not cover systems of HackIndex clients: report a problem there to the client itself or to the NCSC. Nor does it cover services of other parties HackIndex uses, such as hosting and email: report that to that party.
Reports without demonstrable impact, such as:
missing headers or cookie settings without an abuse scenario
SPF, DKIM and DMARC
visible version numbers
clickjacking on a page without a sensitive action
self-XSS and logout CSRF
missing rate limits without consequence
TLS settings without practical abuse
scanner output without explanation
Do no more than needed to show the problem.
Do not copy, change or delete data. If you accidentally see other people's data, stop, delete what you have and mention it in your report.
No attacks that disrupt the service and no heavy automated scans.
No social engineering, phishing, spam or physical access.
Do not plant a backdoor and do not share your access with anyone.
Do not share the problem with anyone until it is fixed.
A reply to your report within 3 working days.
An assessment and an expected fix date within 10 working days.
After that an update at least every 14 days, until it is fixed.
Your details are only used for this report and not shared without your consent.
If you followed the rules, there is no police report and no legal action. If another party complains about your research, HackIndex explains that you acted under this policy.
There is no money reward, HackIndex has no bug bounty. You do get a personal message once it is fixed. If you like, your name is credited as the reporter when the fix is published.
HackIndex also researches open-source packages, plugins and browser and editor extensions. The results are on the Research page, with a reference: HI-SA for a vulnerability, HI-MA for malware. As long as there is no fix, it only says something is in progress, without the package name.
A maintainer is contacted through security.txt, SECURITY.md, a GitHub security advisory or the platform's reporting channel. If there is no reply after 14 days, a second attempt follows through another channel, and then the platform itself or the NCSC.
Then HackIndex found a vulnerability or malicious code in something you build or maintain. This is what happens next.
Is the report genuine? A report comes from an address on hackindex.nl and names a reference such as HI-SA-2026-001. In doubt, mail the address in security.txt yourself and ask.
It costs nothing. HackIndex never asks for money, a reward or an assignment in return for a report.
What is asked of you: confirmation that the report arrived, a fix and the version that contains it.
How much time you have: 90 days for a fix, publication follows 30 days later. Need more time? Send a mail, a deadline is open to discussion as long as a fix is being worked on.
What gets published: the affected and fixed versions, the severity, what users should do and the timeline. Normally only after the fix. Without a fix, after 90 days only a warning without technical details follows.
A maintainer gets 90 days for a fix. If it is nearly ready, 14 days can be added.
After a fix, publication follows 30 days later, so users can update. Earlier is possible if the maintainer wants that.
If there is no fix after 90 days, a warning follows with the affected versions and what users can do themselves, without technical details.
If the vulnerability is already being exploited, the deadline is 7 days.
If you are a maintainer and need more time, email. A deadline can be discussed as long as a fix is being worked on.
For malware there is no waiting period for the maintainer. Malicious code is reported straight to the platform, such as npm, the VS Code Marketplace or the Chrome Web Store. Publication follows as soon as the package is offline, or after 7 days at the latest if it is still online, so users can protect themselves. Indicators are published along with it, so you can check whether you are affected.
The reference, affected and fixed versions, the severity, the impact in plain language, what to do, the timeline, a CVE number and, with consent, the reporter's name. A CVE is requested through a GitHub security advisory or another CVE numbering authority.
