A vulnerability in Chromium’s rendering engine can crash Chrome, Microsoft Edge, and seven other browsers within seconds if exploited by attackers, a security researcher warned after Google ignored his vulnerability report for two months.
Jose Pino published proof-of-concept code for the flaw on October 29, potentially exposing more than three billion users to browser crashes and system instability. The vulnerability exploits a fundamental design weakness in Blink, the rendering engine that powers all Chromium-based browsers.
The timing raises uncomfortable questions about Google’s vulnerability response process. Pino reported the flaw on August 28 and followed up on August 30. He received no response before deciding to publish his research.
“I decided to publish this PoC to draw attention to a severe issue affecting broad internet users after my initial report two months ago went unanswered,” Pino said in technical documentation published on GitHub. “I believe public awareness is necessary when responsible disclosure does not produce timely mitigation.”
Google, Microsoft, and seven other affected browser vendors, including Opera and Vivaldi, did not respond to requests for comment.
How the attack works
The vulnerability, which Pino called Brash, exploits the complete absence of rate limiting on document.title API updates in Blink. By flooding the browser with millions of title changes per second, an attacker can saturate the main thread and force a crash.
“The attack vector originates from the complete absence of rate limiting on document.title API updates,” Pino wrote in the technical document. “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 exploit affects Chromium versions 143.0.7483.0 and earlier. Pino tested 11 browsers across macOS, Windows, Linux, and Android. Nine proved vulnerable: Chrome, Edge, Vivaldi, Arc, Dia, Opera, Perplexity Comet, ChatGPT Atlas, and Brave.
Firefox and Safari emerged unscathed. Both use different rendering engines — Gecko and WebKit, respectively — that don’t share Blink’s architectural flaw. All iOS browsers also escaped because Apple requires them to use WebKit, Pino added in the document.
In Pino’s testing, the exploit produced a predictable collapse timeline. Zero to five seconds triggered extreme CPU consumption. Five to 10 seconds froze tabs completely. Ten to 15 seconds produced browser collapse or “Page Unresponsive” dialogs. Fifteen to 60 seconds required forced termination.
Beyond desktop crashes: enterprise automation at risk
While crashed browsers disrupt individual users, the vulnerability poses greater risks to enterprise automation. Organizations running headless Chromium browsers for AI agents, trading systems, or operational monitoring face potential workflow paralysis, the document stated.
Pino’s documentation outlined several enterprise attack scenarios. AI agents querying compromised websites could crash mid-analysis, halting automated trading decisions. Fraud detection dashboards could collapse during peak transaction periods.
Web-based surgical navigation systems could fail during critical procedures. “The browser process collapses, stopping the entire analysis pipeline,” according to the research documentation.
Pino’s proof-of-concept code included scheduling parameters that let attackers trigger crashes at specific times. An attacker could inject the code with a time delay, letting it lie dormant until a critical moment—market opening, shift change, peak operations.
“A critical feature that amplifies Brash’s danger is its ability to be programmed to execute at specific moments,” Pino’s documentation stated. “An attacker can inject the code with a temporal trigger, remaining dormant until a predetermined exact time.”
When disclosure breaks down
Google’s silence on Pino’s report highlights persistent tensions in vulnerability disclosure. Google’s own Project Zero team enforces a strict 90-day disclosure deadline, the industry standard, for vulnerabilities it discovers in third-party software.
The company’s Chrome Vulnerability Reward Program documentation pledges to “respond promptly and fix bugs in a sensible timeframe.” It states that most security bugs are automatically opened for public access 14 weeks after fixes are committed to Chromium.
But that timeline assumes vendors respond. Pino received no acknowledgment of his August 28 report. His two-month wait fell well short of the 90-day standard, yet exceeded what many researchers consider reasonable when facing vendor silence.
The disclosure debate has raged for years. Microsoft once criticized Google for publishing Windows vulnerabilities before patches were ready, calling it a “gotcha” that left customers exposed. Yet vendors that don’t respond leave researchers with few options.
Pino noted another complication. “The problem is more serious than it seems, since each company that uses Chromium has customized functionalities, which leads me to believe that the fix must be independent for each one,” he said in the documentation.
Google addressed at least six Chrome zero-day vulnerabilities in 2024, according to the company’s security advisories. But this architectural flaw in Blink has received no public acknowledgment. The Chromium project’s public issue tracker contained no entries matching the vulnerability as of October 30.
Microsoft, Brave, and other affected vendors had issued no security advisories by press time.
Limited options for enterprise security teams
CIOs face difficult choices. The vulnerability affects Blink’s core, so standard browser hardening measures — content security policies, site isolation, extension restrictions — provide no protection.
Pino’s proof-of-concept code remained publicly accessible on GitHub under Creative Commons and MIT licenses. The documentation included disclaimers limiting use to educational and security research in controlled environments.
He also published a live demonstration at brash.run that executed the exploit against visitors’ browsers. The code included configurable intensity settings ranging from “moderate” observation modes to “extreme” instant collapse configurations.
The documentation specified that the exploit would cease working once vendors patched the vulnerability. But without response timelines from Google or other browser makers, enterprise security teams have no way to plan their defenses or communicate risks to business units that depend on browser-based workflows.
The silence leaves a critical question unanswered: When vendors don’t respond to properly disclosed vulnerabilities, how long should researchers wait before warning the public?
No Responses