The vulnerability Google won't call a bug
A researcher found a way to leak private YouTube data through a comment. Google says it's not a security bug. That answer is more revealing than the exploit.
A researcher found a way to steal the titles of your private YouTube videos using nothing but a comment. Google looked at the report and decided it wasn’t a security bug.
He was testing Ask Studio, the AI assistant YouTube added to its creator dashboard so channel owners can ask things like “what are people saying about my last upload.” The flaw shows up in what happens when a comment isn’t feedback but an instruction. Edit a comment after posting it, since YouTube doesn’t re-notify the creator of edits, word it as a directive instead of an opinion, then wait for the creator to click one of YouTube’s own suggested prompts, which pulls every comment into the model’s context automatically. Ask Studio can’t tell a fan complaining about pacing from a hidden command telling it to reformat its answer around attacker-controlled links. Push that far enough and Ask Studio, which has authenticated access to private and unlisted video data, can be made to leak titles of videos nobody is supposed to see yet.
Google’s bounty team rejected the report. Their stated reason: it “required social engineering,” so it wasn’t being tracked as a security issue.
We have done this before
Commenters on the story reached for the obvious comparison: this is SQL injection again, twenty years later and one abstraction layer up. Same root cause both times, a system that mixes data and instructions in a single channel with nothing marking where one ends and the other begins. A 2008-era web form couldn’t tell a name from a command either, until parameterized queries drew a hard line between “this is data” and “this is code,” and injection stopped being an unsolved problem and became a solved one. Nobody ships raw string concatenation into a SQL query anymore. It would get you fired.
There is no equivalent fix for a language model yet. You cannot parameterize plain English. A comment and an instruction look identical to a system whose entire interface is “read text, do what the text seems to want.” That part is genuinely hard, and I don’t think Google is wrong to say so.
The rejection is the interesting part
Where Google loses me is the “social engineering” framing. Classic social engineering needs the attacker to reach the victim directly: a phishing email, a fake support call. Here the attacker never talks to the creator at all. The creator finds the comment because YouTube’s own product surfaced it, clicks a button YouTube itself suggested, and gets manipulated by an AI system Google built and shipped as trustworthy. The trust being abused is the creator’s trust in Google’s product, routed entirely through Google’s own interface. Calling that social engineering shifts the blame onto the person who did nothing but use the feature as designed.
It is also the more convenient answer. A patchable bug earns a CVE, a fix, maybe a bounty check. An architectural flaw, “the model cannot reliably distinguish data from instructions,” doesn’t have a patch to ship. Closing the ticket as “not a security bug” makes the exposure disappear from the tracker without anyone admitting the feature can’t currently be built safely.
Compare that to how Microsoft handled EchoLeak, a zero-click prompt injection flaw in 365 Copilot that let attackers pull data out of Word, Excel, and Outlook without the victim clicking anything. Microsoft gave it a CVE, a 9.3 severity score, and a public writeup, then spent months shipping mitigations: tighter classifiers, blocked auto-fetched images, restricted markdown rendering, before patching it this May. None of that solves prompt injection permanently. But treating it as a real vulnerability leaves a paper trail, a disclosed attack chain, and a set of defenses other teams can build on. Treating it as “not a bug” leaves nothing, and the next researcher who finds the same class of flaw somewhere else starts from zero.
Where this actually lands
Ask Studio and Copilot are the visible cases because researchers went looking and published. The pattern won’t stay confined to YouTube comments and Office documents. Every company currently racing to bolt an AI assistant onto a product with access to private data, support tickets, internal documents, banking transactions, is building the same trust-boundary problem, mostly without a security researcher checking their homework first.
I would bet the “it required social engineering, not tracking this” answer does not survive contact with a regulator asking why an authenticated assistant leaked private data. Financial services doesn’t get to close a breach ticket because the exploit was clever. Anyone shipping AI copilots into products that matter should plan for that standard to arrive at their door long before their bounty program is ready to call it a bug.