In February 2026, a security researcher published a review of Huntarr — a popular companion app for the *arr media stack — reporting that a single request with no login could return the API keys for every connected service. Within days the project’s subreddit was private and its GitHub repository was gone. The thread documenting it drew more than 19,000 upvotes, and then the story largely stopped being written about.
That silence is the problem. Thousands of people ran this software, and the question they actually need answered is not “was this one developer careless?” but “how do I judge the next app before I hand it my credentials?” This piece sticks to what is documented, marks clearly what is not, and turns it into a checklist you can use.
Ben-G — independent reviewer at Spineye. Research-based analysis: primary sources, linked and quoted. How we review · LinkedIn
What Was Actually Reported
The review covered Huntarr v9.4.2, pinned to a specific container image and commit — a detail worth noting, because it makes the claims checkable rather than vague. The researcher documented 21 findings: eight backed by automated proof-of-concept tests, of which four were rated critical and three high, plus three further issues found by reading the source (a zip-slip flaw, a path-traversal flaw, and an overly broad authentication whitelist).
The headline issue is simple enough to explain without any security background. Certain settings endpoints did not check whether the caller was logged in. Send a request to one of them, and the server answered with the full configuration — including stored passwords and the API keys for connected apps. In the researcher’s words, a single unauthenticated request “exfiltrates API keys for your entire media stack.”
| Reported issue | What it would allow |
|---|---|
| Unauthenticated settings endpoint | Reading the full config, including proxy passwords and API keys for Sonarr, Radarr, Prowlarr and Lidarr |
| TOTP secret returned to anonymous callers | Setting up two-factor authentication as someone else, enabling account takeover |
| Setup-clear endpoint reachable without login | Re-arming account creation on an already-configured instance |
| Zip slip and path traversal | Writing or reading files outside the intended directory |
An API key for Sonarr or Radarr is not a minor secret. It is full control of that service — what it downloads, where it writes files, what it connects to. If those keys leaked, the exposure is the whole stack, not one app.
The Detail That Makes This Sting
What elevated this from a routine bug report was the researcher’s account of how little effort it took to find:
“This took a basic code review and standard automated security tooling (bandit, pip-audit) — the kind of checks any maintainer should be running as part of normal development. No fuzzing, no reverse engineering, no exotic techniques.”
rfsbraz, huntarr-security-review
Both of those tools are free, open source, and take minutes to run against a Python project. That is the uncomfortable part for the rest of us: if standard tooling surfaces critical issues, the gap is not exotic attacker skill — it is that nobody ran the tools.
The researcher’s closing argument is the one worth carrying forward: “fixing 21 specific findings doesn’t fix the process that created them.” A patch closes today’s holes. A process stops tomorrow’s.
What Is Not Established
Plenty of coverage skipped this section. It matters, so here it is plainly.
Open questions and fairness caveats
- No independent reproduction has been published. The findings come with test code, which is far better than an unsupported claim — but no third party has publicly confirmed them.
- No disclosure timeline is stated. The published review does not say whether the maintainer was contacted privately before publication or given time to patch. Coordinated disclosure is the norm precisely because a public post exposes every running instance at once. Its absence here is a legitimate criticism of the process, whatever the findings’ merit.
- One test did not reproduce. The researcher says so himself: finding T4 failed in continuous integration, possibly needing a container restart to take effect. Publishing that against your own interest is a mark of good faith.
- The maintainer has not publicly responded. Taking a repository and subreddit offline is consistent with damage control, but also with someone overwhelmed. Without a statement, motive is speculation — and this article will not speculate. If the maintainer responds, that response deserves to be read.
- Characterisations of the maintainer’s conduct are contested. The review describes report removals and bans; that is one side’s account, and no adjudicated record exists.
If You Ran Huntarr
Treat the keys as exposed
Not because the exploit is confirmed against your instance, but because rotating an API key costs ten minutes and assuming you were fine costs everything if you weren’t.
- Stop the container. An app you cannot patch and cannot audit does not belong on a running stack.
- Rotate every connected API key — Sonarr, Radarr, Prowlarr, Lidarr and anything else you linked. Each app regenerates its key in settings; update the clients that use it.
- Change any password you stored in it, including proxy credentials, and anywhere you reused that password.
- Check whether it was internet-facing. Behind a LAN or VPN the blast radius is people on your network. Exposed through a reverse proxy or port forward, it is everyone.
- Review your *arr logs for downloads, path changes or connections you did not initiate.
The Real Lesson: How to Judge the Next App
Self-hosting trades a vendor’s security team for your own judgement. That is a fair trade — but only if you actually exercise the judgement. None of the checks below require you to read code.
| Signal | What good looks like | What should slow you down |
|---|---|---|
| Response to criticism | Issues answered, bugs acknowledged, fixes shipped in public | Reports deleted, critics blocked, discussion moved somewhere unsearchable |
| Who reviews the code | Several contributors, pull requests reviewed before merge | One person merging straight to main, no review step |
| Automated checks | A visible CI pipeline; security linters in the repo | No tests, no CI, no dependency scanning |
| Handling of secrets | Documented auth model; secrets via environment variables | Credentials in a config file the web UI can read back to you |
| Release discipline | Tagged releases with notes; security fixes called out | Only :latest, no changelog, no versioning |
And one structural habit worth more than all of the above: assume any self-hosted app can be compromised, and design so that it does not matter much. Keep hobby services off the public internet — a VPN or Tailscale costs nothing and removes most of the risk. Give each app its own credentials so one leak is not a master key. Do not reuse passwords across your stack. Huntarr’s blast radius was large because it was designed to hold the keys to everything else; that concentration is the risk, independent of any single bug.
Quick check: how exposed is your setup?
Where This Leaves the *arr Stack
Nothing here reflects on Sonarr, Radarr, Prowlarr or Lidarr themselves. They were the victims in this story, not the cause: their keys were held by a third-party companion app. The lesson is about the companion layer — the convenience tools that sit on top of a stack and, by design, know all of its secrets. Those deserve more scrutiny than the thing they are managing, not less.
Huntarr’s own value proposition was real; automating missing-content searches across several apps is genuinely useful, which is why so many people installed it. Useful and safe are separate questions, and the second one is on you to ask.
Frequently Asked Questions
What exactly happened with Huntarr?
In February 2026 a researcher published a security review of version 9.4.2 reporting 21 findings, including unauthenticated endpoints that returned stored API keys and passwords. Shortly after the report gained attention, the project’s subreddit was made private and its GitHub repository was removed from public view. No public response from the maintainer has been issued.
Were the vulnerabilities confirmed?
They were documented with proof-of-concept test code against a pinned version and commit, but no independent third party has publicly reproduced them, and there has been no maintainer response. The researcher also noted that one of his own tests did not reproduce in continuous integration.
Should I rotate my *arr API keys?
If you ever ran Huntarr, yes. Rotation takes minutes and removes the risk entirely, which is a better trade than waiting for certainty about whether your instance was reachable.
Is the *arr stack itself insecure?
No. Sonarr, Radarr, Prowlarr and Lidarr were not the subject of the review. The reported issue was in a third-party companion app that stored their credentials.
How do I check if my self-hosted apps are exposed to the internet?
Check your router for port forwards and your reverse proxy for which services it publishes. The safest default is to expose nothing directly and reach your services through a VPN or a mesh network such as Tailscale.
Does this mean self-hosted software is unsafe?
No — but it does mean the security review that a commercial vendor would run is now your job. Judge projects on how they respond to criticism, whether more than one person reviews the code, and whether basic automated checks are visibly in place.
Can I still get Huntarr?
The official repository was taken out of public view. Copies and forks may circulate, but running unmaintained software with publicly documented critical findings is a bad idea — and there is no patched version to point to.
What should a maintainer do when a report like this lands?
Acknowledge it publicly, state which findings are confirmed, ship a fix with a version number, and tell users what to rotate. Silence and removal leave users unable to judge their own risk, which compounds the original problem.
Sources
- rfsbraz/huntarr-security-review — the researcher’s published findings, test code and methodology (primary source)
- PiunikaWeb, 24 February 2026 — reporting on the incident and the aftermath
- r/selfhosted — community discussion and user advisories
- Official projects referenced: Sonarr, Radarr, Prowlarr
If Huntarr’s maintainer publishes a response, this article will be updated to reflect it.
For tools that hold up to this kind of scrutiny, our Dawarich review looks at a self-hosted app whose developer answers criticism in public, and the Brows3 review covers a young project that shipped fixes within days of community pushback. More in the Spineye blog and our reviews section.