https://old.reddit.com/r/selfhosted/comments/1rckopd/huntarr_your_passwords_and_your_entire_arr_stacks/

Today, after raising security concerns in a post on r/huntarr regarding the lack of development standards in what looks like a 100% vibe-coded project, I was banned. This made my spidey senses tingle, so I decided to do a security review of the codebase. What I found was... not good. TLDR: If you have Huntarr exposed on your stack, anyone can pull your API keys for Sonarr, Radarr, Prowlarr, and every other connected app without logging in, gaining full control over your media stack.

The process

I did a security review of Huntarr.io (v9.4.2) and found critical auth bypass vulnerabilities. I'm posting this here because Huntarr sits on top of (and is now trying to replace them as well!) Sonarr, Radarr, Prowlarr, and other *arr apps that have years of security hardening behind them. If you install Huntarr, you're adding an app with zero authentication on its most sensitive endpoints, and that punches a hole through whatever network security you've set up for the rest of your stack.

The worst one: POST /api/settings/general requires no login, no session, no API key. Nothing. Anyone who can reach your Huntarr instance can rewrite your entire configuration and the response comes back with every setting for every integrated application in cleartext. Not just Huntarr's own proxy credentials - the response includes API keys and instance URLs for Sonarr, Radarr, Prowlarr, Lidarr, Readarr, Whisparr, and every other connected app. One curl command and an attacker has direct API access to your entire media stack:

curl -X POST http://your-huntarr:9705/api/settings/general \  
  -H "Content-Type: application/json" \  
  -d '{"proxy_enabled": true}'  

Full config dump with passwords and API keys for every connected application. If your instance is internet-facing - and it often is, Huntarr incorporates features like Requestarr designed for external access - anyone on the internet can pull your credentials without logging in.

Other findings (21 total across critical/high/medium):

• Unauthenticated 2FA enrollment on the owner account (Critical, proven in CI): POST /api/user/2fa/setup with no session returned the actual TOTP secret and QR code for the owner account. An attacker generates a code, calls /api/user/2fa/verify, enrolls their own authenticator. Full account takeover, no password needed.
• Unauthenticated setup clear enables full account takeover (Critical, proven in CI): POST /api/setup/clear requires no auth. Returns 200 "Setup progress cleared." An attacker re-arms the setup flow, creates a new owner account, replaces the legitimate owner entirely.
• Unauthenticated recovery key generation (Critical, proven in CI): POST /auth/recovery-key/generate with {"setup_mode": true} reaches business logic with no auth check (returns 400, not 401/403). The endpoint is unauthenticated.
• Full cross-app credential exposure (Critical, proven in CI): Writing a single setting returns configuration for 10+ integrated apps. One call, your entire stack's API keys.
• Unauthenticated Plex account unlink - anyone can disconnect your Plex from Huntarr
• Auth bypass on Plex account linking via client-controlled setup_mode flag - the server skips session checks if you send {"setup_mode": true}
• Zip Slip arbitrary file write (High): zipfile.extractall() on user-uploaded ZIPs without filename sanitization. The container runs as root.
• Path traversal in backup restore/delete (High): backup_id from user input goes straight into filesystem paths. shutil.rmtree() makes it a directory deletion primitive.
• local_access_bypass trusts X-Forwarded-For headers, which are trivially spoofable - combine with the unauth settings write and you get full access to protected endpoints

How I found this: Basic code review and standard automated tools (bandit, pip-audit). The kind of stuff any maintainer should be running. The auth bypass isn't a subtle bug - auth.py has an explicit whitelist that skips auth for /api/settings/general. It's just not there.

About the maintainer and the codebase:

The maintainer says they have "a series of steering documents I generated that does cybersecurity checks and provides additional hardening" and "Note I also work in cybersecurity." They say they've put in "120+ hours in the last 4 weeks" using "steering documents to advise along the way from cybersecurity, to hardening, and standards". If that's true, it's not showing in the code.

If you work in cybersecurity, you should know not to whitelist your most sensitive endpoint as unauthenticated. You should know that returning TOTP secrets to unauthenticated callers is account takeover. You should know zipfile.extractall() on untrusted input is textbook Zip Slip. This is introductory stuff. The "cybersecurity steering documents" aren't catching what a basic security scan flags in seconds.

Look at the commit history: dozens of commits with messages like "Update", "update", "Patch", "change", "Bug Patch" - hundreds of changed files in commits separated by a few minutes. No PR process, no code review, no second pair of eyes - just raw trunk-based development where 50 features get pushed in a day with zero review. Normal OSS projects are slower for a reason: multiple people look at changes before they go in. Huntarr has none of that.

When called out on this, the maintainer said budget constraints: "With a limited budget, you can only go so far unless you want to spend $1000+. I allot $40 a month in the heaviest of tasks." That's just not true - you can use AI-assisted development 8 hours a day for $20/month. The real problem isn't the budget. It's that the maintainer doesn't understand the security architecture they're building and doesn't understand the tools they're using to build it. You can't guide an AI to implement auth if you don't recognize what's wrong when it doesn't.

They also censor security reports and ban people who raise concerns. A user posted security concerns on r/huntarr and it was removed by the moderator - the maintainer controls the subreddit. I was banned from r/huntarr after pointing out these issues in this thread where the maintainer was claiming to work in cybersecurity (which they now deleted).

One more thing - the project's README has a "Support - Building My Daughter's Future" section soliciting donations. That's a red flag for me. You're asking people to fund your development while shipping code with 21 unpatched security vulnerabilities, no code review process, and banning people who point out the problems, while doing an appeal to emotion about your daughter. If you need money, that's fine - but you should be transparent about what you're spending it on and you should be shipping code that doesn't put your users at risk.

Proof repo with automated CI: https://github.com/rfsbraz/huntarr-security-review

Docker Compose setup that pulls the published Huntarr image and runs a Python script proving each vulnerability. GitHub Actions runs it on every push - check the workflow results yourself or run it locally with docker compose up -d && python3 scripts/prove_vulns.py.

For what it's worth, and to prove I'm not an AI hater, the prove_vulns script itself was vibe coded - I identified the vulnerabilities through code review, wrote up the repro steps, and had AI generate the proof script.

Full security review (21 findings): https://github.com/rfsbraz/huntarr-security-review/blob/main/Huntarr.io_SECURITY_REVIEW.md

What happens next: The maintainer will most likely prompt these problems away - feed the findings to an AI and ship a patch. But fixing 21 specific findings doesn't fix the process that created them. No code review, no PR process, no automated testing, no one who understands security reviewing what ships. The next batch of features will have the next batch of vulnerabilities. This is only the start. If the community doesn't push for better coding standards, controlled development, and a sensible roadmap, people will keep running code that nobody has reviewed.

If you're running Huntarr, keep it off any network you don't fully trust until this is sorted. The *arr apps it wraps have their own API key auth - Huntarr bypasses that entirely.

Please let others know about this. If you have a Huntarr instance, share this with your community. If you know someone who runs one, share it with them. The more people know about the risks, the more pressure there will be on the maintainer to fix them and improve their development process.

Edit: Looks like r/huntarr went private and the repo got deleted or privated https://github.com/plexguide/Huntarr.io . I'm sorry for everyone that donated to this guy's "Daughter College Fund".

Edit 2: Thanks for all the love on the comments, I'll do my best to reach out to everyone I can. People asking me for help on security reviews, believe me when I say I did little more than the basics - the project was terrible.

What was the purpose of that app ? To upgrade a media ? But radarr or sonarr can already do that.

To download media that is old. Without it, you have to periodically tell the *arr suite to download stuff. I tried it out, but it ended up causing more problems than it solved, so I got rid of it.

but it ended up causing more problems than it solved

Gee I wonder why

Oof. I ran this for a bit but ended up removing it because, in addition to searching for missing media, it also kept trying to “upgrade” my existing media. Not sure what quality reference it was using though - I sync Radarr/Sonarr with the Trash Guides and most of what Huntarr pulled for download got stalled at import because it had a lower quality score than what was already in my library.

Looks like the GIthub was taken down before this was even posted.

Yes, and their doc pages and personal site of the same name. Here's hoping they don't resurface the same code under a new name

I always thought Huntarr was a bit over engineered for what it did. Here's a script you can just throw into your crontab that does the same thing

https://github.com/angrycuban13/Just-A-Bunch-Of-Starr-Scripts/blob/main/Upgradinatorr/README.md

If they do hopefully someone will expose them again for this.

Vibe coding. Not even once.

Nice try AI. Trying to bandwagon jump on human hitpieces? I see through your lies!

This was a cool read. I have no way to verify if the assertions are true - I don't code beyond my yamls and some bash (and some wicked index/match formukas in excel) - but it took me on quite the journey.

Did the maintainer of that project post it here trying to get traction and everyone was sus AF about to being vibecoded and using cloud based AI models to parse tracker listings? Maybe that was in the selfhosted com

People asking me for help on security reviews, believe me when I say I did little more than the basics - the project was terrible.

Well, sometimes you have to just have someone who has the time/willingness to actually do the basics.

Unfortunately, hype and groupthink and all kinds of silliness ... or incompetence... can get in the way of that.

Great writeup!

Tbh I've been running this (not exposed of course) for a while now and never thought too much of it, it gave some weird vibes but functionally seemed pretty useful.

In retrospect it absolutely makes sense that the whole thing was just AI slop.

Password was Huntarr2

clicks

powershell

Uhh no thanks I'm good

This is a great writeup, talk about coming with receipts. Mf comes with automated CI reports of your shit. Hopefully huntarr's author is able to read and understand it instead of asking ChatGPT to summarise it.

Whoa, that's some pro cybersecurity work & communication skills (and willpower), bravo.

Yeah, it really helped unstick some items that were in my queue but for whatever reason never got grabbed. Suspect it was the way Sonarr/Radarr work their way through your monitored items but never get around to searching for some of them? Everything is also unexposed for me (why bother? I can add stuff through lists on Trakt, or just wait until I’m home, or WireGuard in to my box if I really need to) but I’ve turned it off. Will look for alternatives.

Suspect it was the way Sonarr/Radarr work their way through your monitored items but never get around to searching for some of them?

This is a common misconception, and is the exact thing Huntarr was meant to fix. The *arr stack doesn’t search for items on your list after it has been added. You can configure them to search when the item is first added, but there are no follow-up searches after that. None. Zero. Nada.

Instead, the *arr stack monitors RSS feeds from your configured trackers, and if it sees something that is on your list, it will grab the item. But it isn’t actively searching for anything on your list. It’s just getting a list of what was recently posted to the various trackers, and then comparing to your list of requested items.

But this presents a problem for lots of media. Especially older media that doesn’t get active re-releases or upscales. That content will simply sit on your Wanted list indefinitely, because nobody is posting them on your various trackers. And that’s exactly what Huntarr was meant to fix. It occasionally poked your *arr stack to tell it to actively search for content that was already on its list, instead of simply waiting around for it to pop up on an RSS feed.

But yeah, it was obviously vibe-coded BS. It was a neat idea, and did exactly what it said on the label. But it’s not worth the massive potential for abuse.

As someone who vibe codes for work (and also knows how to program without it) it’s capable of some crazy stuff that I didn’t think of that’s really cool. But I am not implementing user/pass or token authentication or anything like that into my code. It’s mostly UIs and algorithms and “how to do api with python backend” and whatnot. I have premium LLM with work, so it’s doing a lot of stuff, but still. Doing anything security related with an LLM and not reviewing it by hand is dumbfounding.

I just use recyclarr with trash guides. It just works.

100% on the RSS angle, but is there also an issue of a manually triggered search of your Wanted list not being able to get all the way through because of rate limits on your indexers? Or something similar?