Skip to content
HackIndex
Menu

Research

HackIndex researches open-source packages, plugins and extensions for vulnerabilities and malware. Vulnerabilities go to the maintainer, malware to the store or registry that spreads it.

vulnerabilities reported
5
confirmed by maintainers
3
CVEs assigned
1
malware analyses
1
All Vulnerabilities Malware 5 items
Research
Reference Subject Type Severity Status Date
HI-SA-2026-003 Unsafe deserialization in statamic/importer CWE-502 Vulnerability High Published 12 Nov 2026
HI-SA-2026-002 Access control not enforced in ai-openrouter-gateway CWE-862 Vulnerability High Published 7 Nov 2026
HI-SA-2026-001 Stored XSS in parallax/filament-comments CVE-2026-90943 ยท CWE-79 Vulnerability Critical Published 14 Sep 2026
HI-SA-2026-004 Inefficient regular expression Name follows after the fix Vulnerability High In triage Hidden
HI-SA-2026-005 Missing authorization Name follows after the fix Vulnerability Critical In triage Hidden

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.

From finding to publication

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

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

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.