Yenya030

**Name of the Vulnerable Software and Affected Versions** Angular versions prior to 22.0.0-rc.2 Angular versions prior to 21.2.15 Angular versions prior to 20.3.22 Angular versions prior to 19.2.23 **Description** 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 uses an internal helper function to reconstruct a new `Request` object. This process strips client-defined request redirect policy configurations, such as `redirect: 'error'`, and reverts to the browser's default 'follow' strategy. Consequently, if an application makes client-side requests with a strict policy, the service worker bypasses this instruction and automatically follows HTTP 3xx redirects. This creates a Confused Deputy scenario—where a privileged entity is tricked into performing an action on behalf of an unauthorized party—which can lead to cookie or credential exposure and the leakage of same-origin session-restricted data if public dynamic routes redirect to sensitive routes. **Recommendations** Update to version 22.0.0-rc.2. Update to version 21.2.15. Update to version 20.3.22. Update to version 19.2.23. Refactor server architecture to ensure public paths matched by service worker asset groups do not issue HTTP 3xx redirects to authenticated same-origin secure endpoints. Apply strict flags to session cookies (`SameSite=Strict; Secure; HttpOnly`) and use explicit route isolations, such as subdomains, for credential-guarded private resources. Modify `ngsw-config.json` to ensure patterns targeting dynamic, secure endpoints are explicitly excluded from automatic asset groups or caching scopes.

**Name of the Vulnerable Software and Affected Versions** Angular versions prior to 22.0.0-rc.2 Angular versions prior to 21.2.15 Angular versions prior to 20.3.22 Angular versions prior to 19.2.23 **Description** An issue exists in `@angular/common` when Server-Side Rendering (SSR) and hydration are enabled. The `HttpTransferCache` utility optimizes hydration by caching outgoing HTTP requests during SSR and transferring the state to the client via `TransferState`. The caching mechanism does not inspect the `Cookie` header or the `withCredentials` flag of outgoing requests, causing credentialed, user-specific responses to be cached in the shared `TransferState` payload. When these responses are serialized into HTML, shared caching layers such as CDNs, reverse proxies, or shared server caches may store the SSR-rendered page and leak one user's private data to other users. This allows an unauthenticated attacker to obtain sensitive information of authenticated users if the application performs credentialed requests during the initial server-side render and uses a shared cache without proper cache-control headers. **Recommendations** Update to version 22.0.0-rc.2 Update to version 21.2.15 Update to version 20.3.22 Update to version 19.2.23

**Name of the Vulnerable Software and Affected Versions** Angular SSR versions prior to 21.2.0-rc.1, 21.1.5, 20.3.17, and 19.2.21 **Description** Angular SSR, a server-side rendering tool for Angular applications, contains a Server-Side Request Forgery (SSRF) issue in its request handling pipeline. The problem arises because the framework directly trusts and consumes user-controlled HTTP headers, specifically the `Host` and `X-Forwarded-*` family, to determine the application's base origin without proper validation. This lack of validation allows attackers to manipulate the base origin, leading to arbitrary internal request steering. This can result in credential exfiltration, internal network probing, and potential confidentiality breaches. The vulnerability manifests through implicit relative URL resolution and explicit manual URL construction. The application server must be reachable by an attacker who can influence these headers, and the infrastructure must not sanitize or validate incoming headers for exploitation to succeed. **Recommendations** Versions prior to 21.2.0-rc.1 should be upgraded to version 21.2.0-rc.1 or later. Versions prior to 21.1.5 should be upgraded to version 21.1.5 or later. Versions prior to 20.3.17 should be upgraded to version 20.3.17 or later. Versions prior to 19.2.21 should be upgraded to version 19.2.21 or later. Avoid using `req.headers` for URL construction and instead use trusted variables for base API paths. Implement a middleware in `server.ts` to enforce numeric ports and validated hostnames if immediate upgrade is not possible.

**Name of the Vulnerable Software and Affected Versions** go-ethereum (geth) versions prior to 1.16.8 **Description** go-ethereum (geth) is a golang execution layer implementation of the Ethereum protocol. A specially crafted message can force a vulnerable node to shutdown or crash. This can be triggered remotely without requiring authentication. **Recommendations** Upgrade to version 1.16.8.