Brash Exploit Puts Chromium Browsers at Risk – A Deep Dive

TLDR

Brash is a new exploit that crashes Chromium‑based browsers with one crafted URL.

It abuses an un‑throttled document.title API to flood the UI thread and freeze the browser.

What happened

Security researchers discovered a flaw in the Chromium rendering engine. The flaw is triggered by the document.title API. The API allows JavaScript to change the page title at any time. Chromium does not limit how fast these changes can occur. The lack of rate limiting creates a race condition on the main thread. An attacker can send a single malicious URL that runs JavaScript on load. The script prepares a series of unique hexadecimal strings. These strings are stored in memory and then emitted in rapid succession. Each emission updates the document.title property. The updates are queued on the UI thread. The queue grows faster than the thread can process. Eventually the thread stalls and the browser becomes unresponsive. The researchers named the technique “Brash”. Brash consists of three distinct phases. Phase one builds a pool of unique strings. Phase two injects bursts of title updates using the pool. Phase three saturates the UI thread until it collapses. The attack can be timed to fire at a specific moment. Timing makes the exploit useful for targeted denial‑of‑service. The payload does not need additional network traffic after the initial URL. The entire crash is achieved with a single request. Google has been notified of the issue. No public fix has been released at the time of writing.

Why it matters

Browser stability is a core security guarantee. Users expect a browser to stay responsive. When a browser hangs, users lose access to web applications. Attackers can leverage a hang to force a page reload. A forced reload may discard unsaved data. In enterprise environments, a crash can interrupt critical workflows. The exploit works without user interaction beyond opening a link. Phishing emails can embed the malicious URL. A single click can bring down a browser on any device. The impact is not limited to desktops. Chromium powers browsers on Windows, macOS, Linux, Android, and ChromeOS. All of those platforms inherit the same vulnerability. The exploit demonstrates how a simple API can become an attack vector. It also shows the danger of missing rate limits in high‑frequency APIs. The technique can be adapted to other APIs that lack throttling. If left unpatched, the flaw could be weaponized in larger campaigns. Attackers could combine Brash with ransomware delivery. They could crash a browser, then serve a malicious payload while the user is distracted. The exploit also raises concerns for embedded webviews. Many mobile apps use Chromium‑based webviews. Those apps inherit the same crash condition. Developers must consider the broader attack surface.

Who is affected

• Google Chrome (all stable, beta, and dev channels that use the current rendering engine)
• Microsoft Edge (Chromium‑based versions released after 2022)
• Opera, Vivaldi, Brave, and other Chromium‑derived browsers
• ChromeOS devices that run the Chrome browser
• Android WebView and Chrome for Android
• Any third‑party application that embeds a Chromium webview (e.g., Electron apps, Slack, Discord, VS Code extensions)

Firefox, Safari, and legacy non‑Chromium browsers are not vulnerable because they implement a different title‑handling mechanism.

How to check exposure

Step 1 – Identify the browser version. Open the browser’s About page. Record the major version number. Versions prior to the upcoming patch are at risk.

Step 2 – Verify the document.title throttling status. Open the developer console (F12). Run the following snippet:

let start=performance.now();
for(let i=0;i<10000;i++)document.title='test'+i;
console.log('Duration:',performance.now()-start);

If the duration exceeds a few hundred milliseconds, the browser is likely vulnerable. A patched browser will throttle the loop and finish quickly.

Step 3 – Monitor crash logs. On Windows, check Event Viewer under Application logs for Chrome.exe crashes. On macOS, open Console and filter for “Chrome”. On Linux, review syslog for SIGSEGV entries.

Step 4 – Network traffic analysis. Capture traffic with Wireshark while loading a test page that runs the title‑spam script. Look for a single HTTP GET request followed by a sudden stop in TCP activity. That pattern matches the Brash behavior.

Step 5 – Use a public test page. Security researchers have published a harmless test URL that reproduces the title‑spam without crashing. Load the URL and observe whether the browser becomes sluggish. If it does, you are exposed.

Fast mitigation

• Update the browser immediately. Apply the latest stable release from the vendor. Google has indicated a patch is forthcoming; applying the update as soon as it appears will close the gap.
• Enable experimental rate limiting. In Chrome, navigate to chrome://flags and enable “Throttle document.title updates” if the flag exists. Restart the browser.
• Deploy a Content Security Policy (CSP) that restricts inline scripts. Use script-src 'self' to block malicious payloads that attempt to run on load.
• For embedded webviews, set the disableWebSecurity flag to false and enforce a custom WebViewClient that validates URLs before loading.
• In enterprise environments, push a group policy that disables the document.title API via ChromePolicy if the organization can tolerate the loss of dynamic title changes.
• Monitor process health. Deploy a watchdog that restarts the browser if it becomes unresponsive for more than 5 seconds.
• Educate users. Advise them not to click unknown links in email or chat. A single click can crash the entire session.

These steps provide immediate protection while a permanent fix is rolled out. The mitigation does not require code changes in most cases. Keeping browsers up‑to‑date remains the most reliable defense. Organizations should also audit any Electron‑based applications for the same vulnerability, as they share the Chromium engine.