Google accidentally exposed exploit code for unfixed Chromium bug affecting Chrome and Edge

Google has accidentally exposed proof-of-concept exploit code for an unfixed Chromium vulnerability that could let a malicious website keep browser activity running in the background after a user visits a page.

The issue affects Chromium-based browsers that support the Background Fetch API, including Google Chrome, Microsoft Edge, Brave, Opera, Vivaldi, Arc, and others. According to TechSpot, the bug was first reported in 2022 by independent security researcher Lyra Rebane and still did not have a complete fix when the details surfaced.

The flaw does not let attackers break out of the browser sandbox or directly read files on the device. The risk comes from scale. A malicious site could use the browser as a limited background node for traffic routing, monitoring, redirection, or denial-of-service activity.

The bug abuses a feature built for background downloads

The vulnerable behavior involves Chromium’s Background Fetch API, which helps web apps continue large downloads after a user closes a tab or loses connectivity. The MDN Background Fetch API documentation describes it as a way to manage downloads that may take a long time, such as movies, audio files, and software.

Google’s own Chrome for Developers explanation says Background Fetch was designed for long-running downloads and shows progress to the user. It also notes that background fetches can continue after a user leaves a page or closes the browser.

Rebane’s reported proof of concept abused that design by creating a background fetch task that did not end normally. In some cases, this allowed a Service Worker to remain active and keep communicating with attacker-controlled infrastructure.

Item	Details
Reported by	Security researcher Lyra Rebane
Reported to Google	Late 2022
Feature involved	Chromium Background Fetch API
Browser component	Service Workers and background fetch behavior
Patch status	No complete public fix was available when the exploit details surfaced

Exploit code was published before a complete fix

The concern grew after Google’s Chromium bug tracker reportedly made the private issue public, including the proof-of-concept code. Business Standard reported that Google later removed the disclosure, but archived copies had already spread.

The issue had reportedly carried a high internal priority inside Chromium. Developers also described it as serious because the bug could let JavaScript keep doing browser-level work long after the user expected the page to stop running.

The public proof of concept lowers the barrier for experimentation. Turning it into a reliable large-scale abuse network would still require infrastructure and planning, but defenders now need to assume that more researchers and attackers can study the same technique.

How a malicious site could use the flaw

The attack starts when a user visits a malicious or compromised website. The page registers a Service Worker and starts a background fetch operation designed to keep running instead of completing normally.

The Chrome DevTools background services documentation explains that Chrome can log background fetch, background sync, notifications, and other background services for up to three days. That same class of browser features helps legitimate web apps work after a page closes, but it also shows why persistent browser activity needs careful controls.

Once active, the browser does not become a full malware implant. It cannot freely access the operating system. However, it can still perform actions available inside the browser context, which can create risk when many browsers run the same attacker-controlled logic.

Possible abuse	What it means
DDoS traffic	Many browsers could send requests toward a target at the same time.
Proxy-like behavior	Attackers could route some web traffic through victim browsers.
Traffic redirection	Browsers could open or request attacker-selected pages.
Activity monitoring	Attackers could collect limited browser-level timing and connection data.
Exploit chaining	A persistent browser foothold could become more dangerous if combined with another browser bug.

Chrome, Edge, Brave, Opera, Vivaldi, and Arc may be affected

The issue affects browsers that inherit the relevant Chromium Background Fetch behavior. Reports name Chrome, Edge, Brave, Opera, Vivaldi, and Arc among the affected browsers.

Business Standard also reported that Firefox and Safari are not affected by this specific issue because they do not support the same browser-fetching functionality.

Browser behavior may differ by vendor. Some reports say Chrome may show a brief download-related UI element, while Edge can be more silent in some cases because of its background process behavior.

Why Background Fetch exists in the first place

Background Fetch solves a real problem for legitimate web apps. Large downloads can fail if users close a tab, lose connection, or leave a page before the download finishes.

The MDN page notes that the API lets the browser handle long downloads in a visible way and gives users a way to cancel them. That user-visible design matters because background downloads can create privacy and battery concerns if browsers allow them to run invisibly for too long.

The problem in this case is not the idea of background downloads. The problem is that a malicious page may be able to keep a background task alive in a way that breaks user expectations and creates a hidden communication path.

What users and admins can do now

There is no perfect user-side fix until browser vendors ship and apply a complete patch. Users should keep Chrome, Edge, Brave, Opera, Vivaldi, Arc, and other Chromium-based browsers updated as soon as new versions arrive.

Enterprise administrators can monitor unusual browser background activity and review policies that limit Service Worker or Background Fetch behavior where feasible. The Chrome DevTools guide can also help technical teams inspect background fetch events during testing and incident review.

Organizations with higher-risk users can also consider browser isolation, stricter site access controls, and network monitoring for unusual outbound browser traffic. These controls will not remove the underlying bug, but they can reduce the chance of silent abuse.

• Update Chromium-based browsers as soon as vendors release fixes.
• Watch for unexpected download indicators or browser activity after leaving a site.
• Use enterprise policies to limit risky browser features where possible.
• Monitor unusual browser-originated traffic from endpoints.
• Use browser isolation for sensitive users or high-risk browsing workflows.

The main risk is scale, not full device takeover

The exploit does not turn Chrome or Edge into traditional malware with full access to the device. It stays inside browser boundaries, which limits what attackers can do directly.

However, a browser-level botnet can still matter. A popular malicious page, compromised site, or ad-delivery chain could expose many visitors at once, and even limited browser capabilities become more serious when attackers coordinate thousands of affected sessions.

The TechSpot report said the proof-of-concept Service Worker could continue after browser or device restart in some scenarios. Google and browser vendors now face pressure to close the gap before public code encourages wider abuse.

FAQ