By ByteBot
Google accidentally published proof-of-concept exploit code last week for a Chromium vulnerability that has been sitting unpatched for 42 months — then quietly tried to retract it. Too late. The flaw, first reported by independent researcher Lyra Rebane in late 2022, lets any malicious webpage silently turn a visitor’s browser into a persistent botnet node using the Background Fetch API. Chrome, Edge, Brave, Opera, Vivaldi, and Arc are all affected. Firefox and Safari are not. And as of today, there is still no patch.
How the Exploit Works
Service Workers are supposed to have a limited lifespan. They run, complete a task, and terminate. The exploit breaks that contract with a simple loop.
When a user visits a malicious page, the site registers a Service Worker and initiates a Background Fetch task — the same API Chrome uses to continue large file downloads in the background. The exploit then creates and immediately aborts that fetch every 20 seconds. That create-abort cycle resets the Service Worker’s lifespan timer, keeping it alive indefinitely. Critically, if the cycle runs fast enough, the background task never surfaces in the browser’s download UI at all.
“If the background fetch is created and aborted fast enough, it won’t show up in the browser UI at all, but will still keep the Service Worker active.”
— Lyra Rebane, original Chromium vulnerability report
The result is a persistent, invisible connection between the victim’s browser and an attacker-controlled command-and-control server — one that reopens even after the browser is closed and the device reboots. From there, attackers can track users, proxy traffic, launch DDoS attacks, or execute remotely stored JavaScript payloads. Rebane estimated it is realistic to enroll “tens of thousands” of browsers this way from ordinary web traffic.
Every Chromium Browser Is Affected — Edge Is Worse
The affected list covers the vast majority of the web: Chrome, Microsoft Edge, Brave, Opera, Vivaldi, Arc, and every other Chromium-based browser. Chromium-based browsers collectively hold around 65–70% of global browser market share, so the exposure pool is measured in billions of users.
Firefox and Safari are not vulnerable. Both handle the Background Fetch API differently and do not expose the same lifecycle bypass.
Microsoft Edge deserves a special mention — and not a good one. In Chrome, registering a Service Worker through this method at least triggers a brief download dialog, giving users a fleeting visual cue. Edge executes the same behavior silently, with no notification whatsoever. Edge users are more exposed, not less.
How Google Exposed Its Own Bug
The Chromium Issue Tracker has an automated policy: when a bug is marked as fixed, access restrictions are automatically lifted 14 weeks later. In February 2026, Google marked this bug as fixed in the tracker — without actually shipping the fix. The 14-week timer ran down on May 20, 2026, and the report, the PoC code, and all technical details became publicly accessible.
Rebane tested Chrome Dev 150 and Edge 148 the same day and confirmed on Mastodon that the flaw was still fully present. Google moved quickly to re-restrict the bug report, but the page had already been archived. The PoC is circulating.
This is not a zero-day in the traditional sense. Sophisticated attackers have known about this since 2022. What changed on May 20 is that anyone can now build an exploit from the public PoC. The attacker barrier dropped to near zero.
A Patch Needs More Than a Patch
Forty-two months sounds like negligence. The technical reality is more complicated — though that does not excuse it.
Fixing this properly requires a spec-level change to the Background Fetch API itself: introducing a hard time limit that prevents the create-abort loop from resetting the Service Worker lifecycle timer. That means coordination across the W3C, Google, Microsoft, Brave, and other Chromium contributors. It is not a one-afternoon fix. But it is a P1/S2 issue by Google’s own classification — its second-highest priority and severity ratings — and it has been for nearly four years without resolution.
What Developers Can Do Right Now
No patch means developers running web properties need to act on the defensive side.
- Set a
worker-srcCSP directive. AContent-Security-Policy: worker-src ‘self’header restricts Service Worker registration to scripts served from your own origin. This prevents a third-party injected script from registering a malicious Service Worker under your domain. - Audit registered Service Workers. Open Chrome DevTools, go to Application > Service Workers, and check for anything unexpected. Unexpected Service Workers on a production domain are a serious red flag. Use the Chrome DevTools background services panel to monitor them.
- Enforce HTTPS on all sub-resources. Service Workers require HTTPS. Mixed-content sub-resources create injection attack surfaces. Lock it down.
- Tell your users to update. Google has acknowledged the issue and is working on a fix. When it ships, it comes through a browser update. Users on outdated Chromium browsers are fully exposed until then.
The broader lesson keeps proving necessary: browser APIs designed for convenience — background downloads, push notifications, offline caching — create persistent, hard-to-audit attack surfaces. The Background Fetch API is powerful and legitimate. Without a hard lifetime cap on Service Workers, it is also a standing invitation to abuse. That tension has been documented and unresolved for 42 months. It should not take a public PoC leak to move the priority needle.
