May 25, 2026 · 7 min read
Google Marked a Chromium Botnet Bug "Fixed" Three Months Ago Without Patching It—Then Accidentally Opened the Whole Disclosure to the Public on May 20, And the Exploit Still Works on Chrome and Edge Today
Security researcher Lyra Rebane reported the Service Worker persistence bug in December 2022. Google labeled it a "serious vulnerability" in October 2024, paid out a $1,000 bug bounty, and quietly marked the Chromium bug ticket "fixed" on February 12, 2026—without shipping a patch. On May 20, the access restrictions on the disclosure expired automatically. The exploit still works on Chrome Dev 150, Edge 148, Brave, Opera, Vivaldi, and Arc.
Key Takeaways
- Lyra Rebane disclosed in December 2022 that Chromium's Service Worker feature lets a malicious site run JavaScript in the background after the user closes the tab and the browser window.
- Google paid a $1,000 bug bounty and on February 12, 2026 marked the bug ticket "fixed" without releasing a code patch.
- The access restrictions on the Chromium issue tracker entry expired automatically on May 20, 2026, exposing the full technical disclosure to the public 14 weeks after closure.
- Rebane retested the exploit on May 20 and confirmed it still works on Chrome Dev 150, Edge 148, Brave, Opera, Vivaldi, and Arc—any Chromium browser.
- Rebane wrote that "it's realistic to get tens of thousands of pageviews for creating a botnet" via the bug; the exploit can drive DDoS attacks, malicious traffic proxying, and ad fraud, though it cannot access local files or read other origins.
What Does the Bug Actually Do?
Service Workers are a long lived feature of the modern web platform. Their official purpose is to enable progressive web apps—offline support, push notifications, background sync—by running a small JavaScript context that survives independently of any visible page. The intended lifecycle is constrained: the Service Worker is supposed to run while the user has the site open or for a brief period after a push event, and it is supposed to shut down when the browser is closed.
Rebane's bug is that the Chromium implementation does not actually enforce that boundary. A malicious page that registers a Service Worker can keep it running long after the tab is closed, after the browser window is closed, and—on some platforms—after the browser process is restarted. The Service Worker continues to execute JavaScript at whatever cadence its creator scheduled.
From the attacker's perspective, the bug is a free, durable foothold inside any user's browser. There is no malware install, no exploit chain, no privilege escalation. Visiting one webpage—or being served one ad on a third party site—is enough.
What Can an Attacker Actually Do With It?
The persisting Service Worker runs inside the browser's sandbox, so it cannot read local files, cannot access the contents of email accounts the user is signed into in other tabs, and cannot escape into the operating system. That is the limit. Within those bounds, the available primitives are still substantial:
- Distributed DDoS. The Service Worker can issue HTTP requests to arbitrary destinations. Multiply by tens of thousands of victim browsers and the result is a respectable Layer 7 attack source.
- Malicious traffic proxying. The browser becomes a residential proxy, relaying requests for attacker controlled clients through clean residential IPs.
- Ad fraud. Background requests to ad serving endpoints generate fraudulent impressions and clicks; the requests come from genuine browsers with real fingerprints.
- Crypto mining. Background JavaScript runs CPU intensive code on the victim's machine. The economics are marginal, but they have been exploited before.
- Reconnaissance. The Service Worker can fetch attacker controlled URLs at scheduled times, allowing a botnet operator to gauge fleet size and availability.
Rebane's own estimate, in the now public disclosure, is that "it's realistic to get tens of thousands of pageviews for creating a botnet." The number is a function of how widely the malicious site or ad is distributed, not of how hard the exploit is to weaponize.
Why Did Google Close the Bug Without Fixing It?
The publicly visible record does not include a Google statement. The likeliest explanation, given how Chromium's issue tracker has historically been used, is that the security team judged the bug too entrenched in the platform's behavior to fix without breaking legitimate progressive web app functionality, decided the practical attacker payoff did not justify the engineering work, and closed the entry administratively.
That decision is defensible up to a point. The bug does not bypass the sandbox, does not read user data, and does not execute native code. The threat model is "botnet of browsers," which is real but not catastrophic in the way a sandbox escape would be. Marking it fixed without a patch is a triage call, not a security cover up.
The problem is that closing the bug also started a countdown to automatic public disclosure. Chromium's issue tracker policy unlocks access to closed bugs after a defined waiting period—14 weeks in this case—on the assumption that closed means fixed. When closed does not mean fixed, the disclosure unlocks anyway. The exploit is now public, no patch exists, and Google has not commented to BleepingComputer or to the researcher.
What Did Edge Add to the Problem?
Microsoft Edge implemented an additional behavior in a recent version that removed the small popup notification users used to see when a Service Worker registration completed. The popup was, in practice, the only user visible signal that a site had set up a background worker. Without it, the exploitation is completely silent on Edge: the user closes the tab, walks away, and the Service Worker continues to run with no indication on the screen.
Chrome retains the popup, but it is small, transient, and only appears the first time a worker is registered for a given origin. Users dismiss it without reading. The signal is technically present and operationally invisible.
What Should Users Do Right Now?
Until a patch ships—and the public disclosure makes it more likely that one will, despite the previous "fixed" status—the practical mitigations available to a Chromium user are limited but real:
- Quitting the browser process (Cmd Q on macOS, fully exiting the application on Windows) terminates running Service Workers. Closing the last window may not.
- Visiting chrome://serviceworker internals/ lists all registered Service Workers in the profile and provides a manual unregister button. Edge offers an equivalent at edge://serviceworker internals/.
- Clearing site data for an unfamiliar origin removes its Service Worker registration along with cookies and storage.
- Containerizing browsing through separate profiles for high risk activities limits the persistence surface. A Service Worker registered in one profile does not run in another.
For a corporate environment, the more important step is monitoring outbound traffic from end user devices for the kind of slow steady beaconing a Service Worker botnet would produce. Endpoint detection products have not historically watched browser background activity carefully, because there was no widely exploited reason to. The May 20 disclosure changes the calculus. The next round of botnet operators is reading the same Chromium issue tracker entry the defenders are.
Google's response time on the formal patch is the next thing to watch. The bug now has the full attention the original disclosure never received. The companies running Chromium derivatives—Microsoft, Brave Software, Opera, Vivaldi, The Browser Company—are all on the same upstream patch path, and any actual fix will arrive simultaneously across the family.