blogForever Security Research·27 Oct 2026·Gal Weizman

MaXSS: Chrome Extension MaxAI Vulnerable to UXSS Puts 1,000,000 Users at Risk

The MaxAI Chrome extension, with 1M installs, exposes extension-only privileges to any web page, enabling universal XSS, screenshots and request interception.

Read original on forever.security

vulnerability-research LLM Security web-platform

Depth 4/5Score 5.28

Extract

TL;DR Forever Security Research has discovered a critical vulnerability in the MaxAI Chrome extension. The extension is supported by every Chromium-based browser and is installed on over 1,000,000 devices (According to Chrome and Edge stores). The vulnerability allows any arbitrary website to invoke special permissions that are normally reserved for extensions. All it takes for the attack to work is visiting a malicious website and having the extension installed (no authentication/interaction required). The vulnerability allows attackers to: Query currently opened tabs and hiddenly open new ones to any website. Take screenshots of any website. Intercept network requests and storage of any website. Run code on any website (aka Universal XSS). In some cases, access to arbitrary files from the local operating system (in some cases). This translates to significant impact, allowing attackers to: Access and leak any type of information across any website the victim is logged into. Perform any action on behalf of the user on any website the victim is logged into. Read files and folders from the victim’s computer (in some cases). Attempts to contact the vendors regarding this vulnerability failed. Given its high severity, we decided to make this information public so users are aware of the risk. Additionally, as the official owner of the Chrome Web Store, Google’s security teams were informed of this. MaXSS vulnerability was just one out of two vulnerabilities we found in the scope of this research - read about Spyder vulnerability here This blog post presents a technical breakdown of this vulnerability. Read the main post here Background To demonstrate the flaw in MaxAI and its impact, it’s first important to understand the product. MaxAI is an agentic side panel, implemented as a standard Chrome extension. This report assumes the reader is familiar with both. If you are not familiar enough with agentic side panels, refer to our agentic side panels cover to learn more. If you are not familiar enough with standard Chrome extensions architecture, refer to our Chrome extensions architecture cover to learn more. Vulnerability The vulnerability was the result of two significant problems: MaxAI implements the communication channel between webpages and its content-scripts unsafely. MaxAI designs APIs that are too powerful, too general, and too permissive. Zero filtering on incoming messages MaxAI injects a UI component into the sites the user visits, allowing them to …

Explained

What happened

Forever Security found a universal cross-site scripting flaw in the MaxAI Chrome extension, installed on over 1,000,000 devices. Any website the victim visits can borrow the extension full permission set, with no clicks:

MaxAI injects a content script into every page that listens for window.postMessage events to talk to its background service worker.
The listener does no origin or sender check in practice: a page can post a message shaped like {eventType: "BROWSER_EXTENSION_FEATURES__RUN_BACKGROUND_FUNCTION", data: [...]} and the content script forwards it to the background.
The background exposes a command runBackgroundFunction that looks up command and commandFunctionName in a dictionary Ty and calls it with page-supplied arguments.
Ty contained every extension API MaxAI holds: tabs, scripting, declarativeNetRequest, storage, management, windows and more.
So a malicious page can run tabs.query({}) to read the URLs and titles of all open tabs (a full Same-Origin Policy read bypass), captureVisibleTab for screenshots, scripting.executeScript for code execution on any site (universal XSS), intercept requests, and in some cases read local files.

Why it works

Two failures compound. First, the message channel between the untrusted page and the privileged extension had no authentication, so the page could speak as if it were the extension UI. Second, the exposed API was a generic dispatcher over the full permission set rather than a small set of specific, validated actions. Either flaw alone is bad; together they hand every page the extension privileges.

The bigger pattern

This is a confused deputy via an unauthenticated postMessage bridge, the most common class of browser-extension bug. window.postMessage is broadcast to any script in the frame, so a listener that does not verify event.origin and event.source trusts the attacker. Exposing a reflective callFunction(name, args) API across a trust boundary is the web version of an eval sink: it turns a narrow channel into arbitrary capability. Browser extensions are a large, under-audited supply-chain surface sitting above the Same-Origin Policy.

What it means in practice

On any postMessage listener, verify event.origin against an allowlist and check event.source is the expected window. Treat every inbound message as hostile.
Never expose a generic dispatch that maps a string to a privileged function with caller-supplied arguments. Define specific, narrowly scoped message types and validate each one.
Apply least privilege: an extension should request only the APIs it needs, so a bridge bug leaks less.
Prefer chrome.runtime messaging with sender checks over window postMessage for page-to-extension communication, and keep privileged logic behind explicit, typed handlers.
For teams and fleets: inventory installed extensions, especially AI side panels with broad host_permissions, and remove or block ones that are unmaintained or unresponsive to disclosure. Any page a user visits can reach these.