Security Bug

Important: Please do not change the component of this bug manually.

Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md

Please see the following link for instructions on filing security bugs: https://www.chromium.org/Home/chromium-security/reporting-security-bugs

Reports may be eligible for reward payments under the Chrome VRP: https://g.co/chrome/vrp

NOTE: Security bugs are normally made public once a fix has been widely deployed.

VULNERABILITY DETAILS

The CORP enforcement that commit e2b91876eb013 (crbug/497436273) added for the Service Worker Static Routing API cache source is wired incorrectly and does not actually block cross-origin responses. Enabling kServiceWorkerStaticRouterCORPCheck (and, for completeness, kServiceWorkerStaticRouterOpaqueCheck) has no effect on the subresource-embed bypass. A page in a crossOriginIsolated (COEP:require-corp) context can embed a cross-origin credentialed opaque response whose bytes were stored by a Service Worker via cache.put(...) and routed through the Static Routing API cache source.

Root cause: content/common/service_worker/service_worker_resource_loader.cc:99-106 passes resource_request.url as both the request_url and original_url arguments to network::CrossOriginResourcePolicy::IsBlockedByHeaderValue:

if (network::CrossOriginResourcePolicy::IsBlockedByHeaderValue(
        resource_request.url, resource_request.url,
        resource_request.request_initiator, corp_header_value,
        resource_request.mode, resource_request.destination,
        response->request_include_credentials, cross_origin_embedder_policy,
        is_enabled ? cross_origin_embedder_policy_reporter : nullptr,
        document_isolation_policy,
        is_enabled ? document_isolation_policy_reporter : nullptr)) {

resource_request.url is the SW-chosen cache key URL (for example a.test/service_worker/x), which is same-origin to the document because the attacker controls both the SW and the page. The CORP logic at services/network/public/cpp/cross_origin_resource_policy.cc:184-186 then derives target_origin from request_url and returns std::nullopt (allowed) on the same-origin short-circuit:

url::Origin target_origin = url::Origin::Create(request_url);
if (initiator == target_origin)
  return std::nullopt;

The check should compare the response’s actual origin. The general CacheStorage CORP check at content/browser/cache_storage/cache_storage_dispatcher_host.cc:169-176 does this correctly:

return CrossOriginResourcePolicy::IsBlockedByHeaderValue(
           response->url_list.back(), response->url_list.front(),
           document_origin, corp_header_value, RequestMode::kNoCors,
           ...)

With the SW Static Router path using resource_request.url instead, the added CORP flag is a no-op for the cache source. A compromised origin in a crossOriginIsolated context still embeds cross-origin credentialed no-CORP responses as subresources, defeating the exact protection CORP was designed to enforce in COEP contexts against Spectre-style reads.

Scope distinction from the previously-addressed class: the surrounding issue family (static router cache source needs CORP/opaque enforcement) is tracked at crbug/495999481 and crbug/497436273. This report is not the class-level discovery. It is a defect in the CORP fix implementation that ships in current main. Turning the flag on via Finch would not close the bypass.

Reachability:

• Attacker controls origin attacker.example.
• Attacker’s page sets Cross-Origin-Embedder-Policy: require-corp and Cross-Origin-Opener-Policy: same-origin, reaches window.crossOriginIsolated === true.
• Attacker SW does fetch(victim, {mode: 'no-cors', credentials: 'include'}) and stores the opaque response in a cache.
• Attacker SW registers a router rule mapping a same-origin URL to the cache source.
• Attacker page embeds the same-origin URL as an <img>. The image loads. naturalWidth and naturalHeight are readable cross-origin.

With all fix flags enabled, the same attack succeeds.

Capability uplift:

1. Cross-origin credentialed image dimensions are directly readable, defeating the CORP protection Chrome is rolling out.
2. crossOriginIsolated context exposes SharedArrayBuffer and precise timers. CORP blocks cross-origin content from entering this process for Spectre-defence reasons. The bypass reopens Spectre-style side channels against any cross-origin resource the attacker chooses to cache.

VERSION

Chrome Version: built from main branch 2026-04-23, out/fuzz_asan with is_asan=true, commit tree at HEAD. Operating System: Linux (debian bullseye sysroot), x86_64.

REPRODUCTION CASE REPRODUCTION CASE

Two attached files drive an end-to-end repro against stable Chrome. No Chromium build required.

Attached files:

• POC-sw-static-router-CORP-bypass.html — attacker client page + driver script (origin A).
• POC-sw-static-router-CORP-bypass.sw.js — Service Worker script, saved as sw.js at origin A web root.

Setup (two distinct secure origins mapped to loopback):

1. Create web roots and drop the attached files:

   mkdir -p /tmp/sw-poc/a /tmp/sw-poc/b
   cp POC-sw-static-router-CORP-bypass.html    /tmp/sw-poc/a/index.html
   cp POC-sw-static-router-CORP-bypass.sw.js   /tmp/sw-poc/a/sw.js
   # any 100x50 PNG works — keep the dimensions small so the leak is visible
   convert -size 100x50 xc:red /tmp/sw-poc/b/animated.png
   

2. Generate a self-signed cert with SANs for both hostnames:

   openssl req -x509 -newkey rsa:2048 -nodes -days 30 \
     -keyout /tmp/sw-poc/key.pem -out /tmp/sw-poc/cert.pem \
     -subj /CN=a.test \
     -addext 'subjectAltName = DNS:a.test, DNS:b.test'
   

3. Start origin A (COEP/COOP only on HTML; sw.js MUST NOT carry COEP or the worker inherits it and cannot fetch cross-origin):

   # /tmp/sw-poc/server_a.py
   import http.server, ssl
   class H(http.server.SimpleHTTPRequestHandler):
       def __init__(self, *a, **k): super().__init__(*a, directory='/tmp/sw-poc/a', **k)
       def end_headers(self):
           if self.path in ('/', '/index.html') or self.path.endswith('.html'):
               self.send_header('Cross-Origin-Embedder-Policy', 'require-corp')
               self.send_header('Cross-Origin-Opener-Policy',   'same-origin')
           super().end_headers()
   s = http.server.ThreadingHTTPServer(('0.0.0.0', 4443), H)
   ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
   ctx.load_cert_chain('/tmp/sw-poc/cert.pem', '/tmp/sw-poc/key.pem')
   s.socket = ctx.wrap_socket(s.socket, server_side=True); s.serve_forever()
   

4. Start origin B (no CORP header on the victim image):

   # /tmp/sw-poc/server_b.py — identical to server_a but directory=/tmp/sw-poc/b,
   # port 4444, and empty end_headers() (no COEP/COOP/CORP).
   

5. Launch Chrome against the loopback cert:

   google-chrome \
     --ignore-certificate-errors \
     --host-resolver-rules='MAP a.test 127.0.0.1, MAP b.test 127.0.0.1' \
     --user-data-dir=/tmp/sw-poc-profile \
     https://a.test:4443/
   

   --ignore-certificate-errors is required because Service Worker subresource fetches fail silently against untrusted certs (no interstitial bypass path inside the SW). mkcert + OS trust store works too.

6. In the browser: enter https://b.test:4444/animated.png as the victim URL and click Run POC. On first run the SW registers but is not yet controlling; reload the page once to finish controlling, then click Run POC again.

Expected output (runtime-confirmed on stable Chrome, 2026-04-23, all fix flags enabled via --enable-features=ServiceWorkerStaticRouterOpaqueCheck,ServiceWorkerStaticRouterCORPCheck):

isolation = {"crossOriginIsolated":true,"isSecureContext":true}

[1] register sw.js?https%3A%2F%2Fb.test%3A4444%2Fanimated.png
    SW installed + controlling

[2] control: direct <img src="https://b.test:4444/animated.png">
    {"status":"error"}

[3] attack: <img src="/service_worker/x"> (router -> cache -> victim)
    {"status":"loaded","naturalWidth":100,"naturalHeight":50}

VERDICT
    CORP BYPASS CONFIRMED — cross-origin opaque bytes embedded
    leaked dimensions: 100x50

DevTools network panel shows the control request blocked as ERR_BLOCKED_BY_RESPONSE.NotSameOriginAfterDefaultedToSameOriginByCoep — the exact CORP defence the attack sidesteps.

Interpretation:

• crossOriginIsolated=true confirms the COEP context is active.
• Control (direct cross-origin <img>) fails with the standard CORP / defaulted-to-same-origin-by-COEP block.
• Attack (/service_worker/x via router → cache → victim) loads. naturalWidth and naturalHeight expose information about the cross-origin credentialed response. Result is unchanged with both fix flags enabled.

Suggested fix: at content/common/service_worker/service_worker_resource_loader.cc:99, pass response->url_list.back() (and an appropriate entry for original_url) instead of resource_request.url, matching the pattern already used at cache_storage_dispatcher_host.cc:169-176.

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION

Not a crash. Cross-origin policy bypass.

CREDIT INFORMATION

Externally reported security bugs may appear in Chrome release notes. If this bug is included, how would you like to be credited? Reporter credit: David Bors, Catalin Iovita