Rodrigo Braz

If anyone can ship an app in a few days, who checks it?

This is the request:

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

It has no cookie and no token. Huntarr accepted the write and sent back its whole configuration, including the API keys of every Sonarr, Radarr and Prowlarr instance it managed.

Ten years ago, a solo project like this took someone who could build the whole thing alone: a web UI, background jobs, integrations with half a dozen APIs, user accounts and 2FA. Getting that far usually meant you had already built a few systems and picked up some security on the way. That was never a guarantee. Solo projects shipped with serious holes long before AI. But the amount of work involved kept out a lot of people who hadn’t learned the basics yet.

That barrier is mostly gone. With a coding agent, one person can ship a useful product in a few days without knowing much about sessions, auth or API design. The product works, people like it, and they install it. Nobody notices what’s missing until someone reads the code, and it’s no longer clear whose job that is. The author may not know what to look for, and the users assume someone else already looked.

Huntarr was vibe coded, and the maintainer admitted as much. I’m using it as a case study because it’s exactly the kind of project that is now easy to build: lots of useful features shipped fast, a growing user base, no tests or review I could see, and an app that people trusted with the keys to every other app on their server.

Where Huntarr sat

A lot of people run a media server at home. Plex or Jellyfin plays the films and shows to the TV, phones and anything else in the house. Around it sits a set of apps that manage the library: Sonarr for TV shows, Radarr for films, Prowlarr to manage the indexers they search, and a download client that fetches what they find. Together they’re usually called the *arr stack. Most people run them as Docker containers on a NAS or a small home server, and wire them together with API keys so each app can control the others.

Huntarr ran next to Sonarr, Radarr, Prowlarr and the other *arr apps and searched them for missing items on a schedule. To do that, it held an API key for each one. Anyone who could read those keys could control the apps behind them, whatever security those apps had of their own.

Why these apps end up on the internet

These apps are meant to stay on the home network, but a lot of people open them up anyway. They want to add a show from their phone while they’re out, let family request films, or check on downloads from work. The quick way is a port forward on the router or a reverse proxy with a domain name, often with no VPN in front. At that point the app’s own login is the only thing between the internet and the server. In Huntarr’s case, that login could be skipped.

How I reviewed it

The review started with a question. On r/Huntarr I asked about the speed of development and the amount of code going in, and whether there were any guardrails in place. The maintainer told me he worked in cyber security, called me a “hater”, and banned me from the subreddit. That reply was the red flag that made me look at the code.

I didn’t do this the old way, reading every file by hand. Most of the review was done by an AI agent. I pointed it at the code, starting with authentication and sessions, because a mistake there exposes everything else, and asked it to look for ways in. Then I checked what it reported, and reproduced the worst findings against a running copy of the app.

Around that I put a few very basic security tools: bandit, which scans Python code for common security mistakes, pip-audit, which checks the dependencies for known vulnerabilities, and a script that calls the API without logging in. No fuzzing, no reverse engineering. Any maintainer could run all of it in CI, with or without an agent. The same kind of tool that lets one person build an app like Huntarr in a few days found most of these bugs once I asked it to look.

The review ended with 21 findings: 7 critical, 6 high, 5 medium and 2 about open-source practice, plus one more high finding that makes a critical one worse. The full write-up is in the review repo.

The worst finding

Huntarr’s auth code keeps a list of paths it lets through without a session, and /api/settings/general was on it. The route had no check of its own.

The response made it worse. After saving, the endpoint returned every setting, including the sections it hadn’t changed. That covered every connected app, with nothing redacted, so their URLs and API keys came back in clear text. Writing a harmless value like the timezone was enough to read all of it.

From a leak to account takeover

The bypass list had more problems. Some entries used substring or suffix matching instead of exact paths, so they let more routes through than intended.

The worst of these was 2FA setup. POST /api/user/2fa/setup worked without a session. With no logged-in user, it fell back to the first user in the database, the owner, and returned a new TOTP secret. A caller could generate a code from that secret, call /api/user/2fa/verify, and put their own authenticator on the owner’s account.

Some endpoints also trusted a setup_mode flag sent by the client. When it was true, the Plex link route skipped its session checks, and in the code the recovery key route skipped its password check. Separately, POST /api/setup/clear was open and reset the setup state, which is the first step to creating a new owner account.

These are beginner mistakes

None of these bugs are exotic. A path allowlist matched with substrings. An endpoint that echoes back every setting after a save. A function that falls back to the first user when nobody is logged in. A server that believes a flag the client sends. These are the mistakes you make the first time you build auth, before someone reviews your code or you get burned in production.

A coding agent writes the feature you ask for. If you never think to ask whether the settings endpoint needs a session, or what the response should leave out, it won’t bring it up.

Users can’t tell the difference from the outside either. Stars, downloads and a polished UI used to hint that a lot of work, and probably some experience, went into a project. Now they mostly show that people find it useful.

Making it reproducible

I published the review with a small lab. A Docker Compose file starts the stock Huntarr image, and a Python script that uses only the standard library sends the requests as an anonymous client and writes the results to JSON and Markdown. A GitHub Actions workflow ran both on every push.

The script tests eight cases, and seven reproduced. The eighth chains the settings write with a spoofed X-Forwarded-For header. It did not reproduce in CI.

To run it, clone the repo and run:

docker compose up -d huntarr
python3 scripts/prove_vulns.py

The project has been offline for a while, so you may need to find a mirror of the image. The results of the runs are committed in the repo under results/.

What happened next

Every one of these bugs had a small fix. Take the settings route off the bypass list. Redact the keys in the response. Stop falling back to the first user. Ignore setup flags sent by the client. Match paths exactly. None of it needed a redesign, and a test that calls each endpoint without a session would keep it fixed.

I posted the review on r/selfhosted in February 2026. The thread spread well beyond the subreddit, especially among Plex users. The project has since gone offline.

If you still run a copy of Huntarr, remove it, then rotate every API key it held, for Sonarr, Radarr, Prowlarr and any other app you connected. Removing Huntarr does not invalidate a key that someone may already have read.

What I check now

So who checks it? Part of the answer is the maintainer. The same agents that wrote the code can review it, as this review shows, but only if the maintainer asks them to and takes the findings seriously when someone else does. The rest falls on the people who install the app. Writing the code is no longer the hard part, so I look at what surrounds it, because that tells me whether anyone besides the author looked at the result. Before I install a self-hosted app, and before I ship one, I look for these:

As more apps get built this way, how many of us will check before we install one?