In 2022 security researcher Rebane discovered a flaw in Chromium‑based browsers that allowed a malicious site to register a service worker that persisted after the window closed, effectively enrolling the victim’s browser in a remote‑controlled botnet. The issue, tracked as Chromium bug 40062121, was only publicly disclosed in 2026 and remains partially unfixed, leaving Edge, Chrome, Brave, Opera, Vivaldi and Arc vulnerable to silent, long‑running code execution.
Thesis
In early 2022 a previously unknown vulnerability in the service‑worker implementation of Chromium‑based browsers was found that lets an attacker turn any user’s browser into a permanent JavaScript botnet node without any user interaction. Although the bug was reported to the Chromium project, the fix has been delayed, partially reverted, and as of mid‑2026 the exploit still works in Microsoft Edge and several other browsers, raising serious concerns about the security guarantees of modern web platforms.
How the bug works
Service workers as background agents
Service workers are scripts that run in a separate thread from the main page, intended to enable features such as offline caching and push notifications. They are registered by a page via the navigator.serviceWorker.register() API and, once installed, survive page navigation and even the closing of all visible windows, continuing to run until explicitly unregistered or the browser process terminates.
The exploit chain
- Malicious payload delivery – A victim visits a crafted website. The site includes a tiny script that registers a service worker with a
background-fetchrequest. - Silent registration – The bug prevents the browser from showing the usual download‑prompt or permission dialog that would normally alert the user to a background fetch.
- Persistence beyond window closure – In Edge (and other Chromium forks) the main browser process remains alive after all UI windows are closed, keeping the service‑worker process alive as well. The worker maintains a persistent WebSocket connection to a command‑and‑control (C2) server.
- Botnet enrollment – The C2 can now issue arbitrary JavaScript to be executed in the context of the worker, effectively turning the browser into a remote‑controlled bot that can perform actions such as data exfiltration, cryptomining, or further exploitation of the host system.
The key novelty is that no user interaction is required after the initial page load, and the malicious code continues to run even after the user thinks the browser has been closed.
Evidence and public disclosure
Rebane first posted a brief description on the Mastodon instance infosec.exchange in May 2026, linking to the Chromium issue tracker: https://issues.chromium.org/issues/40062121. The thread shows community reactions, including:
- Confirmation that the bug still works in Edge, where the download menu no longer appears, making the attack completely silent.
- Reports that other Chromium‑based browsers (Brave, Opera, Vivaldi, Arc) exhibit the same behavior.
- Discussions about mitigation via uBlock Origin CSP filters that block
worker-src 'none'or by disabling service workers entirely.
A screenshot of the conversation (
) illustrates the frustration of the community over the four‑year delay in a proper fix.
Implications for users and developers
For end users
- Persistent infection risk: Even users who close all browser windows may remain compromised until the entire browser process is terminated (e.g., by a system reboot or task manager kill).
- Ineffective UI cues: Traditional security indicators such as download prompts or permission dialogs no longer warn about the background activity.
- Mitigation options: Users can disable service workers via browser flags, employ extensions like uBlock Origin with CSP rules, or use NoScript‑style blockers that prevent any JavaScript from running on untrusted sites.
For browser vendors
- Architectural review: The bug highlights a design flaw where the lifetime of a service worker is decoupled from visible UI, allowing it to outlive the user’s perception of the browser’s shutdown.
- Patch urgency: A proper fix must ensure that closing all windows also terminates background workers, or at least prompts the user before establishing persistent network connections.
- Transparency: The prolonged public exposure of the issue without a definitive fix erodes trust in the security processes of large open‑source projects.
Counter‑perspectives and remaining questions
Some commentators argue that the responsibility also lies with site operators and users who run unrestricted JavaScript. While it is true that disabling JavaScript globally would mitigate this class of attack, such a blanket approach breaks the modern web experience. Moreover, the exploit leverages a browser‑level bug, not a flaw in a particular website, meaning that even well‑behaved sites could inadvertently become vectors if an attacker compromises a third‑party resource.
Another point of debate concerns the role of extensions. Certain extensions rely on service workers for background tasks; indiscriminately blocking them could break functionality. A nuanced solution would involve a permission model that distinguishes between trusted extensions and arbitrary web‑origin workers.
Looking ahead
The community’s call for a proper fix has resurfaced on the Chromium bug tracker, and a private re‑opening of the issue suggests that developers are revisiting the problem. Until a permanent resolution lands in a stable release, security‑conscious users should consider the mitigations discussed above and stay alert for any unusual network activity originating from their browsers.
The episode serves as a reminder that even the most widely deployed web platform components can harbor long‑standing vulnerabilities, and that timely, transparent remediation is essential for maintaining the trust of both users and the security research community.
Comments
Please log in or register to join the discussion