CVE-2026-50169, CVE-2026-50184 & CVE-2026-54264: Angular Service Worker Request-Policy Stripping

On June 22, 2026, three related vulnerabilities were disclosed in the @angular/service-worker package via GitHub Security Advisory: CVE-2026-50169, CVE-2026-50184, and CVE-2026-54264. All three share one root cause. When the Angular Service Worker intercepts a request for a matched asset, it rebuilds a new Request object from scratch, and in doing so it drops or mishandles the strict, client-defined properties the application set on the original request. CVE-2026-50169 (CWE-441 Confused Deputy) strips the redirect: 'error' policy and silently follows 3xx redirects the app meant to reject. CVE-2026-50184 (CWE-524) strips credentials: 'omit' and the HTTP cache mode, sending cookies where the developer said not to and caching private responses. CVE-2026-54264 (CWE-359) fails to strip sensitive headers on cross-origin redirects, leaking Authorization, Cookie, and Proxy-Authorization to untrusted origins. NVD scores all three 6.1 Medium (CVSS v3.1); GitHub, the CNA, scores the first two 5.7 Moderate and 54264 an 8.3 High on CVSS v4. Angular 20 through 22 received full upstream patches. Angular 19, EOL since May 19, 2026, got fixes for the first two only: there is no 19.x patch for CVE-2026-54264 and none is coming. Angular 18 and earlier get no OSS fix for any of the three.

Affected and unsupported? See NES for Angular.

‍

Why the service worker layer matters

The Angular Service Worker (@angular/service-worker, configured through ngsw-config.json) sits between your application code and the network. When it is registered, it intercepts fetch events for assets it manages and serves them from cache or reconstructs the network request itself. That interception is the whole point: it is what makes an Angular app work offline and load instantly on repeat visits.

But it also means the service worker becomes the thing that actually talks to the network, on behalf of your code. Your application sets a request policy, things like redirect: 'error', credentials: 'omit', cache: 'no-store', precisely because those flags encode security decisions. "Do not follow this redirect." "Do not send my cookies here." "Do not persist this response." When the service worker rebuilds the request and quietly drops those flags, it substitutes the browser's permissive defaults (redirect: 'follow', credentials: 'same-origin', default caching) for the developer's explicit, stricter intent.

That is the pattern across all three CVEs. The service worker is a deputy acting on your behalf, and it stopped honoring your instructions. This is the same request-reconstruction surface that made Angular's 2026 disclosure run so unusual, and we covered the broader trend in Angular's 2026 CVE surge: 21 new advisories, no patches for EOL apps.

‍

What are these CVEs?

CVE-2026-50169: redirect-policy bypass

A Confused Deputy flaw (CWE-441, with CWE-200 and CWE-524). During request reconstruction the helper drops the client-defined redirect mode. An application that set redirect: 'error', expecting a network error instead of an automatic redirect, gets the browser default follow instead. The service worker then follows HTTP 3xx redirects to destinations the app explicitly intended to block. If a public, dynamically routed endpoint redirects to a sensitive same-origin route, the service worker walks straight into it and can expose session-restricted data.

CVE-2026-50184: credential and cache-mode stripping

An information-exposure flaw (CWE-200, CWE-524). Reconstruction reverts two client-defined safety parameters to browser defaults: credentials: 'omit' becomes credentials: 'same-origin', and an explicit cache mode such as no-store is dropped. The first sends active credentials (cookies, Authorization headers) on outbound requests where the developer explicitly instructed they be omitted. The second lets private or non-cacheable responses get cached by the service worker engine, so private page state stays readable in the local cache after logout.

CVE-2026-54264: sensitive header leakage on cross-origin redirects

An information-disclosure flaw (CWE-359, CWE-200). When the service worker fetches an asset, it preserves the original request's metadata, including headers. On a cross-origin redirect it fails to strip sensitive headers, which violates the Fetch specification's redirect algorithm. A remote attacker who can trigger a cross-origin redirect to an external origin receives Authorization tokens, Proxy-Authorization credentials, or session cookies that were only ever meant for the original origin. This is the highest-impact of the three, and its version footprint is different from the other two (see the table below).

‍

Severity and exploit conditions

There is a genuine divergence between NVD and the CNA here, and it matters for prioritization, so both are disclosed with attribution.

NVD analyzed all three and assigned each a CVSS v3.1 base score of 6.1 Medium (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N). GitHub, as the assigning CNA, scored them on CVSS v4:

The gap on 54264 is the one to note. NVD's v3.1 model caps the confidentiality impact at Low and does not have a clean way to express "credentials leak to a different origin," so it lands at 6.1. The CNA's v4 vector does express that (VC:H plus SC:H, a high-confidentiality impact with a subsequent-system scope change) and lands at 8.3 High. If you triage by NVD score alone, you will under-rate 54264. Treat it as the High-severity member of the cluster.

Here is the full CVSS v4 breakdown for CVE-2026-54264, the most severe:

PR:N across all three means none of these require authentication. The attacker does not need an account on the target app. What they need is the ability to influence a route or redirect the app will follow, which is the precondition that varies by CVE.

‍

Exploitation status

As of publication there is no public, weaponized proof-of-concept exploit and no working exploit code published for any of the three CVEs, and none appears in the CISA Known Exploited Vulnerabilities catalog. Third-party vulnerability trackers have published conceptual write-ups describing the attack shape (for example, the general "force the victim to a public route that redirects to an authenticated endpoint" pattern for 50184), but these are analyses of the advisory, not runnable exploits.

That said, the exploit preconditions are not exotic. All three are unauthenticated (PR:N), and 54264 in particular needs only a cross-origin redirect the attacker can influence plus a victim browsing the app normally. The primary sources are the Angular project's own advisories: GHSA-gv2q-mqqv-365m, GHSA-95qp-cmmw-mgqv, and GHSA-qxh6-94w6-9r5p.

‍

What an attacker can do

Concretely, across the three flaws:

• Follow a redirect the app blocked (50169). The app sets redirect: 'error' on a request to a public dynamic route. The attacker arranges for that route to return a 3xx pointing at a sensitive same-origin route (for example a redirect from /go?to= into an authenticated /account/settings view). The service worker, having dropped the error policy, follows it and returns the sensitive response to a context that was supposed to see a network error.
• Exfiltrate cookies and tokens the app said to omit (50184). The app calls an endpoint with credentials: 'omit', deliberately, to avoid attaching the session. The service worker restores same-origin credentials, so cookies and Authorization headers ride along on a request that was designed to be anonymous.
• Persist private data past logout (50184). A response marked cache: 'no-store' gets cached by the service worker engine anyway. After the user logs out, their private page state is still sitting in the ngsw: caches, readable by anything with access to that browser profile.
• Leak credentials to an external origin (54264). The app makes an authenticated request that gets redirected cross-origin. Instead of stripping Authorization, Cookie, and Proxy-Authorization on the cross-origin hop (as the Fetch spec requires), the service worker forwards them intact to the attacker-controlled external origin.

‍

Who is affected?

The first two CVEs share a version footprint and were fixed together in the June batch. CVE-2026-54264 was disclosed the same day but fixed in a later patch set, affects the 19.x line as well, and has a different set of fix versions. Looking at this per CVE:

Two things to flag from this table. First, if you are on Angular 19, upgrading to 19.2.23 closes 50169 and 50184 but does not close 54264, because that fix only landed in the 20.3.25 / 21.2.17 / 22.0.1 lines. Angular 19 reached end of life on May 19, 2026, so there is no 19.x patch coming for 54264. To fully remediate all three on the supported path you have to move to Angular 20.3.25 or later. Second, Angular 18 and earlier are fully EOL (Angular 18 reached end of life on November 21, 2025) and will receive no upstream fix for any of the three.

‍

Mitigation guidance

If you are running an EOL Angular version and a full framework migration is not viable on your timeline, NES for Angular ships drop-in replacement builds with these vulnerabilities resolved, so you can close the gap without the breaking-change risk of a rushed major-version jump. HeroDevs maintains NES for Angular in coordination with the Angular ecosystem, covering EOL versions back through the early v4-era releases.

‍

Related CVEs

This cluster is part of a larger run of Angular disclosures in 2026, several of them in the same SSR and request-handling surface:

• CVE-2026-50169 and CVE-2026-50184: the sibling service-worker flaws in this post.
• CVE-2026-50168: Angular SSR SSRF allowlist bypass, disclosed in the same June window.
• CVE-2026-50555 and CVE-2026-50556: two high-severity XSS flaws in Angular SSR's DOM serialization layer.
• CVE-2026-27970: XSS in Angular i18n ICU messages.

For the full picture of why 2026 has produced so many Angular advisories at once, see Angular's 2026 CVE surge: 21 new advisories, no patches for EOL apps.

‍

Taking action

These three CVEs are the same lesson told three ways: the service worker is a deputy that acts on your app's behalf, and when it stops honoring the request policy your code set, your security decisions quietly stop applying. Redirect blocks get ignored, omitted credentials get sent, and cross-origin hops leak tokens.

If you are on a supported line, the fix is a version bump: Angular 20.3.25, 21.2.17, or 22.0.1 closes all three. Watch the Angular 19 case specifically, where 19.2.23 leaves CVE-2026-54264 open with no upstream 19.x patch, because 19 is now EOL.

And that EOL cliff is the real exposure. Angular 18 and earlier get no fix for any of these, and download data shows EOL Angular is still running in production at scale: nearly half of all weekly @angular/core installs are for EOL major versions. If migrating off an EOL version is not realistic on your timeline, NES for Angular gives you drop-in patched builds that resolve these vulnerabilities so you can stay compliant without a rushed rewrite. Compare your options on pricing or talk to us about your stack.