| Risiko / Label | Veröffentlichung | |
|---|---|---|
| Risiko 2 / 10 CVE-2026-49356 | vor 1 Stunde(n) | |
| ## Impact Using `@babel/core` to compile maliciously crafted code can allow ab attacker to read any source map from the system that is running Babel, if these conditions are _all_ true: - the attacker controls the input source code - the attacker can read the output source code - the attacker knows the path of the source map file that they want to read **Users that only compile trusted code are not impacted.** ## Patches The vulnerability has been fixed in `@babel/core@7.29.6` and `@babel/core@8.0.0-rc.6`. ## Workarounds Callers can mitigate the issue without upgrading by setting [`inputSourceMap: false`](https://babeljs.io/docs/options#inputsourcemap) in their Babel options. Callers can also manually extract the `#sourceMappingURL` comment from the input source code, validate whether the source map that it links to is allowed to be read, and if it is pass an object to `inputSourceMap` (passing `false` when it's not). ## Credits Thanks Teodor-Cristian Radoi for reporting the vulnerability. | ||
| Risiko 5 / 10 CVE-2026-50184 | vor 1 Stunde(n) | |
| 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 explicit client-defined safety parameters: the credentials configuration (such as `credentials: 'omit'`) and the HTTP `cache` mode configuration (such as `cache: 'no-store'`). These are reverted back to standard browser-default parameters (`credentials: 'same-origin'` and default HTTP cache properties). This causes the browser to include active credentials (such as cookies or Authorization headers) on outbound requests where the client-side developer explicitly instructed they should be omitted, leading to potential session leaks. Additionally, it causes private or non-cacheable resources to be cached by the service worker's engine, making private page states accessible or persistent inside the client's local cache post-logout. ### Impact Web applications registering the `@angular/service-worker` package are vulnerable to credential exposure or post-logout cache persistence if client-side code relies on fetch calls with explicit safety attributes (such as `{ credentials: 'omit' }` or `{ cache: 'no-store' }`) targeting paths matched by service worker asset groups. By stripping these safety boundaries, the service worker exposes same-origin cookies and dynamic sensitive data to endpoints that should not receive them, or retains dynamic user sessions in cache storage where logout operations fail to fully evict user records. ### Attack Preconditions To successfully exploit this vulnerability, all of the following application states and parameters must concurrently exist: 1. **Active Angular Service Worker:** The target application uses `@angular/service-worker` and has an active registration of `ngsw-worker.js` inside the client's browser context. 2. **Asset Group Matching:** An `assetGroups` pattern in `ngsw-config.json` encompasses the target dynamic routing endpoint. 3. **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. 4. **Client-Side Safe Fetch Call:** The application initiates an explicit fetch request to the route with safety parameters: `{ credentials: 'omit' }` or specific cache control parameters (e.g. `{ cache: 'no-store' }`). ### Mitigations & Workarounds If upgrading the `@angular/service-worker` package is not immediately feasible, developers should implement the following defensive measures: * **Strict Cookie Configuration:** Apply strict flags to session cookies (`SameSite=Strict; Secure; HttpOnly`) and ensure complete route isolation for credential-guarded secure resources. * **Exclude Secure Endpoints from SW Config:** Ensure that patterns targeting dynamic, secure endpoints are explicitly excluded from automatic asset groups or caching scopes in your `ngsw-config.json`. * **Post-Logout Cache Invalidation:** Programmatically purge the browser's Cache Storage API entries registered by the Angular Service Worker upon user logout: ```javascript if ('caches' in window) { caches.keys().then(names => { for (let name of names) { if (name.startsWith('ngsw:')) { caches.delete(name); } } }); } ``` ### Patches - 22.0.0-rc.2 - 21.2.15 - 20.3.22 - 19.2.23 | ||
| Risiko 7.5 / 10 CVE-2026-50171 | vor 1 Stunde(n) | |
| A Denial of Service (DoS) vulnerability exists in the `@angular/common` package of Angular. The `formatNumber` function, which is also utilized by `DecimalPipe`, `PercentPipe`, and `CurrencyPipe`, does not properly validate the upper bounds of the `digitsInfo` parameter. Specifically, the minimum and maximum fraction digits parsed from the `digitsInfo` string (e.g., `1.2-4`) are converted to integers and used without limits. When parsing a maliciously crafted `digitsInfo` string with excessively large fraction digit values (e.g., `1.200000000-200000000`), the internal `roundNumber` function attempts to pad the digits array to match the requested fraction size. This results in an unbounded loop that repeatedly pushes elements into an array. ### Impact Successful exploitation of this vulnerability allows an attacker to trigger resource exhaustion, leading to a Denial of Service (DoS): * **Server-Side Rendering (SSR):** In applications using SSR (e.g., `@angular/ssr`), an attacker can crash the Node.js server process due to a `JavaScript heap out of memory` error. This affects the availability of the application for all users. * **Client-Side Rendering (CSR):** In standard client-side applications, the unbounded loop will block the main thread, freezing the user's browser tab and making it unresponsive. ### Attack Preconditions For this vulnerability to be exploitable, the following conditions must be met: 1. **Vulnerable Component Usage:** The application must use Angular's number formatting utilities, such as the `formatNumber` function directly, or via template pipes (`DecimalPipe`, `PercentPipe`, `CurrencyPipe`). 2. **Attacker-Controlled Parameter:** The `digitsInfo` parameter passed to these utilities must be customizable or directly controlled by untrusted user input (e.g., parsed from query parameters, user preference settings, or API responses that accept user-defined formatting options). If `digitsInfo` is trusted or limited to a known, defined range for its value, the vulnerability is not exploitable by external attackers. ### Patches - 22.0.0-rc.2 - 21.2.15 - 20.3.22 - 19.2.23 ### Credits This vulnerability was discovered and reported by [CodeMender from Google DeepMind](https://deepmind.google/blog/introducing-codemender-an-ai-agent-for-code-security/). | ||
| Risiko 7.5 / 10 CVE-2026-50170 | vor 1 Stunde(n) | |
| 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 | ||
| Risiko 5 / 10 CVE-2026-52725 | vor 1 Stunde(n) | |
| An issue in the `@angular/core` package allows bypassing script-execution restrictions during dynamic component creation. Specifically, the dynamic component instantiation mechanism (`createComponent`) failed to reject mounting components directly onto a ` | ||