GHSA-gv2q-mqqv-365m
MEDIUMAngular Service Worker Policy-Bypass & Credential-Stripping Vulnerabilities
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
@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.2 |
| 📦npm | @angular/service-worker | ≥ 20.0.0-next.0&&< 20.3.22 | 20.3.22 |
| 📦npm | @angular/service-worker | ≥ 19.0.0-next.0&&< 19.2.23 | 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.15 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @angular/service-worker. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-gv2q-mqqv-365m is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-gv2q-mqqv-365m is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-gv2q-mqqv-365m. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-gv2q-mqqv-365m in your dependencies?
O3 detects GHSA-gv2q-mqqv-365m across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.