# Research

HackIndex researches open-source packages, plugins and extensions for vulnerabilities and malware.

- [HI-SA-2026-003: Unsafe deserialization in statamic/importer](https://hackindex.nl/en/research/hi-sa-2026-003), Vulnerability, High, Published
- [HI-SA-2026-002: Access control not enforced in ai-openrouter-gateway](https://hackindex.nl/en/research/hi-sa-2026-002), Vulnerability, High, Published
- [HI-SA-2026-001: Stored XSS in parallax/filament-comments](https://hackindex.nl/en/research/hi-sa-2026-001), Vulnerability, Critical, Published
- [HI-MA-2026-001: Hidden spyware and adware in the ModHeader browser extension](https://hackindex.nl/en/research/hi-ma-2026-001), Malware, High, Published
- HI-SA-2026-004: Inefficient regular expression, Vulnerability, High, In triage
- HI-SA-2026-005: Missing authorization, Vulnerability, Critical, In triage

Package names and dates stay hidden until the maintainer has released a fix. That keeps users of those packages protected.

## Why HackIndex does research

Nearly every app runs on packages, plugins and extensions made by others. A vulnerability in one of those building blocks does not hit one app, it hits every app that uses it at once. Researching those building blocks and getting the flaws fixed makes them safer for everyone, HackIndex clients included.

It also keeps the knowledge sharp. What goes wrong in open-source code goes wrong in client code too: permissions that are not checked, input that is trusted too much, keys in the wrong place.

## What gets researched

Packages and plugins from the ecosystems HackIndex works in every day, such as Laravel, WordPress and React Native. And extensions for browsers and code editors: they run with broad permissions on a developer's computer, which makes them a favourite target for malware.

A vulnerability gets a CVE number where possible. That way scanners and administrators recognise it, and users know they have to update.

## How a vulnerability is reported

Malware takes a faster route: it goes straight to the store or registry that spreads it.

1. **Report**: Privately to the maintainer first, through the channel they point to.
2. **Confirm**: With evidence and a proposal for the fix.
3. **Fix**: 90 days by default, longer when the maintainer is visibly working on it.
4. **Publish**: Only after the fix, with a CVE where possible.

[All agreements in the responsible disclosure](https://hackindex.nl/en/security)

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

[All deadlines and agreements are in the responsible disclosure.](https://hackindex.nl/en/security)

## Separate from client work

Research happens separately from assignments. Client code is never used as research material, and a finding from an assignment never ends up on this page.