CVE-2026-50170

A vulnerability was discovered in `@angular/common` when Server-Side Rendering (SSR) and hydration are enabled. The `HttpTransferCache` utility optimizes hydration by caching outgoing HTTP requests performed during SSR and transferring the cached state to the client-side application via `TransferState`. However, the caching mechanism fails to inspect the `withCredentials` flag or the `Cookie` header of outgoing requests. As a result, credentialed, user-specific responses may be cached by default in the shared `TransferState` payload. When these responses are serialized into the HTML, any caching layer (such as a CDN, reverse proxy, or shared server cache) that caches the SSR-rendered HTML page could inadvertently cache and leak one user's private data to other users, leading to a high-severity information disclosure vulnerability. ### Impact Successful exploitation allows an unauthenticated attacker to obtain sensitive, user-specific information of other authenticated users. This occurs when: * The SSR-rendered HTML containing the cached private data is stored in a shared cache (e.g., CDN, reverse proxy). * Subsequent requests for the same page receive the cached HTML containing the first user's private data. ### Attack Preconditions * **SSR and Hydration Enabled:** The Angular application must be configured to use Server-Side Rendering and hydration (e.g., using `provideClientHydration()`). * **Credentialed Requests during SSR:** The application must perform HTTP requests that require user-specific authentication (using cookies or `withCredentials: true`) during the initial server-side render. * **Shared Caching:** The application's HTML responses must be cached by a shared caching layer (CDN, reverse proxy, or server-side cache) without proper cache-control headers to distinguish authenticated users. ### Patches - 22.0.0-rc.2 - 21.2.15 - 20.3.22 - 19.2.23

A vulnerability was discovered in `@angular/common` when Server-Side Rendering (SSR) and hydration are enabled. The `HttpTransferCache` utility optimizes hydration by caching outgoing HTTP requests performed during SSR and transferring the cached state to the client-side application via `TransferState`. However, the caching mechanism fails to inspect the `withCredentials` flag or the `Cookie` header of outgoing requests. As a result, credentialed, user-specific responses may be cached by default in the shared `TransferState` payload. When these responses are serialized into the HTML, any caching layer (such as a CDN, reverse proxy, or shared server cache) that caches the SSR-rendered HTML page could inadvertently cache and leak one user's private data to other users, leading to a high-severity information disclosure vulnerability. ### Impact Successful exploitation allows an unauthenticated attacker to obtain sensitive, user-specific information of other authenticated users. This occurs when: * The SSR-rendered HTML containing the cached private data is stored in a shared cache (e.g., CDN, reverse proxy). * Subsequent requests for the same page receive the cached HTML containing the first user's private data. ### Attack Preconditions * **SSR and Hydration Enabled:** The Angular application must be configured to use Server-Side Rendering and hydration (e.g., using `provideClientHydration()`). * **Credentialed Requests during SSR:** The application must perform HTTP requests that require user-specific authentication (using cookies or `withCredentials: true`) during the initial server-side render. * **Shared Caching:** The application's HTML responses must be cached by a shared caching layer (CDN, reverse proxy, or server-side cache) without proper cache-control headers to distinguish authenticated users. ### Patches - 22.0.0-rc.2 - 21.2.15 - 20.3.22 - 19.2.23