# Responsible disclosure

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.

## How to report a vulnerability

Email your report to the address in [security.txt](https://hackindex.nl/.well-known/security.txt), preferably encrypted with the [PGP key](https://hackindex.nl/pgp.txt). 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.

## What is covered

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.

## What does not count as a vulnerability

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

## Rules

- 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.

## What HackIndex promises

- 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.

## Thanks

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.

## Research by HackIndex

HackIndex also researches open-source packages, plugins and browser and editor extensions. The results are on the [Research](https://hackindex.nl/en/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.

## Did you receive a report from HackIndex?

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](https://hackindex.nl/.well-known/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.

## Deadlines for a vulnerability

- 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.

## Malware

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.

## What is published

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.

Source: https://hackindex.nl/en/security