How a Security Researcher Hacked YouTube

If you’ve ever uploaded a private video to YouTube and wondered if it could still become public, the findings of independent bug hunter David Shütz will only heighten your concerns. Shütz discovered several ways to access private YouTube videos and extract information from user accounts. Here’s how these bugs worked and what they revealed about YouTube’s security.

How to Steal a Private Video

In December 2019, while participating in the Google Vulnerability Reward Program (VRP), David Shütz became interested in whether it was possible to view private videos on YouTube. When uploading a video, users can choose from three privacy settings:

• Public: The video is available to everyone and indexed by search engines.
• Unlisted: The video can only be viewed by those with a special link.
• Private: Only specific, registered users selected by the account owner can view the video.

From a hacker’s perspective, the third option is the most interesting. Shütz tried to view a private video he uploaded from another account by clicking every button and modifying the video’s URL, but YouTube consistently returned an access error.

He then decided to take an indirect approach, inspired by a common pentester tactic: if the main service is well-protected, perhaps a related service using its API is less secure. He targeted Google Ads, which interacts with many Google services, including YouTube.

Shütz registered a Google Ads account and tried to set up an ad campaign using the ID of his private video, but the system blocked this attempt. He then explored the settings in the ad account and found a “Video” section listing videos used for ads. Clicking a video preview opened an “Analytics” section with details and an embedded player. He noticed a “Moments” feature, allowing advertisers to mark specific moments in a video—useful for tracking when a product or logo appears on screen.

Analyzing proxy logs, Shütz found that each time he created a “moment,” Google Ads sent a POST request to /GetThumbnails with the video ID and a timestamp. The server responded with a Base64-encoded image—a thumbnail of the selected frame. By replacing the video ID in the request with the ID of his private video, Shütz unexpectedly received a frame from the private video. This was an IDOR (Insecure Direct Object Reference) vulnerability, allowing access to protected content.

However, this only allowed him to extract a single frame. To go further, Shütz wrote a Python script to automate requests, saving frames at 33ms intervals (for 24 frames per second), and then reassembled them into a short video. The resulting video was small, blurry, and low-quality, but recognizable—proof the method worked.

This method had three major limitations: you needed to know the private video’s ID, it only extracted video (no audio), and the quality was poor. Shütz reported the bug to Google, who paid him $5,000 and fixed the “Moments” feature to check video access rights. But Shütz didn’t stop there—he soon found another interesting bug in YouTube’s services.

I Know What You’re Watching!

The second bug Shütz found was even more intriguing. By sending a potential victim a link to a specially crafted web page, an attacker could access their YouTube watch history, links to private videos, liked videos, and their “Watch Later” list. Here’s how it worked.

Invisible Playlists

Even if you’ve only visited YouTube a few times, your account has several automatically created playlists:

• HL (History List): Contains your watch history.
• WL (Watch Later): Contains videos you’ve marked to watch later.
• LLB/LLD: Contains your liked videos (by modifying the first three characters of your channel ID).
• UUB/UUD: Contains all videos you’ve uploaded, regardless of privacy settings.

While the owner can see all videos in these playlists, other users can only see public videos. Still, these playlists contain a lot of information that could be valuable to attackers.

The Embedded Player

YouTube videos can be embedded on third-party sites using the YouTube Iframe Player, which has its own API for controlling playback and accessing data. Communication between the web page and the player uses the browser’s PostMessageAPI, allowing data exchange between the site and the iframe.

Shütz discovered that the player sends a lot of information to the web page, including details about the currently playing video. By using JavaScript, he could intercept these messages and extract data such as video IDs, titles, and more—even for videos in private playlists, if the user was logged in.

For example, the player.getPlaylist() method returns an array of all video IDs in the loaded playlist, and player.getVideoData() provides details about the current video. Although getVideoData() was undocumented, it still worked.

If a user is logged into YouTube and visits a site with an embedded player, the player is also authenticated and has access to the user’s playlists. This means the site owner can access the user’s watch history, liked videos, and more, simply by loading the relevant playlist and calling the API methods.

Proof of Concept

Shütz created a proof-of-concept site with an embedded YouTube Iframe Player that loaded the HL (History List) playlist from another of his accounts. When the playlist loaded, he called player.getPlaylist() and got a list of all watched video IDs. He could also access the “Watch Later” and liked videos playlists, and by reconstructing the channel ID, he could get the list of uploaded videos.

There was a limitation: private video IDs remained hidden on third-party sites, but videos set as “unlisted” (accessible only by link) were visible. Knowing the ID, an attacker could generate links to these videos and share them publicly.

Shütz reported his findings to Google and received a $1,337 reward. Google updated the embedded player to check access rights when loading playlists, and eventually patched the getVideoData() issue as well.

Conclusions

The bugs discovered by David Shütz show that vulnerabilities can arise from the interaction of multiple products developed by different teams within the same company—as was the case with YouTube and Google Ads. Sometimes, the right hand doesn’t know what the left is doing, leading to leaks that attackers can exploit.

As Shütz writes: “After you’ve tested a product for a while and understand how it works internally, it becomes more effective (and fun) to try unexpected actions the developers might not have anticipated. The better you understand the system, the more ideas you’ll have for breaking it.”

Testing new features and technologies before they’re fully polished is a good approach. But even in well-tested systems, a simple change to an identifier in a request can sometimes lead to a critical bug.