CVE-2026-50169 — @angular/service-worker
Fix: angular/angular#67494CVE-2026-50169 is a Information Exposure vulnerability in @angular/service-worker. A fix is available for @angular/service-worker — see the affected versions and patch details below.
Angular Service Worker Policy-Bypass & Credential-Stripping Vulnerabilities
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-50169.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@angular/service-workernpmDescription
An issue in the @angular/service-worker package compromises the integrity of request-policy enforcement during request reconstruction. When the Angular Service Worker intercepts network requests for matched assets, it reconstructs a new Request object using an internal helper function.
During this reconstruction process, the helper function strips the strict, client-defined request redirect policy configuration (such as redirect: 'error'), falling back to the browser's default 'follow' strategy.
If the target web application makes client-side requests with a strict policy (e.g., expecting a network error instead of automatically following redirects), the service worker will bypass this instruction and automatically follow HTTP 3xx redirects to other destinations. This acts as an unintended proxy/intermediary ("Confused Deputy") and can result in cookie/credential exposure or same-origin session-restricted data leakage if public dynamic routes redirect to sensitive routes.
Impact
Web applications registering the @angular/service-worker package are vulnerable to this redirect-policy bypass if they make safe client-side fetch calls (such as { redirect: 'error' }) to paths matched by a service worker asset group (such as lazy-loaded JavaScript bundles or dynamic public assets) that can return HTTP redirects to authenticated same-origin secure endpoints.
By stripping developer-defined safety boundaries, the service worker allows the browser to transparently query and return data from credentials-guarded resources that should have been blocked at the network barrier.
Attack Preconditions
To successfully exploit this vulnerability, all of the following application states and parameters must concurrently exist:
- Active Angular Service Worker: The target application uses
@angular/service-workerand has an active registration ofngsw-worker.jsinside the client's browser context. - Asset Group Matching: An
assetGroupspattern inngsw-config.jsonencompasses the target dynamic routing endpoint. - Same-Origin Dynamic Redirection: The server routes a public matched asset route to a service that returns an HTTP 3xx redirect pointing to a sensitive, session-restricted same-origin private route (e.g.,
/private/account-summary.json). - Established User Session: The victim user currently has an active authentication state, such as valid same-origin session cookies or auth headers stored by the browser.
- Client-Side Safe Fetch Call: The application initiates an explicit fetch request to the route with safety parameters:
{ redirect: 'error' }.
Mitigations & Workarounds
If upgrading the @angular/service-worker package is not immediately feasible, developers should implement the following defensive measures:
- Avoid Public-to-Private Dynamic Redirection: Refactor the server architecture so that public paths matched by service worker asset groups never issue HTTP 3xx redirects to authenticated same-origin secure endpoints.
- Strict Cookie Configuration: Apply strict flags to session cookies (
SameSite=Strict; Secure; HttpOnly) and consider explicit route isolations (such as subdomains) for credential-guarded private resources. - Exclude Secure Endpoints from SW Config: Verify your
ngsw-config.jsonsettings and ensure that patterns targeting dynamic, secure endpoints are explicitly excluded from automatic asset groups or caching scopes.
Patches
- 22.0.0-rc.2
- 21.2.15
- 20.3.22
- 19.2.23
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @angular/service-worker | ≥ 22.0.0-next.0&&< 22.0.0-rc.2 | 22.0.0-rc.2npm install @angular/service-worker@22.0.0-rc.2 |
| 📦npm | @angular/service-worker | ≥ 20.0.0-next.0&&< 20.3.22 | 20.3.22npm install @angular/service-worker@20.3.22 |
| 📦npm | @angular/service-worker | ≥ 19.0.0-next.0&&< 19.2.23 | 19.2.23npm install @angular/service-worker@19.2.23 |
| 📦npm | @angular/service-worker | all versions | No fix |
| 📦npm | @angular/service-worker | ≥ 21.0.0-next.0&&< 21.2.15 | 21.2.15npm install @angular/service-worker@21.2.15 |
Affected Products
angularangularDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @angular/service-worker, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @angular/service-worker to 22.0.0-rc.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-50169 is resolved across your whole dependency graph.
Workarounds
Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.
Frequently Asked Questions
Is CVE-2026-50169 in your dependencies?
Find it across npm, including transitive dependencies.