You close your browser. You walk away. You assume it’s done.
A newly surfaced Chromium issue challenges that gut feeling: a Service Worker task can be created in a way that never terminates, keeping JavaScript running in the background even after you “close” the browser. The researcher who reported it says it can turn a Chromium-based browser into a persistent JavaScript botnet member with no clicks beyond visiting a page once . That’s not sci-fi. That’s a real “wait… what?” moment.
What was reported: the “never-ending Service Worker” that won’t let go
Service Workers are supposed to be the “background helper” for websites.
They’re the reason your favorite site can load faster on repeat visits, work offline, or send push notifications. Technically, a Service Worker is a JavaScript file your browser can run separately from a tab, so it can handle things like caching, background sync, and network requests even when you’re not actively looking at the page.
The problem in the report is what happens when that background helper stops behaving like a helper and starts behaving like a squatter.
Security researcher Lyra Rebane described a Chromium Service Worker bug where a webpage can create a Service Worker task (the example discussed is a download task) in a way that never terminates . If the task doesn’t end, Chromium doesn’t fully “let go” of the worker. Net result: JavaScript keeps running in the background even after you close the browser .
That’s the part that messes with your intuition. Most people treat closing the browser window as the finish line. This bug challenges that assumption: your “closed” Chromium-based browser can still be doing work in the background because the Service Worker never hits a clean shutdown point .
Why it’s so hard to notice
Even if you’re the kind of person who watches for weird browser behavior, this report has an extra twist: the visibility cues may be disappearing.
Rebane noted that in newer Microsoft Edge builds, the download pop-up/menu that used to appear when triggering the exploit no longer shows up . That turns something suspicious (“why is Edge downloading something?”) into something silent (“nothing happened… right?”) while the Service Worker can keep running.
The core claim, in plain terms
If you strip it down to basics, the reported Chromium issue is:
- Visit a page once
- That page registers a Service Worker
- The worker starts a task engineered to never finish
- Your browser keeps a background process alive
- JavaScript can continue executing after the browser is “closed”
That’s why the phrase “persistent JavaScript” shows up so often in discussion of this bug. It’s not about a normal tab staying open. It’s about background execution that can outlive your session in a way users don’t expect.
Why it matters: persistence without you doing anything (and what attackers could do with it)
A normal web attack usually needs something from you: keep a tab open, approve a prompt, install an extension, run a file.
The reported risk here is uglier because it aims for persistence. Rebane’s point was simple: if you can get enough people to visit a page, you can get “tens of thousands of pageviews” and quietly turn those browsers into a kind of JS botnet, with users unaware that code can keep executing on their device .
This isn’t “your laptop gets Hollywood-hacked in 30 seconds.” It’s more like your browser becomes a background worker for someone else’s agenda while you think you shut everything down.
What attackers could do with persistent background JavaScript
Once a browser can be kept running JavaScript in the background, it can be treated like a disposable node. The report calls out a few realistic outcomes :
- DDoS (distributed denial-of-service)
Your browser can generate repeated requests to a target site. One device isn’t impressive. Thousands are. - Proxying malicious traffic
The attacker can route traffic “through” victims’ browsers, making it harder to trace back and spreading the risk across many IPs . - Traffic redirection
Browsers can be used to send traffic to attacker-chosen destinations, inflating visits, stressing a service, or funneling users into scams .
Why this hits regular people (and companies) fast
Persistent background execution is a force-multiplier. It takes something already common—people clicking links—and turns it into ongoing activity.
The real-world pain tends to look boring, which is why it’s easy to miss:
- Unexplained network chatter on your home Wi‑Fi
- Battery drain or fans spinning when “nothing is open”
- Corporate egress traffic that makes security teams chase ghosts
- Your IP address showing up in abuse logs for traffic you didn’t send
Rebane also described the “always-on” angle in plain words: a Chromium-based browser could stay connected to a command-and-control server even after the user closes the browser . That’s the part that changes this from a one-time web nuisance into something operators can schedule, coordinate, and scale.
Who’s affected and the messy timeline: ‘fixed’ on paper, still reproducible in the wild
If you use a Chromium-based browser, you’re in the blast radius.
That’s not just Google Chrome. The report explicitly lists Microsoft Edge, Brave, Opera, Vivaldi, and Arc as impacted too . Different brands, same engine under the hood. When a Chromium core behavior goes sideways, it tends to travel.
Who’s affected (practical view)
If your browser is built on Chromium, treat it as potentially affected until a shipped fix is clearly confirmed for your exact version.
Common Chromium-based browsers mentioned in coverage include:
- Google Chrome
- Microsoft Edge
- Brave
- Opera
- Vivaldi
- Arc
The timeline, without the noise
This is where the story gets frustrating. It’s a long-running issue with a lot of “status changed” energy and not enough “users are safe” clarity.
Here’s the sequence as reported:
- December 2022: Reported and acknowledged as valid
The flaw was reported by Lyra Rebane and acknowledged as valid in December 2022, tied to discussion on the Chromium Issue Tracker . - October 26, 2024: A Google dev flags it as a serious vulnerability
A developer noticed it was still open and called it a “serious vulnerability”, pushing for a status update “to ensure that there’s progress” . - February 10 (year of the report): Marked fixed, then reopened minutes later
It was marked fixed and then reopened shortly after due to concerns . - February 12: Closed as fixed, but without a patch shipped
The issue was marked fixed in the system even though a patch hadn’t shipped, and the bug went through security program labeling; Rebane later received a $1,000 bounty email . - May 20: Accidental public exposure, then immediate retesting shows it still works
Access restrictions were removed because the issue had been closed for over 14 weeks and marked fixed . On the same day, Rebane retested and said the problem was still present in Chrome Dev 150 and Edge 148 .
That last point is the headline inside the headline: “fixed” as a tracker status isn’t the same thing as “fixed” on your machine. When a bug can still be reproduced in current developer channels after being closed out, it creates the worst possible mix—wide awareness, easy reproduction, and uncertainty about when the real fix lands.
What you can do right now: reduce exposure while waiting for a real patch
When an issue is “fixed” in a tracker but still reproducible in real builds , you don’t wait around for clarity. You tighten your setup so a one-time site visit can’t leave long-running browser baggage behind.
1) Update, then do a real restart (not just closing windows)
Updating matters, but it’s not the whole move.
- Update Chrome/Edge/Brave/Opera/Vivaldi/Arc to the latest stable available.
- After updating, fully quit the browser (File → Exit), then reboot your computer if you can.
- The goal is to stop any leftover background processes that can keep running even when the browser looks “closed.”
2) Hunt down and remove Service Workers you don’t trust
If you’ve been testing random sites, doing OSINT, or clicking unfamiliar links, this is worth 5 minutes.
Fast, user-friendly option (most people):
- Go to your browser’s Site settings / Privacy & Security
- Find Site data (or “Cookies and site data”)
- Search for domains you don’t recognize and remove stored data
That often clears the site’s local storage, cache, and registration state that lets background features stick around.
Targeted option (power users):
- Open DevTools → Application tab → Service Workers
- Review what’s registered per site and Unregister anything suspicious
3) Turn off the “quiet helpers” you don’t need
Service Workers often show up alongside features that are great for convenience and bad for stealth.
Consider tightening these per-site (or globally if you can live with it):
- Notifications: block by default
- Background sync: limit when possible
- Pop-ups / redirects: block by default
You’re not trying to break the web. You’re trying to stop “background privileges” from being the default.
4) Extension hygiene (the boring win)
Extensions aren’t the same issue as this Chromium bug, but they amplify damage when something weird is already happening.
- Remove anything you don’t actively use
- Avoid “free” utilities that ask for broad access
- Check for extensions with “read and change data on all websites” and cut aggressively
5) Managed devices: use enterprise controls if you have them
If you’re in IT or security, don’t rely on “user behavior” as your control.
Use enterprise policy to:
- restrict or disable Service Worker behavior where it’s not required
- control which sites can run advanced background features
One practical privacy step if you must visit sketchy sites
Sometimes your job forces you onto low-trust sites: threat research, vendor checks, scraping, even just chasing a lead.
At that point, reducing exposure also means reducing what you hand over. Tools like Cloaked can help by giving you masked emails and phone numbers for sign-ups, so if a site turns out to be spammy (or worse), you’re not also dealing with account takeovers, inbox floods, and identity breadcrumbs tied to your real contact info.
The key limitation: scary persistence, but not instant access to your files
It’s worth drawing a hard line here, because a lot of people hear “silent JavaScript RCE” and assume it means “they can read my whole computer.”
That’s not what the researcher claimed.
Lyra Rebane explicitly clarified that the bug does not bypass browser security boundaries and doesn’t give attackers access to your emails, files, or the host OS . In plain terms: this is not an automatic “open your laptop like a book” situation.
What “doesn’t bypass the OS” actually means
Even if a Service Worker can keep running JavaScript in the background, it’s still operating inside the browser’s sandboxed environment.
So, by default, it can’t:
- Browse your file system like File Explorer/Finder
- Read your local email app or your mailbox
- Jump into other apps on your machine
That boundary matters. A lot.
Why it’s still a serious problem
The limitation doesn’t make it harmless. It just changes the damage profile.
Persistent, silent background execution can still:
- Burn bandwidth (your connection gets “rented out” without consent)
- Create reputational risk (your IP shows up in abuse reports or attack logs)
- Add corporate network noise (security teams see outbound spikes and have to chase the source)
- Drain battery / resources on laptops that are supposed to be “done for the day”
And because Rebane described it as silent in practice—especially in Edge, where nothing obvious pops up during triggering —the user feedback loop breaks. People don’t investigate what they can’t see.
So yes, it’s not instant file theft. But a browser that can keep doing attacker-directed work after you think it’s closed is still a real security event, not a quirky bug.
