BragJack [Technical Overview]: How We Hijacked Top 5 Browsers' Internal Agents With Just One Single Extension
Technical deep dive showing how one low-permission extension hijacked built-in agents in 5 browsers: Chrome Gemini, Comet, Edge, Opera Neon and Claude in Chrome, earning 2 CVEs.
Extract
TL;DR In its recent discovery, the Forever Security Research team showed how 5 different browser agents were completely compromisable with any ordinary extension. The achievable impact ranged from accessing local files, browsing history, camera & microphone, taking screenshots of tabs, and more. These classes of impact were mostly achievable by a Prompt Forcing attack, which was possible via varying instances of security flaws. This research was found effective against Gemini Live in Chrome, Perplexity Comet, Microsoft Edge Actions, Opera Neon, and Claude in Chrome, yielding 20,000$ in bounties and 2 CVEs assigned. This post is a technical deep dive into these vulnerabilities and their exploitations. For the main story, read further here. Impacted Browsers Impact \ BrowserChromeCometEdgeOpera NeonClaude in ChromeCVEs discoveredCVE-2026-0628CVE-2026-55945Local file access✅✅❌❌❌Microphone & camera access✅❌❌❌❌Browser agent hijack❌✅✅✅✅Browser profile leak✅✅❌❌❌User history leak❌✅❌❌❌Screenshot ability✅✅❌❌❌Zero clicks required✅✅✅✅✅Bounty$7,000$7,000$5,000$900$600 Before jumping into each of the 5 BragJacks, it’s important to establish a couple of points: 1 Extension vs 5 Browsers Every browser impacted in this research was Chromium-based, and they were all attackable with a very standard manifest.json, which allowed us to use the same extension for all 5 attacks: { "manifest_version": 3, "name": "BragJack", "version": "1.0", "permissions": ["declarativeNetRequest"], "host_permissions": ["https:///"], "declarative_net_request": { "rule_resources": [ { "id": "glic", "enabled": true, "path": "glic_rules.json" }, { "id": "comet", "enabled": true, "path": "comet_rules.json" }, { "id": "neon", "enabled": true, "path": "neon_rules.json" }, { "id": "egde", "enabled": true, "path": "egde_rules.json" }, { "id": "claude", "enabled": true, "path": "claude_rules.json" }, ] } } The part that’ll actually change between attacks is the contents of rules.json, which is where the DNR (declarativeNetRequest) rules are defined. DiNneR Serving A key component of all 5 attacks is DNR permissions. Broadly, they allow extensions to preconfigure how network requests are handled. For this research, they are mostly interesting for two main powers they offer: Weaken security headers - such as Content-Security-Policy, X-Frame-Options, etc, that may interfere with the next stage; Execute code by Redirecting JavaScript resources - make a request to good.com/a.js to serve …
Explained
What happened
Researchers at Forever Security hijacked the built-in AI agents of five Chromium browsers, Gemini Live in Chrome, Perplexity Comet, Edge Actions, Opera Neon and Claude in Chrome, with one ordinary extension. It asked only for declarativeNetRequest and https://*/* host permissions. The work earned about 20,000 dollars in bounties and two CVEs, CVE-2026-0628 and CVE-2026-55945.
The Chrome case shows the pattern:
- Gemini in Chrome has a privileged internal page,
chrome://glicor "the body", that embeds the normal web appgemini.google.com, "the brain", in a WebView. - Chromium blocks extensions from debugging or injecting content scripts into that WebView, but it forgot to block DNR rules inside it.
- The extension uses DNR to strip the CSP header and loosen
document-isolation-policy, then redirects a harmless lazy-loaded script ongstatic.comto an attacker script. - That script now runs as
gemini.google.cominside the privileged embedder. It skips the AI entirely and sendspostMessagecommands such asglicBrowserCreateTabandglicBrowserGetContextFromFocusedTabdirectly. - Result: read any site, any
file://path, take screenshots, leak the profile email, and reuse the camera and microphone grants of the Gemini pane. Zero clicks.
Why it works
These agents split into a trusted browser-side "body" and a web-origin "brain" that decides what the body should do. The body trusts any message from the brain origin. So whoever can run code in the brain origin owns the body. DNR gave a low-privilege extension a path to rewrite headers and swap scripts in exactly that origin. The authors call this prompt forcing: you do not trick the model, you speak for it.
The bigger pattern
This is a classic confused deputy and privilege boundary bug, now with an agent in the middle. It is not prompt injection. The model never sees the attack. The new part is that browser vendors put powerful capabilities behind a web app origin and treated that origin as the security boundary, while extension network APIs could still tamper with it. The researchers call the header-weakening plus script-redirect combo DiNneR Serving and say it works beyond these five products.
What it means in practice
- If you build an agent with a planner and an executor, authenticate the commands the executor accepts. Origin checks alone are not enough when anything can inject code into that origin.
- Treat any API that can rewrite headers or redirect scripts as code execution in the target origin.
- Keep the capability set of the executor small and require user confirmation for file, camera and cross-site reads.
- For enterprise fleets, audit extensions with
declarativeNetRequestplus broad host permissions, and keep browsers patched. - In AI products generally, threat model the channel between the model output and the tool runner, not just the prompt.