What happened#
Google appears to have accidentally exposed details of a still-unfixed Chromium security issue after the bug was marked as fixed in Chromium’s tracking system.
According to BleepingComputer, the issue involves Service Workers and background JavaScript execution. Security researcher Lyra Rebane reported the bug in 2022. Google acknowledged it as valid in December of that year.
The reported behavior is direct: a malicious webpage could register a Service Worker, such as one tied to a download task, that does not terminate as expected. Rebane said this could keep JavaScript running on a visitor’s device even after the browser is closed.
That is the part that matters. This is not a normal “web page runs JavaScript while open” case. The reported issue is about persistence beyond the visible browser session.
BleepingComputer says the bug affects Chromium-based browsers, including Google Chrome, Microsoft Edge, Brave, Opera, Vivaldi, and Arc. That does not mean every browser is affected in the same way at every moment, but it does put the issue in a broad risk class because Chromium is the shared engine layer for much of the browser market.
Why the exposure matters#
Security bugs in Chromium’s tracker can remain restricted while fixes are developed and shipped. In this case, the issue was apparently treated as fixed in the system before a working patch had actually reached users.
The timeline is the problem.
BleepingComputer reports that on February 10, 2026, the issue was marked fixed and then reopened minutes later because of several concerns. The labels were updated so the issue could go through Google’s Chrome Vulnerability Rewards Program panel. On February 12, it was again marked as fixed, and Rebane received an automated email awarding a $1,000 bug bounty.
But a patch had not shipped.
On May 20, access restrictions were removed from the Chromium Issue Tracker because the bug had been closed for more than 14 weeks and was marked fixed in the system. Rebane then tested the issue and found it still worked in Chrome Dev 150 and Edge 148, according to the report.
The issue was later made private again. But the window was long enough for details to leak.
That is the operational failure: disclosure controls followed the status field, not the real patch state. If the tracker says “fixed,” automation can treat the report as safe to expose. If the code path remains exploitable, that becomes an accidental publication of vulnerability details.
What the bug could allow#
The reported impact is serious, but it should be kept precise.
Rebane described a scenario where visiting a single malicious website could cause a Chromium-based browser to become part of a persistent JavaScript-controlled network. In the original report, she warned that it could be realistic to get large numbers of pageviews and that users would not expect JavaScript to continue executing remotely on their devices after browser closure.
Potential abuse cases listed in the report include:
- distributed denial-of-service activity using compromised browser instances
- proxying malicious traffic through affected browsers
- redirecting traffic to target sites
- maintaining a silent command-and-control style connection through the browser context
BleepingComputer also notes a browser-specific detail that may increase stealth. Rebane said that in newer Edge behavior, a download pop-up that previously appeared when triggering the exploit no longer appears, making the issue less visible to the user.
That does not automatically mean attackers can take over the host computer.
Rebane clarified that the bug does not bypass browser security boundaries. It does not give attackers access to the victim’s emails, local files, or the operating system. The useful model is not “full device compromise.” It is “unexpected persistent browser-based JavaScript execution after one site visit.”
That is still dangerous. A browser does not need filesystem access to cause harm. It has network access. It has user trust. It can generate traffic. At scale, even a constrained execution environment can become useful infrastructure for abuse.
What not to overclaim#
There is no public confirmation in the source that this issue is being exploited in the wild.
There is also no public fix version listed in the provided report. BleepingComputer said it contacted Google for comment but had not received a response by publication.
So the safe conclusions are narrower:
- A Chromium bug report with security impact was exposed.
- The issue had previously been marked fixed in the tracker.
- The researcher later found the behavior still reproducible in development browser builds cited by the report.
- The bug details were made private again after exposure.
- The issue affects the Chromium browser family in principle, but final impact may vary by browser, version, and implementation details.
The unsafe conclusion would be to say there is confirmed mass exploitation, a working public exploit in broad circulation, or a shipped emergency patch. The source does not establish those points.
Why ordinary users should care#
Most users do not think of the browser as a background runtime. They think of it as a window. Close the window, close the page, stop the code.
This bug challenges that assumption.
If a web visit can leave JavaScript running after the browser is closed, the browser becomes closer to a background agent than a temporary app session. That changes the trust model for ordinary browsing. It also makes visibility weak: users may not see a tab, a window, or a download prompt.
The practical risk is higher because Chromium is not one product. It is a base layer. Chrome, Edge, Brave, Opera, Vivaldi, Arc, and other browsers all depend on Chromium in some form. When a Chromium-level issue exists, the remediation path can involve multiple vendors and release channels.
What to check now#
There is no perfect user-side mitigation listed in the source. But there are sensible steps.
Update your Chromium-based browser as soon as new stable releases arrive. Do not rely only on the fact that auto-update is enabled. Open the browser’s about/settings update page and force a check.
If you use multiple Chromium-based browsers, check each one. Chrome being current does not make Edge, Brave, Opera, Vivaldi, or Arc current.
Be careful with unknown sites that ask you to start downloads or trigger unusual browser behavior. This is not a complete defense, because the report describes low-interaction behavior, but it still reduces exposure to opportunistic abuse.
For managed environments, security teams should watch for emergency Chromium updates across all installed browsers, not just Chrome. Browser inventory matters here. Many fleets have secondary browsers installed that do not get the same patch attention as the default browser.
Teams can also monitor for unusual browser-originated outbound traffic after browser closure. That may not be simple, and it may produce noise, but the behavioral signal fits the risk model described in the report.
The larger lesson#
The bug is important. The process failure may be more important.
Security disclosure systems depend on state accuracy. “Fixed” is not just a label. It can trigger access changes, bounty workflows, public visibility, and downstream vendor assumptions.
Here, the public record described by BleepingComputer suggests a mismatch between tracker state and delivered protection. The result was accidental exposure of vulnerability details before a confirmed shipped fix.
That is the part browser vendors and security teams should not ignore. Modern patch pipelines are automated because they have to be. But automation that trusts the wrong status field can turn a private vulnerability into a public one.