{"id":5601,"date":"2025-10-30T12:27:18","date_gmt":"2025-10-30T12:27:18","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=5601"},"modified":"2025-10-30T12:27:18","modified_gmt":"2025-10-30T12:27:18","slug":"chromium-flaw-crashes-chrome-edge-atlas-researcher-publishes-exploit-after-googles-silence","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=5601","title":{"rendered":"Chromium flaw crashes Chrome, Edge, Atlas: Researcher publishes exploit after Google\u2019s silence"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

A vulnerability in Chromium\u2019s 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.<\/p>\n

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.<\/p>\n

The timing raises uncomfortable questions about Google\u2019s 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.<\/p>\n

\u201cI 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,\u201d Pino said in technical documentation published on GitHub<\/a>. \u201cI believe public awareness is necessary when responsible disclosure does not produce timely mitigation.\u201d<\/p>\n

Google, Microsoft, and seven other affected browser vendors, including Opera and Vivaldi, did not respond to requests for comment.<\/p>\n

How the attack works<\/h2>\n

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.<\/p>\n

\u201cThe attack vector originates from the complete absence of rate limiting on document.title API updates,\u201d Pino wrote in the technical document. \u201cThis 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.\u201d<\/p>\n

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.<\/p>\n

Firefox and Safari emerged unscathed. Both use different rendering engines \u2014 Gecko and WebKit, respectively \u2014 that don\u2019t share Blink\u2019s architectural flaw. All iOS browsers also escaped because Apple requires them to use WebKit, Pino added in the document.<\/p>\n

In Pino\u2019s 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 \u201cPage Unresponsive\u201d dialogs. Fifteen to 60 seconds required forced termination.<\/p>\n

Beyond desktop crashes: enterprise automation at risk<\/h2>\n

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.<\/p>\n

Pino\u2019s 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.<\/p>\n

Web-based surgical navigation systems could fail during critical procedures. \u201cThe browser process collapses, stopping the entire analysis pipeline,\u201d according to the research documentation.<\/p>\n

Pino\u2019s 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\u2014market opening, shift change, peak operations.<\/p>\n

\u201cA critical feature that amplifies Brash\u2019s danger is its ability to be programmed to execute at specific moments,\u201d Pino\u2019s documentation stated. \u201cAn attacker can inject the code with a temporal trigger, remaining dormant until a predetermined exact time.\u201d<\/p>\n

When disclosure breaks down<\/h2>\n

Google\u2019s silence on Pino\u2019s report highlights persistent tensions in vulnerability disclosure<\/a>. Google\u2019s own Project Zero team enforces a strict 90-day disclosure deadline, the industry standard, for vulnerabilities it discovers in third-party software.<\/p>\n

The company\u2019s Chrome Vulnerability Reward Program documentation<\/a> pledges to \u201crespond promptly and fix bugs in a sensible timeframe.\u201d It states that most security bugs are automatically opened for public access 14 weeks after fixes are committed to Chromium.<\/p>\n

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.<\/p>\n

The disclosure debate has raged for years. Microsoft once criticized Google<\/a> for publishing Windows vulnerabilities before patches were ready, calling it a \u201cgotcha\u201d that left customers exposed. Yet vendors that don\u2019t respond leave researchers with few options.<\/p>\n

Pino noted another complication. \u201cThe 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,\u201d he said in the documentation.<\/p>\n

Google addressed at least six Chrome zero-day vulnerabilities in 2024, according to the company\u2019<\/em>s security advisories. But this architectural flaw in Blink has received no public acknowledgment. The Chromium project\u2019s public issue tracker contained no entries matching the vulnerability as of October 30.<\/p>\n

Microsoft, Brave, and other affected vendors had issued no security advisories by press time.<\/p>\n

Limited options for enterprise security teams<\/h2>\n

CIOs face difficult choices. The vulnerability affects Blink\u2019s core, so standard browser hardening measures \u2014 content security policies, site isolation, extension restrictions \u2014 provide no protection.<\/p>\n

Pino\u2019s 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.<\/p>\n

He also published a live demonstration at brash.run that executed the exploit against visitors\u2019 browsers. The code included configurable intensity settings ranging from \u201cmoderate\u201d observation modes to \u201cextreme\u201d instant collapse configurations.<\/p>\n

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.<\/p>\n

The silence leaves a critical question unanswered: When vendors don\u2019t respond to properly disclosed vulnerabilities<\/a>, how long should researchers wait before warning the public?<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

A vulnerability in Chromium\u2019s 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 […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-5601","post","type-post","status-publish","format-standard","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/5601"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5601"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/5601\/revisions"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5601"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5601"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5601"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}