Nobody jailbroke these AI assistants. The attackers spoke through a channel the assistant already trusted.

Forever Security’s summary table for its BragJack research has a row headed Zero clicks required, and it is ticked for all five browsers. The first CVE record the same post links to, CVE-2026-0628 in Google Chrome, describes the attacker as one “who convinced a user to install a malicious extension”, and its CVSS vector records user interaction as required.

Both statements are accurate, and the distance between them is the story. Once the extension is installed, the attack needs nothing further from the user. The installation is the click. It is also the only point in the whole sequence where a person, or a policy, gets to say no.

That matters because of what the extension could then do, and because a Mandiant case study reported the same day has the same shape in a different place. In one, an extension spoke to a browser’s built-in AI agent through a web page the agent was built to obey. In the other, an attacker took over a developer’s live AI coding assistant session and used it to install poisoned software. Neither report describes defeating a model. Forever says in terms that it did not use prompt injection and did not have to bypass the assistants’ guardrails.

What BragJack is

Forever Security, an endpoint security company, published two posts on 16 September 2026 by its researcher Gal Weizman: a general account and a technical write-up. Both describe one line of research across five products built on Chromium: Gemini in Chrome, Perplexity Comet, the agent in Microsoft Edge, Opera Neon, and the Claude in Chrome extension.

The architecture under attack is common to all five, and the technical post describes it well. Each assistant has a body, the part inside the browser that can read tabs, take screenshots, open files or click and type on the user’s behalf, and a brain, a web application on the vendor’s servers that tells the body what to do. The body accepts instructions only from pages it trusts. For Chrome that is gemini.google.com, embedded inside Chrome’s internal chrome://glic page. For Comet it is perplexity.ai, for Neon opera.com, for Claude in Chrome a page on claude.ai, and for Edge a marketing page at microsoft.com/en-us/edge.

Each of the five attacks is a way for an extension to speak as that trusted page. None of them touches the model.

The technical post calls its core technique DiNneR Serving. An extension holding the declarativeNetRequest permission can rewrite network traffic without reading it. It can remove or loosen the security headers a page relies on, such as its Content-Security-Policy, and it can redirect a script the page loads to a different script the attacker controls. Weaken the page, swap in your own code, and your code runs as the page the agent trusts.

Forever’s name for what follows is Prompt Forcing. Prompt injection hides an instruction inside content the agent happens to read, and hopes the model follows it. Prompt Forcing writes the entire prompt and delivers it through the channel meant for the user, so there is nothing for the model to be suspicious of. As far as the agent can tell, its own page asked.

Five browsers, five different mistakes

The design weakness is shared. The implementation mistakes are not, and each is worth reading on its own, because each is the kind of thing a design review has to catch.

What each exploit needed, and what the public record does not establish

Product	The mistake	What an extension reached	Fix on the record
Gemini in Chrome	Chrome stopped extensions scripting or debugging the Gemini page inside its privileged container, but did not stop them rewriting its network traffic. A redirected script ran as Gemini.	Direct commands rather than forced prompts: open any tab, including local file paths, and read it as text, PDF or screenshot; the profile email address and picture. The pane’s process held camera and microphone permission, which Forever says could have allowed hidden recording.	CVE-2026-0628, rated High by Google, CVSS 8.8 from CISA. Reported 23 November 2025, fixed in Chrome 143.0.7499.192 on 6 January 2026. Bounty $7,000.
Perplexity Comet	The built-in agent extension accepted messages from ten Perplexity addresses. Not all were protected like the main site. An extension removed the redirect on testing.perplexity.com and ran a script there.	Browsing history, screenshots, local files (an earlier block on file paths was bypassed with mixed case, FiLe:///), and an agent that would act on any prompt.	No CVE. No fix version or date stated. Bounty $7,000.
Microsoft Edge	A marketing page was given a private browser interface that places a prompt in the Copilot side panel. Edge added three safeguards. The research defeated all three, the last with a race between switching agent actions off and on.	An agent that would take actions on any prompt.	CVE-2026-55945, CVSS 4.2, published 3 July 2026. Bounties $2,000 and $3,000.
Opera Neon	Nothing stopped an extension running a script on opera.com, the origin the agent obeys.	An agent that would act on any prompt.	No CVE. No fix version or date stated. Forever says Opera had found the flaw independently and paid $900.
Claude in Chrome	A script on claude.ai forwarded the prompt attached to an onboarding button to the side panel. Another extension could create that button and click it.	An agent that would act on any prompt. Forever says Anthropic rated it medium severity.	No CVE. No fix version or date stated. Bounty $500 in the technical post, $600 in the summary table.

Two of the five have CVE records, and those two records are the only formal severity judgements in the set. They are far apart. Google rates the Chrome flaw High, and the CVSS score of 8.8 on its NVD record, added by CISA, has a network attack vector and needs no privileges. Microsoft scored its own Edge flaw 4.2, with a local attack vector and low privileges required, and its record describes the outcome as an attacker able “to disclose information locally”.

That spread is not a contradiction. The Chrome flaw let an extension reach local files and the camera through the browser itself; the Edge chain needed more permissions and more moving parts to reach a prompt. But it is a reminder that “hijacked five browsers” describes five findings of quite different weight.

Two phrases worth reading slowly

The general post makes two claims that are true in a narrow sense and misleading in the ordinary one.

The first is zero clicks. After installation, no click from the user is needed, which is what the table means. But two of the five exploits, Edge and Claude in Chrome, did need a click. They simply did not need the user to make it. Chromium grants certain sensitive actions only in the few seconds after a real user gesture, and the technical post gets past that by “extending the permissions array in manifest.json with the debugger permission”, then using the debugger to send a synthetic click that the browser treats as the victim’s own.

The second is the one ordinary extension with, in the technical post’s words, “a very standard manifest.json”. The manifest it prints asks for declarativeNetRequest and host access to every HTTPS site. Chrome’s own permissions documentation lists what a user is shown when an extension asks for those. The network rules permission displays the warning “Block content on any page”. The debugger permission, which the Edge and Claude exploits added, displays “Access the page debugger backend” and “Read and change all your data on all websites”.

None of that makes the research weaker. Content blockers ask for the network rules permission as a matter of course, and people accept these warnings every day, which is exactly Forever’s point. It does change where the defence sits. A single extension could carry all five attacks, but it would have to be installed, with broad permissions, and in two cases with the debugger permission as well. Every one of those is something an organisation can refuse centrally before any AI agent is involved.

A smaller point, because figures travel. The summary table’s bounties add up to $20,500. The technical post’s headline says $20,000. Adding the amounts in its own resolution sections gives $20,400, because Claude in Chrome appears as $600 in the table and $500 in the text. It changes nothing about the findings. It is the kind of discrepancy that turns into three different numbers in three different write-ups.

Who is selling what

Both publishers sell the remedy they recommend, and both reports are worth reading with that in mind.

Forever’s general post argues that endpoint detection tools cannot see this kind of attack because “there’s no malicious code involved”, and concludes: “You need Forever.” The research does not show that. The extension is code, installed through a route organisations already control, and the two flaws with public records were closed by browser patches from Google and Microsoft, not by an endpoint product.

Mandiant is part of Google Cloud, and its recommended controls name Google Cloud products: Artifact Registry for internal package traffic, Model Armor as a prompt firewall, VPC Service Controls for egress. The controls themselves are generic and sound. The product names are optional.

That is a statement about how to read the recommendations, not an accusation about the findings. The Chrome and Edge flaws are confirmed by CVE records and Google’s own release notes, and Mandiant’s case studies are frontline incident response work. Take the evidence at full weight and the sales conclusions at none.

The Mandiant case, read for what it says

Mandiant’s AI Risk and Resilience Report 2026, published on Google Cloud in September, carries eight case studies. The first is the one that made the headlines, and it is short: two paragraphs and two recommended controls. Read closely, it establishes less than the coverage implies, and something more important.

Case study 1: what Mandiant states, and what it does not

Mandiant states	Mandiant does not state
A threat actor compromised a software-as-a-service provider and hijacked an active AI coding assistant session on a developer’s workstation.	Which assistant, editor or model was involved, how the session was hijacked, or how the provider was first compromised.
The assistant recommended installing an external package that the attacker had poisoned, and the recommendation was accepted.	Whether a developer accepted it or the assistant ran it. The report uses both framings: the recommendation was accepted, and the assistant executed it.
The attacker installed an infostealer through a poisoned PyPI package and harvested GitHub OAuth tokens.	When any of this happened, how long the attacker was present, or how it was detected.
The Shai-Hulud worm spread across approximately 100 internal code repositories, stealing repository secrets and proprietary source code.	Whether any customer of the provider was affected. The only further victim it describes is another employee.
The attacker poisoned a package in the organisation’s official namespace, and another employee who pulled that version was infected.	Attribution. The report discusses the TeamPCP supply chain intrusions, which it tracks as UNC6780, in a separate section, and does not link them to this case.

The line that matters most is the first. By Mandiant’s account the attacker was already inside the provider and already had a live session when the assistant entered the story. The AI assistant was not the way in.

What it added was legitimacy. An install suggested by the tool a developer works through all day looks like work. The report does not say how the assistant came to recommend a poisoned package. The simplest reading of “hijacked an active session” is that whoever holds the session writes the prompts, in which case the recommendation was the attacker’s instruction delivered in the assistant’s voice. That is an inference, not a finding, and the report should not be quoted as saying it. It is also exactly what BragJack does inside a browser.

Two other cases in the same report sit close to this one. In case study 3, an attacker poisoned an internal AI repository and tampered with an assistant’s command-line hooks, which Mandiant says gave remote code execution “natively through the AI platform’s standard operational workflow”. In case study 5, a Mandiant red team used role-confusion prompt injection to persuade a client’s internal pipeline chatbot to clone sensitive internal repositories and push them to an external GitHub repository the testers controlled. Mandiant calls that the confused deputy problem: sanctioned tools, doing what they are allowed to do, for the wrong person.

The channel is the privilege

Put the two reports side by side and the common lesson is not about AI models at all.

Browser security has long rested on a clean rule: an extension can change web pages, but it cannot command the browser. Built-in agents quietly break that rule, because some web pages now can command the browser. An extension that can change the right page inherits the page’s authority. Every BragJack finding is a variation on that sentence.

The coding assistant is the same arrangement on a developer’s machine. A session can install packages, use the developer’s tokens and push to repositories. Whoever holds the session holds all of that, and the assistant does not know the difference.

This is where friendly names do their damage. A page called a marketing page is still a page that can command the agent. A button called onboarding is still a button that sends a prompt. A tool called an assistant, running in a session with a long-lived GitHub token, is still something that can install software and push code. None of those names describes what the thing is allowed to do, and what it is allowed to do is the only property an attacker cares about.

What to do

One detail in Chromium’s own policy documentation is worth knowing for the fourth and fifth steps. It states that from Chrome 154, applying runtime_blocked_hosts to an extension that has the debugger permission disables its ability to attach the debugger to anything at all. That is the capability the Edge and Claude exploits used to fake a user’s click.

The position

Forever’s research is good, and the most useful thing in it is not a vulnerability. It is the observation that each vendor, building an agent that takes orders from its own web page, then had to defend that page as if it were part of the browser, and none of the five fully managed it. Google protected the page from scripts and forgot network rules. Perplexity protected the main site and forgot the testing one. Microsoft built three safeguards and the research got past all three. Opera left its trusted origin open to extension scripts, and Anthropic, shipping an extension rather than a browser, could not shield its page from another extension at all. These are the companies best placed to get this right.

Mandiant’s case shows the same design problem on a developer’s workstation. There, too, the question was never whether the model could be tricked. It was who could put words in its mouth.

So the useful question for any vendor shipping an assistant that can act is not how well the model resists manipulation. It is this: list every page, origin, extension, hook and session your agent will accept an instruction from, and show what stops something else from speaking through each one.