The Scale of Exposure

With Chrome commanding over 70% of the global browser market and an estimated 5.5 billion internet users worldwide, this vulnerability potentially affects more than 3 billion people. The issue extends beyond Chrome to include all Chromium-based browsers: Microsoft Edge, OpenAI's ChatGPT Atlas, Brave, Vivaldi, Opera, Arc, Dia, Perplexity Comet, and others.

Security researcher Jose Pino discovered the flaw and created a proof-of-concept exploit called Brash to demonstrate the vulnerability's impact. Testing across 11 major browsers on Android, macOS, Windows, and Linux revealed that nine browsers succumb to the attack, collapsing within 15 to 60 seconds.

How the Attack Works

The vulnerability stems from an architectural flaw: the complete absence of rate limiting on document title API updates. This allows attackers to inject millions of DOM mutations per second, saturating the browser's main thread, disrupting the event loop, and causing interface collapse.

The attack unfolds in three distinct phases:

First, the attacker pre-loads 100 unique hexadecimal strings of 512 characters into memory. Using unique strings rather than reusing the same string is crucial for attack effectiveness.

Next, the exploit executes in rapid bursts of consecutive document title updates. With a typical configuration attempting approximately 24 million updates per second, the browser quickly becomes overwhelmed.

Finally, these continuous updates saturate the browser's main thread, consuming massive computational resources and preventing it from processing other events. Within five to ten seconds, browser tabs freeze. Between ten and fifteen seconds, the browser collapses or displays "page unresponsive" dialogue boxes. By fifteen to sixty seconds into the attack, Chromium-based browsers require forced termination.



During testing, the exploit not only crashed Edge but also locked up the Windows-based host machine after approximately 30 seconds, consuming 18GB of RAM in a single tab.

The Disclosure Timeline

Pino initially disclosed the vulnerability to Chromium's security team on 28th August and followed up on 30th August, but received no response. After two months without acknowledgement or mitigation, he chose to publish the proof-of-concept publicly to draw attention to the severe issue affecting internet users broadly.

The researcher believes responsible disclosure should produce timely mitigation, and when it doesn't, public awareness becomes necessary.

Which Browsers Are Safe?

Testing revealed that browsers using alternative rendering engines remain immune. Firefox, which uses the Gecko engine, and Safari, which uses WebKit, both resisted the attack. All browsers running on iOS also proved immune, as Apple requires iOS browsers to use WebKit regardless of branding.

The vulnerability affects Chromium versions 143.0.7483.0 and later, meaning recent browser updates have actually introduced rather than resolved this security issue.

Industry Response

Requests for comment were sent to all nine affected browser vendors. Seven companies didn't respond. Google confirmed it's investigating the issue. Brave stated it has no custom behaviour around document title functionality and will implement the fix when Chromium provides it—highlighting how dependent downstream browsers are on Google's upstream patches.

This response pattern underscores a challenge inherent to the Chromium ecosystem: companies using Chromium have customised functionalities, potentially requiring independent fixes rather than a single upstream solution.

The Real-World Threat

Whilst this exploit won't lead to ransomware or data theft, it can cause significant disruption. Users could lose unsaved work across all browser tabs when forced to terminate their browser. Any webpage could contain the malicious JavaScript code, and attackers could potentially inject it into compromised websites.

The attack's simplicity makes it particularly concerning. It doesn't require sophisticated exploits or complex attack chains—just JavaScript code that overwhelms a fundamental browser function that lacks proper resource limitations.

The Broader Problem

This vulnerability highlights a fundamental issue in modern browser architecture: the absence of proper resource throttling on certain API functions. Browsers have become extraordinarily complex applications managing countless processes simultaneously, but without appropriate rate limiting on resource-intensive operations, they remain vulnerable to denial-of-service attacks.

The fact that alternative rendering engines proved immune suggests this isn't an inevitable characteristic of all browsers—it's a specific architectural decision or oversight in Chromium's implementation.

What Users Should Know

Until patches are released, users of Chromium-based browsers remain vulnerable to this attack. The exploit can be delivered through any website, making it difficult to avoid beyond general safe browsing practices.

For organisations, this represents another reminder that browser security extends beyond traditional vulnerabilities like remote code execution. Denial-of-service attacks that freeze systems and cause data loss carry real business impact, particularly in environments where users work with unsaved content or time-sensitive operations.

The lack of response to responsible disclosure and the two-month delay in addressing this issue also raises questions about security response processes at major browser vendors, particularly given the scale of potential impact.

Stay Protected Against Emerging Threats

At Altiatech, we help organisations stay informed about emerging security vulnerabilities and implement strategies to mitigate risks across their technology stack. Our cybersecurity services include threat monitoring, security assessments, and guidance on managing vulnerabilities in widely-used platforms.

Get in touch:

📧 Email: innovate@altiatech.com
📞 Phone (UK): +44 (0)330 332 5482

Proactive security. Informed decisions.