How a $10K bounty hunter turned YouTube's recommender into a private-video oracle

What happened

A researcher publishing under the handle javoriuski documented a chain of YouTube API bugs that let an attacker enumerate a target account's private and unlisted videos — content that, by definition, is supposed to be invisible to anyone the uploader hasn't explicitly shared it with. The writeup landed on Hacker News at 214 points, which for a single-source security post is well above the reflex-upvote line.

The technique didn't involve a broken permission check in the classical sense. There was no `if (user.canView(video))` returning `true` when it should have returned `false`. Instead, the researcher leaned on YouTube's recommendation and related-videos endpoints — the ML-driven surfaces that suggest what to watch next. Those endpoints, when queried in the right session context, would surface video IDs belonging to private uploads on other accounts. Once you have an 11-character video ID, the rest of the pipeline (thumbnails, titles, sometimes transcripts) leaked enough metadata to confirm what the video was and who owned it.

The vulnerability wasn't in the auth layer — it was in the recommender treating private videos as valid candidates and then emitting their IDs into a response the caller was authorized to receive. Google paid out, patched it, and the researcher published the post-mortem. Standard bounty ending. The interesting part is the shape of the bug, not the payout.

Why it matters

For twenty years, the security industry has trained developers to think about access control as a synchronous boolean check at the edge of a request handler. Can this session read this row? Yes/no. Frameworks, ORMs, and policy engines are all built around that model. It's a good model. It also completely fails to describe what's happening when a machine-learning system is between the user and the data.

Recommender systems don't ask permission questions. They ask relevance questions. "Given this user's watch history, what videos are most likely to keep them on the platform for another 90 seconds?" The candidate pool for that question, at Google's scale, is a mostly-undifferentiated soup of every video in the index. The privacy label on each video is metadata — a flag the ranking pipeline is *supposed* to respect, but which lives in a completely different subsystem from the ranker itself. When those subsystems drift, you get exactly this: a ranker that scored a private video highly and then handed the ID to a caller who wasn't the owner.

This is the same class of bug that has haunted RAG systems for the last two years — a retrieval layer pulls documents into a context window without re-checking whether the calling user is allowed to see them, and the LLM cheerfully summarizes the contents. The YouTube variant is more embarrassing only because it's happening at a company that has been shipping recommendation systems since before most of your engineers were writing production code. If Google's recommender can leak private video IDs, your internal Confluence-search-with-vectors project is almost certainly leaking rows too. You just don't have a 214-upvote HN post about it yet.

The community reaction is telling. Top comments on the HN thread aren't outraged — they're resigned. Multiple commenters described near-identical patterns they'd found in their own bug-hunting: internal search endpoints that happily indexed private objects, autocomplete APIs that leaked draft titles, notification feeds that surfaced object IDs the recipient shouldn't have known existed. The shared thread is that all of these are derived data surfaces — outputs computed from a private input by a pipeline the security team didn't audit as an access-control boundary.

What this means for your stack

The practical takeaway isn't "audit your recommender." Most of you don't have one. The takeaway is that any endpoint that returns IDs, titles, thumbnails, or embeddings computed over a corpus that mixes private and public data is now part of your auth surface, and it needs to be threat-modeled as such.

Concretely, three things worth doing this quarter. First, enumerate your derived-data endpoints: search, autocomplete, "related to," "people also viewed," activity feeds, notification digests, ML-generated summaries. For each one, ask whether the underlying corpus contains objects with per-row access control. If the answer is yes, you have a candidate leak. Second, push access filtering as far upstream as possible. Filtering after ranking is the pattern that bit YouTube — the ranker already saw the private video, scored it, and the filter step only removes it from the *final* response. If a downstream endpoint (thumbnails, metadata) accepts the ID directly, the filter never runs. Filter at the retrieval layer, not the presentation layer. Third, assume your vector index is a covert channel. If you built RAG over documents with mixed permissions and you're not re-checking authz on every retrieved chunk against the calling user, you have this bug. The fact that no one has published a writeup about your specific instance yet is not evidence of absence.

If you're on the offense side, the pattern to fuzz is: find any endpoint whose response depends on a private input but which returns to a caller who shouldn't have been able to see that input directly. Recommenders, search, and "similar to" APIs are the fat targets. The Google payout confirms bounty programs are treating this class as in-scope; the ambiguity is mostly gone.

Looking ahead

The uncomfortable trajectory here is that ML surfaces are getting bolted onto every product, and most of the teams doing the bolting have never been through a serious authz review. The recommender-as-oracle attack pattern is going to keep showing up — in enterprise search, in agentic assistants that read from mixed-permission corpora, in the "AI summary" feature your PM added to the sidebar last sprint. The YouTube leak is a nice, clean case study to point at the next time someone in a design review says "the ranker just returns IDs, it's fine." It's not fine. IDs are data. The ranker is a query. Treat it accordingly.