August 22, 2026

The bug that survived three years of code review

I’ve been auditing open source projects lately, hunting for real vulnerabilities in codebases that actual companies and people rely on…

By Mayssare

1 min read

I've been auditing open source projects lately, hunting for real vulnerabilities in codebases that actual companies and people rely on. This one's about Frigate, an open source NVR system thousands of people run at home to manage their security cameras.

Frigate had this feature where you search through motion detection history. You pick a camera you have access to, search its events, get results back. Nothing fancy. The kind of feature that gets built, tested, shipped, and forgotten about.

That's usually where the good bugs are.

The system uses role based camera access. Makes sense for a shared household, or a small business running a dozen cameras with different employees needing different views. You get access to the cameras you're supposed to see, and nothing else. The endpoint looked like this:

GET /api/{camera_name}/search/motion/{job_id}

Camera name in the URL, checked against your permissions. If you're only allowed to see front_yard, the system should stop you from peeking at server_room.

I sat with this endpoint for a while, because something about it felt off before I could even say why. The camera_name gets validated, sure. But the actual data comes from a completely separate identifier, the job_id. And nowhere in the code does anything confirm that the job you're pulling actually belongs to the camera you were just approved for.

Two different things being checked. Only one of them mattered.

So here's what that meant in practice. Say I only have access to front_yard. If I know, or can guess, a job_id from a motion search someone else ran on server_room, I send:

GET /api/front_yard/search/motion/{that_job_id}

The permission check passes, because yes, I'm authorized for front_yard. But the response hands me server_room's data anyway. Timestamps, movement intensity, activity patterns. A camera I was never supposed to have any visibility into, sitting right there in the response.

Here's the part that actually got my attention. I kept reading through the codebase after finding this, mostly out of habit, and found another feature doing the exact same kind of lookup, except this one did it right. It checked the job's actual camera field, not whatever camera name happened to be sitting in the URL. Same project, same bug class, same exact mistake, and somebody had already fixed it once. Just not here.

That's the thing about these bugs. They don't usually come from nowhere. Somebody already knew the right way to do it. It just didn't make it everywhere it needed to.

I wrote it up and submitted through GitHub's private disclosure process. The maintainer picked it up within days, which honestly doesn't happen often. We went back and forth a bit on severity, since what leaked was motion metadata rather than actual video footage, so it landed at Moderate instead of High. Published as GHSA-vff9–46ww-fjjm.

If there's one thing I keep relearning doing this kind of work, it's this: when you find a bug that's clearly a mistake, go look for its sibling. Check if the same pattern shows up somewhere else in the codebase. Maintainers fix the bug they know about. They don't always go looking for its twin.