Google Publishes Exploit Code Threatening Millions of Chromium Users (arstechnica.com)
- Reference: 0183301203
- News link: https://it.slashdot.org/story/26/05/20/2013252/google-publishes-exploit-code-threatening-millions-of-chromium-users
- Source link: https://arstechnica.com/security/2026/05/google-publishes-exploit-code-threatening-millions-of-chromium-users/
> Google on Wednesday published exploit code for an unfixed vulnerability in its Chromium browser codebase that [1]threatens millions of people using Chrome, Microsoft Edge, and virtually all other Chromium-based browsers . The proof-of-concept code exploits the Browser Fetch programming interface, a standard that allows long videos and other large files to be downloaded in the background. An attacker can use the exploit to create a connection for monitoring some aspects of a user's browser usage and as a proxy for viewing sites and launching denial-of-service attacks. Depending on the browser, the connections either reopen or remain open even after it or the device running it has rebooted.
>
> The unfixed vulnerability can be exploited by any website a user visits. In effect, a compromise amounts to a limited backdoor that makes a device part of a limited botnet. The capabilities are limited to the same things a browser can do, such as visit malicious sites, provide anonymous proxy browsing by others, enable proxied DDoS attacks, and monitor user activity. Nonetheless, the exploit could allow an attacker to wrangle thousands, possibly millions, of devices into a network. Once a separate vulnerability becomes available, the attacker could use it to then compromise all those devices.
>
> "The dangerous part here is that you can just have a lot of different browsers together that you can in the future run something on that you figure out," said Lyra Rebane, the independent researcher who discovered the vulnerability and privately reported it to Google in late 2022 in an interview. He said using the exploit code Google prematurely published would be "pretty easy," although scaling it to wrangle large numbers of devices into a single network would require more work. In the thread of Rebane's disclosure to Google, two developers said in separate responses that it was a "serious vulnerability." Its severity was rated S1, the second-highest classification.
>
> Since its reporting 29 months ago, the vulnerability remained unknown except to Chromium developers. Then on Wednesday morning, it was published to the Chromium bug tracker. Rebane initially assumed the vulnerability was [2]finally fixed . Shortly thereafter, he learned that, in fact, it remained unpatched. While Google removed the post, it remains available on archival sites, along with the exploit code. Google representatives didn't immediately respond to an email asking how and why it published the vulnerability and if or when a fix would become available.
The exploit works by abusing Chromium's Browser Fetch API to open a [3]service worker that remains persistently active. A malicious website can trigger it through JavaScript, creating a connection that can be used "for monitoring some aspects of a user's browser usage and as a proxy for viewing sites and launching denial-of-service attacks," reports Ars.
Depending on the browser, those connections "either reopen or remain open even after it or the device running it has rebooted," effectively turning the device into part of a "limited botnet."
[1] https://arstechnica.com/security/2026/05/google-publishes-exploit-code-threatening-millions-of-chromium-users/
[2] https://infosec.exchange/@rebane2001/116606719764376414
[3] https://developer.chrome.com/docs/workbox/service-worker-overview/
29 months ago? (Score:5, Insightful)
I hope nobody's complaining that it got publicly disclosed because "they only had two and a half years to fix it but hadn't gotten around to it yet"
IMO, "responsible disclosure" taps out after six months. Anything that happens after that is entirely on the devs for not bothering to plug holes that they were privately notified about.
Re:29 months ago? (Score:4, Interesting)
This wasn't even the security researcher disclosing though. This was all on the Chromium folks fumbling in multiple ways.
Re: (Score:2)
> This wasn't even the security researcher disclosing though. This was all on the Chromium folks fumbling in multiple ways.
I am guessing that the Chromium folk made the same presumption as the security researcher initially did, that the bug was already fixed years ago (two years for a S1, it *must* have gotten fixed a long time ago), so was just closing the issue. The egg on the face of the Chromium folk will take some time to wash off, and probably add in some new internal process to opening other bug reports.
Re:29 months ago? (Score:4, Informative)
The issue id is [1]40062121 [chromium.org] and the latest one is 515156127. So they weren't adding it, but just accidentally marked the a 4+ year old original S1 vuln as public.
Hard to find an explanation besides just being a very embarrassing oopsie daisy. Lucky the researcher was watching it and excited to [2]show off their work. [infosec.exchange]
[1] https://issues.chromium.org/issues/40062121
[2] https://infosec.exchange/@rebane2001/116606719764376414
Re: (Score:3)
Fucking hell. What is the problem preventing this from being fixed?
Is it unfixable? no? THEN FIX IT.
Unacceptable incompetence.
Right (Score:4, Informative)
> "vulnerability in its Chromium browser codebase that threatens millions of people using Chrome, Microsoft Edge, and virtually all other Chromium-based browsers."
Right. Pretty much all browsers except Firefox and Safari.
> "The dangerous part here is that you can just have a lot of different browsers together that you can in the future run something on that you figure out," said Lyra Rebane"
Right. What many of us have been saying for years. That there is very little actual browser diversity now and it is extremely dangerous. Dangerous not just for security, but also robust true standards, and even privacy. Safari is only Apple stuff; for multiplatform there are essentially only two "browsers" left now, Chrom* and Firefox-ish. And Firefox is struggling, most of which isn't Mozilla's fault and bashed often based on inaccurate information.
Re: (Score:2)
I think it's easy to recognize this problem, but a lot harder to solve it.
Developing a modern browser is a ridiculous amount of work. Too much to be developed out of free time of volunteers. Which comes back to open source competitors that have perennial problems with funding or direction and commercial competitors facing a huge barrier to entry against multi-billion dollar giants. (Noting that several of those giants even have had rulings against them for abusing their monopoly position.)
Re:Right (Score:5, Insightful)
Agreed that there is no easy solution, especially at this point. All I can do is encourage people to support, use, and test against the only non-Chrom* multiplatform browser left (Firefox or Firefox-based). At a time when we desperately need MORE than just two browsers, we are at great risk of it essentially becoming just one.
Every time some site "recommends Chrome" or tech support says "we only test on Chrome" or "we only support Chrome [or whatever Chrome variant]" it is another nail in our collective coffin. I want Chrome and its children to prosper, but not in a vacuum, not unchallenged, not without usable alternatives.
Re: (Score:1)
> I think it's easy to recognize this problem, but a lot harder to solve it.
> Developing a modern browser is a ridiculous amount of work. Too much to be developed out of free time of volunteers. Which comes back to open source competitors that have perennial problems with funding or direction and commercial competitors facing a huge barrier to entry against multi-billion dollar giants. (Noting that several of those giants even have had rulings against them for abusing their monopoly position.)
Yep. Modern browsers have to be ridiculously complex.
Because modern HTML, JS, and CSS are ridiculously complex. They do ridiculously cool stuff, so I'm not saying that they shouldn't be. But they are, and therefore the browsers have to be as well.
Re: (Score:2)
Serious question: what can html, js and css do today that they couldn't 10 or even 15 years ago, at least for the user? I think the only cool, new, user-friendly innovation I have seen in that timeframe is passkeys. Granted, I don't run across random sites like I used to.
Re: (Score:2)
There's a ton of things, most of them incremental improvements that make it either easier to work with, faster, prettier, or safer. WebAssembly, CSS Grid / Flexbox implementations, CSS variables, WebRTC, the list goes on...
Re: (Score:3)
WebAssembly is technically an answer as it first appeared about nine years ago, but it was widely discussed before that. WebRTC dates back to 2011. Can't find a date on flexboxes but I see blog articles from 2013(!) on that. CSS grid is more recent, as are CSS variables - long after SCSS became standard because everyone got fed up of waiting - but I agree with the GP, is any of the actually more recent stuff actually necessary?
Of all of the above, WebAssembly is kinda useful, (and WebRTC fills a hole but is
Re: (Score:2)
The modern browser was a mistake and google has not been a good custodian of it. Browsers should probably not have any of the components being used in this exploit in the first place.
Re: (Score:2)
This is why I do all of my browsing from [1]Lynx [invisible-island.net]
[1] https://lynx.invisible-island.net/lynx_help/Lynx_users_guide.html
Re: (Score:2)
> Developing a modern browser is a ridiculous amount of work.
Depends what you mean by "modern browser." The OP is complaining about the lack of diversity in browsers, not the lack of diversity in browser engines. You can write a browser using your engine of choice, i.e. not Chrome's Blink, in a few hours. It will support all the CSS, Javascript, yadda yadda. There are even some projects around that will let you build an app around whatever browser engine happens to be available on the system. That app could b
Re: (Score:2)
> Chrome, Microsoft Edge, and virtually all other Chromium-based browsers."
> Safari is only Apple stuff; for multiplatform there are essentially only two "browsers" left now, Chrom* and Firefox-ish.
I have a hard time reading talking about classes of "browsers" not really meaning or including the engines. So then I didn't jump into the weeds about engines in my comment (and if we want to get into the weeds, Blink isn't the Chrome JS engine that's V8). But yes, the engines are of course the harder part.
Re: (Score:2)
> Safari is only Apple stuff
Webkit (what Safari uses) is open source. It runs on Windows, Linux and a bunch of other UNIX-like OSs. It's also used by the browsers in Playstations, Nintendos, and Kindles. If you're using Linux you can use Gnome's default browser, which is Webkit. If you're using Windows your options are limited, but you could try the Orion port.
Another point for Firefox and against Google (Score:2)
People complained about Microsoft somehow allowing an exploit to come back. Looks like Google didn't even bother. And meanwhile, Google is reducing the info and power they give to open source devs, like delaying what the GrapheneOS people need in order to add new devices. It took months to get support for the Pixel 10 for this reason. At this point, I use Chrome for when I want a naked web experience, no plugins and all the ads or for the rare plugin that is Chrome only.
Re: (Score:2)
Thank goodness for the NoScript plugin in Firefox.
It takes some diligence to selectively whitelist each site; totally worth it.
Background fetch. Such a "useful" concept (Score:1)
ah yes. Background fetch. Such a "useful" concept ps1 Nuke New-Item -Path 'HKLM:\Software\Policies\Google' -Name 'Chrome' -Force | Out-Null; New-ItemProperty -Path 'HKLM:\Software\Policies\Google\Chrome' -Name 'BackgroundModeEnabled' -PropertyType DWord -Value 0 -Force | Out-Null; New-Item -Path 'HKLM:\Software\Policies\Microsoft' -Name 'Edge' -Force | Out-Null; New-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Edge' -Name 'BackgroundModeEnabled' -PropertyType DWord -Value 0 -Force | Out-Null uBlo
Web APIs have become too complex and overreaching (Score:5, Insightful)
Remember when Google removed from Chrome the 60 lines of code implementing the FTP protocol because it was a security liability?