The Chromium service worker flaw: how to protect your browser and extensions

You close your browser. The windows are gone, the tabs are gone, you assume nothing's running. According to security reporting from BleepingComputer, that assumption is wrong on every Chromium-based browser right now — and the way we found out is that Google accidentally published the proof.

This isn't a malicious extension story. It's a platform story. But it lands squarely on extension security, because the exact mechanism at the center of it — the Chromium service worker — is the thing every modern Chrome extension runs its background logic on. So let me walk you through what broke, why it matters for the extensions you've got installed, and what you can actually do about it today.

What happened: Google published the exploit by accident

On May 20, 2026, Google's Chromium issue tracker automatically lifted the access restrictions on a bug report. That's a routine policy — reports get opened to the public after they've been closed for more than 14 weeks. The problem this time: the bug was marked "fixed" on February 12, 2026, but the patch was never actually shipped. So the auto-disclosure dumped working exploit details for a still-live flaw into public view.

According to BleepingComputer, the bug was first raised by security researcher Lyra Rebane back in 2022, which means it sat acknowledged and unpatched for more than three years. CSO Online corroborated the same account. The short version: a website can keep JavaScript executing in the background after you've fully closed the browser.

The trick abuses the Background Fetch API. That feature exists for a good reason — it lets large downloads keep going through a service worker even if you navigate away, so your file finishes instead of dying the moment you close a tab.

Rebane found that the same "never give up on this task" behavior can be pointed at attacker infrastructure instead of a download server. The service worker just keeps running. No window, no tab, no notification.

Researchers quoted by BleepingComputer were blunt about the impact. "It's realistic to get tens of thousands of pageviews for creating a 'botnet', and people won't be aware that JavaScript can be remotely executed on their device," Rebane said. On Microsoft Edge specifically, the description was that "you wouldn't even notice anything out of place, and would stay connected to the C2 even after closing the browser."

It affects everything built on Chromium — Chrome, Edge, Brave, Opera, Vivaldi, and Arc. There was no CVE assigned at the time of reporting, and Google had not publicly commented on the accidental disclosure as of late May 2026.

What a Chromium service worker actually does

Quick refresher, because this is the part that connects to extensions. A service worker is a small script the browser can run in the background, separate from any web page. It's the engine behind offline web apps, push notifications, and background sync. It's designed to be woken up when there's work, then shut down when there isn't.

That "shut down when there isn't work" part is the whole security and battery-life promise. A service worker isn't supposed to be a process you can pin open forever. The reported flaw breaks that promise: the Background Fetch path gives a page a task the browser won't terminate, so the worker outlives the browser session that spawned it.

The reason an attacker wants that is persistence. Most browser-based malicious code dies when you close the tab or quit the browser. A background task that survives a full browser close is a much more valuable foothold — you can use it to proxy traffic, contribute to a DDoS botnet, or hold a quiet command-and-control connection open, all of it invisible to the person whose machine is doing the work.

The Manifest V3 connection

Here's why I'm covering a website-level flaw on a blog about extension security. Manifest V3 — the platform every new Chrome extension ships on, and the one Chrome is forcing the last MV2 holdouts onto — moved extension background logic off the old persistent "background pages" and onto service workers. The headline justification was that service workers are ephemeral: they spin up, do their job, and get killed, so an extension can't just idle in the background forever burning resources or holding state it shouldn't.

This flaw pokes a hole in that mental model. I want to be precise here: the disclosed exploit is about malicious web pages, not extensions. No researcher has shown an extension using this specific Background Fetch trick, and you should be skeptical of anyone who tells you your extensions are now secretly running 24/7 because of it. That's not what the reporting says.

What it does show is that the "background work can't persist" guarantee underpinning MV3 isn't airtight at the platform level — and that a serious gap in it went unfixed for years. The architecture extensions depend on for their safety story has a demonstrated soft spot in the same primitive.

And it fits a pattern I keep running into. The browser's install-time permission prompt — the thing most people use to decide whether an extension is safe — never sees platform-level holes like this.

I made the same point in my earlier piece on zero-permission malware droppers: the permission screen gives you no signal about an entire class of risk. Same lesson here. The green "looks fine" checkmark is not the whole picture.

Why this matters for you

If you're a normal person who just uses Chrome or Edge, the practical risk is this: a single visit to a malicious or compromised site could leave a background task running on your machine after you think you've closed everything. You wouldn't see a window. On Edge, per the researchers, you might not see anything at all.

And detection is genuinely hard. Most of the defenses people lean on — antivirus, a firewall, a VPN — watch for files written to disk or obviously sketchy network destinations. A service worker quietly proxying traffic from inside your own browser doesn't necessarily trip any of those, especially when its requests look like ordinary web traffic. That's exactly what makes a flaw like this attractive to attackers and frustrating to defend against.

If you run a lot of extensions, the indirect lesson matters more than the direct one. Every extension you install with broad access widens the surface for the next bug — whether it's a platform flaw like this one or a compromised extension update. The flaw itself isn't extension-borne, but it's a good prompt to ask: do I actually know what's installed in my browser and what each one can reach?

How to protect yourself

You can't patch Chromium yourself, and there's no extension that "fixes" this. But you're not helpless. Here's what actually moves the needle.

1. Fully quit your browser — don't just close the window. On Windows and macOS, closing the last window often leaves the browser process alive in the background for a faster relaunch. Use Quit (Cmd+Q on Mac, or right-click the taskbar/tray icon and Exit on Windows). If the process is gone, any rogue service worker goes with it.

2. Watch for a browser that won't die. If you "closed" Chrome but it's still showing up in Task Manager or Activity Monitor minutes later, chewing CPU with no windows open, that's worth a look. It's not proof of an attack — but it's exactly the symptom this flaw produces.

3. Stay on the latest stable channel. When Google ships the real fix, it'll arrive through a normal browser update. Don't sit on an old build. Enterprise IT teams: track the eventual CVE and patch note instead of trusting the February "fixed" label, which clearly didn't mean what it said.

4. Clear site data for anything you don't trust. Service workers register per-site. Clearing browsing data — specifically "cookies and other site data" — unregisters service workers a sketchy site may have left behind. If you visited something dodgy, wipe its data.

5. Audit your extensions while you're at it. This flaw isn't on your extensions, but the ones you forgot you installed are the ones that quietly accumulate risk. Fewer extensions with broad access means a smaller blast radius for everything, including the next platform bug.

How Extenshi helps

The install-time prompt fails you exactly where stories like this live, and a second opinion helps. Extenshi scans extensions for the permissions and behaviors that actually matter — not just the headline permission string, but what an extension can reach and what it does with that reach. If you've got a drawer full of extensions you don't remember adding, that's where to start.

Scan your extensions → to see what's really running with access to your data. You can also browse the catalog to check an extension's security profile before you install it.

My take

The scariest part of this isn't the bug. Background-persistence bugs happen, and researchers find them. The scary part is the process around it: a serious flaw stayed acknowledged and unfixed for years, got mislabeled as fixed, and then went public by accident through Google's own auto-disclosure timer. That's a process failure on top of a code one.

Until the patch actually ships, my advice is simple. Treat "I closed my browser" as "I probably closed my browser," quit it fully when you're done, and keep the number of extensions with deep access as small as you can live with.

---

This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If you believe any information is inaccurate, please contact us at [email protected].