devtake.dev

Google's bug tracker auto-published exploit code for an unpatched Chromium flaw. The bug is still live.

Chromium Issue 1396278 went public on May 20 because Google's tracker auto-clears restrictions on stale closed bugs. The flaw, reported in 2022, was never fixed.

Luca Reinhardt · · 4 min read · 4 sources
Google Chrome logo on a dark background
Image: BleepingComputer · Source

Google’s Chromium Issue Tracker dropped its access restrictions on bug 1396278 on May 20, making the exploit code, the bug report, and the proof-of-concept page world-readable. The bug isn’t patched. The researcher who reported it in 2022 confirmed the same day that the behavior still works against Chrome Dev 150 and Edge 148.

The system that exposed it was Google’s own automation. Chromium bugs flip to public after they’ve been marked fixed for 14 weeks, on the assumption that the patch has shipped, ridden a Chrome stable cycle, and made it into every downstream browser. This bug was marked fixed on February 12, 2026, nothing actually landed in the codebase, and the timer expired anyway. Google pulled the issue private again after the disclosure cycle started, but the report and code are mirrored on archival sites and at this point cannot be put back.

What the bug actually does

Independent security researcher Lyra Rebane filed Chromium Issue 1396278 in December 2022. The problem lives in the way Chromium’s Browser Fetch API hands off to a Service Worker. The API is the standard primitive for downloading large files (videos, archives, app payloads) in the background without blocking the page, and Service Workers are how Chromium keeps the download alive when the user closes the tab.

Rebane found that a malicious page can register a Service Worker that opens a background fetch and then never completes it. The fetch keeps the worker alive. The worker keeps executing JavaScript. The tab closing doesn’t stop it. The user closing the browser stops it on Chrome, but Rebane noted in the bug report that “Edge no longer even makes the download menu pop up, so it’s completely silent JS RCE that keeps running even after you close the browser!”

The exploit code Google’s tracker exposed is short. It registers a Service Worker, fires off a fetch() to a large remote resource, intercepts the response in the worker, and keeps the connection open as a covert command channel. Rebane described the scaling math bluntly: “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.”

Why the patch didn’t ship

Chromium classified the issue as Priority 1, Severity 2 in 2022. That’s the second tier of urgency, below “actively exploited,” and the TechSpot writeup walks through what happened after: the bug bounced through teams, a Chrome engineer commented in mid-2023 that the Browser Fetch spec itself would need to change, the spec discussion stalled at the W3C, and the issue went quiet until Rebane re-tested the supposed February fix.

When the auto-public timer fired on May 20, Rebane re-ran the proof of concept against Chrome Dev 150 and Edge 148. The Service Worker stayed alive past tab close in both. There is no patch in Chrome Stable 149 (the May 13 release) and no patch advertised for the upcoming Chrome 151 stable bump. Microsoft hasn’t confirmed an Edge timeline.

Affected browsers extend past Chrome and Edge to every Chromium-based shell: Brave, Opera, Vivaldi, Arc, the new Tor Browser developer build. The recent GitHub VS Code extension breach showed how much enterprise attack surface routes through a Chromium-based runtime, and a persistent silent JavaScript RCE primitive in Service Workers is materially worse than the patched Chrome bugs from the last quarter.

What we don’t know

  • Whether the bug already has a quiet patch in flight. Google hasn’t responded to press inquiries since the May 20 disclosure. Chromium’s Gerrit doesn’t show a public review tied to issue 1396278.
  • Whether real-world exploitation is happening. No public threat report names the technique as of May 24. That doesn’t mean it isn’t being used; “silent JS that survives tab close” is exactly the primitive a banking trojan operator would value.
  • Whether the auto-publish timer itself gets revisited. Google’s policy makes sense when “marked fixed” actually means fixed. The Rebane case is the second time this year that a high-severity bug went public on auto, and the policy hasn’t changed.

What this means for you

If you run a corporate fleet on Chromium, treat Service Worker registration as suspect for the next week. The mitigations available today are blunt: Chrome enterprise policy can disable Service Workers per origin via ServiceWorkerCacheEnabled and ServiceWorkerLifecycle flags, at the cost of breaking PWAs and offline modes for the same origins. uBlock Origin and similar extensions already block third-party Service Workers on most ad networks, which removes the most plausible delivery path.

If you ship a Chromium-based product, watch the 151 release notes when they land. The fix the spec discussion stalled on in 2023 either appears now, or the wider Chromium fork ecosystem inherits the same liability the upstream tracker just published the playbook for. Subscribe a security inbox to Chromium’s release notes if you don’t already; the bug report’s existence in mirror form means the next 30 days are the highest-risk window the API has had in years.

Share this article

Quick reference

Service Worker
A JavaScript script the browser runs in the background for a website, designed to handle caching and offline behavior independent of any open tab.

Sources

Mentioned in this article