Google VRP: An Authorization Bypass in NotebookLM That Can Permanently Lock the Owner Out

A walkthrough of an authorization gap in NotebookLM's Gemini import flow, and an argument for why locking out an owner is a different class of problem than editing their content.

Quick note — I built HackThrough . It turns real bug bounty writeups into interactive step-by-step challenges. This bug is on there. Go play it instead of just reading if that sounds interesting.

I've been doing bug bounty on and off for a while, mostly nights and weekends after my day job. Most reports resolve one of two ways: quick triage, quick reward, done. This one took a month of back-and-forth with Google's security team and ended in a rejection I still disagree with. Not because I lost, but because I think the rejection rests on a distinction that doesn't hold up once you look closely at what actually happened to the account that got locked out.

Here's the report, the reasoning on both sides, and why I think this is worth arguing about even with no bounty attached.

The setup

NotebookLM is Google's AI research tool. You feed it sources — PDFs, docs, links, and Gemini chat exports — and it reasons over them. Notebooks can be shared, and an Editor invited to a notebook can add and manage sources inside it. That's the intended design, and it's no different from Editor access in Google Docs.

Gemini also lets you export a chat straight into a notebook as a source, via a "move to notebook" action. When I tested this, the Gemini UI only listed my own private notebooks as valid targets. Notebooks shared with me by someone else never appeared in that list. That's a sensible restriction: your own private chat shouldn't casually end up inside a workspace other people can see.

The question I wanted to answer was simple. Is that restriction enforced by the server, or only by the interface?

What I did

I used two accounts. Account A owns a shared notebook and invited Account B as an Editor — ordinary collaboration, nothing adversarial about it yet.

From Account B, I opened gemini.google.com, created a chat, and clicked "move to notebook." As expected, Account A's shared notebook was absent from the list; only my own private notebooks were selectable. I picked one of mine, intercepted the resulting request in Burp Suite before it left the browser, and inspected the payload.

The request carried a plain notebook ID as a parameter. I already had Account A's notebook ID — it's visible in the URL as soon as you accept a share invite. I replaced my own ID with theirs and forwarded the request.

The server accepted it. My Gemini chat, from Account B, was added as a source inside Account A's shared notebook. Based on this one test, the server-side handler for this endpoint does not verify that the destination notebook is one the requesting Gemini session was permitted to target. I haven't tested other endpoints in the product, so I can't say how widespread this pattern is beyond this specific flow — but on this flow, the UI-level restriction and the backend behavior clearly disagree with each other.

The lockout

The injection itself would be a minor issue if it just meant an unwanted file in a notebook. What makes it significant is what NotebookLM does next: to protect the privacy of the newly added Gemini chat, it automatically disables the notebook's Share option.

As a privacy safeguard for the injected content, that behavior makes sense in isolation. The problem is what it does to Account A. Logging back in, the owner finds the Share control disabled. They cannot manage collaborators, cannot remove the Editor who triggered this, and cannot reshare the notebook with anyone else.

The obvious next move is to delete the injected source and get the Share option back. I tried this, and I could not do it: the delete control for that source was disabled, apparently because the owner doesn't hold the underlying permission on a Gemini chat they didn't create. I also could not reach it from the Gemini side, since notebooks shared with someone else don't appear on that person's Gemini dashboard.

In my testing, I found no path back to a working Share button and no path to removing the injected source once this state was triggered. I want to be precise about what I can and can't claim here: I did not exhaustively test every possible workaround Google's support flow might offer, such as a manual account recovery process outside the product UI. What I can say is that there is no UI-level recovery path, which for a self-serve product is the recovery path that matters to an actual user.

What Google said

I reported this in June with full reproduction steps and a POC video. The first response closed it on the grounds that the attack "requires the attacker to already be in control of the victim's account," through hacking or social engineering.

That framing didn't match what I'd actually done. Account B never touches Account A's credentials or session at any point; it acts entirely under its own authentication throughout. I laid that out clearly, and the report was reopened.

The second response was more substantive, and worth taking seriously on its own terms. Google's position was that Editors are already a trusted role with broad power over a shared notebook's contents — they can add, edit, and presumably damage what's inside it. Given that baseline, an Editor causing an administrative inconvenience doesn't clear the bar for a tracked security bug, especially since the same behavior wasn't reproducible with only Viewer access or without any access at all. That's a defensible position: if the impact requires a privilege the owner already granted voluntarily, the security boundary being described is fuzzier than it first appears.

Here's where I think that argument runs into a limit, though. It treats every action an Editor takes as belonging to one bucket — "things Editors can already do" — without separating what happens to the notebook's content from what happens to the notebook's ownership controls. Those are different bundles of trust, and most access-control systems, including Google's own IAM model elsewhere, treat them differently on purpose.

An Editor overwriting or deleting sources is recoverable: the owner can revert, restore, or simply remove that Editor and carry on. What I demonstrated is not recoverable through the product. The owner loses the Share control itself, permanently, with no in-product action available to reverse it. That's not a bigger version of content editing. It's a different category: the Editor role reaching into a permission that, by Google's own design, only the owner is supposed to hold.

So the real question isn't whether Editors are trusted — they clearly are. It's whether that trust should extend to permanently overriding the one control the owner role exists to protect: the ability to decide who has access at all. I don't think it should, and I don't think the Viewer-access bar Google asked for is the right test for that question, since it's measuring privilege escalation between roles rather than the irreversible loss of an owner-only capability.

I made this argument across several follow-up comments. A month after the initial report, the final decision came back: Won't Fix, Infeasible.

The core disagreement

Stripped of the specifics, this comes down to one question: is denying an owner the ability to recover administrative control the same category of risk as an Editor being able to modify content? I don't think it is, for a structural reason rather than a severity one. Content permissions and ownership permissions protect different things. Content permissions govern what happens inside the resource. Ownership permissions govern who gets to decide that in the first place, and they're supposed to sit above the roles they define — an Editor's actions shouldn't be able to reach up and disable the Owner's own controls. When they can, the role hierarchy has effectively collapsed, even if nothing inside the notebook itself was touched maliciously.

I'd also flag the strongest counterargument to my own position, so readers can weigh it themselves: this does require an Owner to have already extended Editor trust to the person who exploits it, and Google is right that Editors are expected to be capable of causing real damage. Reasonable people can disagree about whether an unrecoverable admin lockout is meaningfully worse than unrecoverable content damage, especially since Google didn't dispute the technical mechanism, only its severity classification.

Where I land is that recoverability is the deciding factor. A trusted collaborator going rogue is a risk every sharing feature accepts. A trusted collaborator being able to permanently and unilaterally revoke the owner's ability to fix that situation is a different, narrower, and in my view more serious problem — one that exists because of a specific backend gap, not because of the inherent risk of collaboration.

A lot of hunters would drop a report here once it's closed. I'm writing this up anyway because the underlying pattern is generic: any product with Owner and Editor roles should be able to answer, concretely, what happens if an Editor tries to sabotage the owner's control rather than the content, and whether there's a way back if they do. If there isn't, that's worth fixing regardless of what a single triage decision says.