GHSA-rgjc-h3x7-9mwg

To optimize client-side bootstrap in Server-Side Rendered (SSR) environments, Angular supports **Hydration** via `provideClientHydration()`. During SSR, Angular serializes the application's runtime state (such as cached `HttpClient` responses) and outputs it into the HTML stream as a `<script>` tag with a predictable identifier:

```html <script type="application/json" id="ng-state"> {"some-api-url": {"body": ...}} </script> ````

During client bootstrap, Angular recovers this state by looking up the element via `document.getElementById('ng-state')` and parsing its text content.

Because the DOM element lookup for the state container is predictable and relies solely on the ID selector (`ng-state`), it is susceptible to **DOM Clobbering**.

If the application binds untrusted user input or CMS content to element properties such as `id` (e.g., `<div [id]="userInput">` or `<a id="ng-state">`) *before* the genuine `<script>` tag is parsed by the browser, the attacker-controlled element takes precedence in the DOM lookup.

During hydration, when Angular calls `document.getElementById('ng-state')`, the browser returns the attacker's clobbered element. Angular then attempts to parse the text content or attributes of this clobbered element as JSON.

### Impact

By clobbering the state element, the attacker can inject a custom JSON payload into Angular's `TransferState` cache. The most critical exploitation vector is poisoning the **HTTP Transfer Cache**.

1. The attacker injects a clobbered `ng-state` element containing custom JSON. 2. The JSON maps a key (representing a target API endpoint URL) to a malicious payload of the attacker's choice. 3. During client-side initialization, Angular's `HttpClient` checks `TransferState` before making requests. Finding the poisoned key, `HttpClient` returns the forged response instantly instead of requesting the genuine backend API.

Depending on how the application processes and renders the affected API response, this can lead to:

* **DOM-based Cross-Site Scripting (XSS)** if poisoned fields are rendered using unsafe bindings. * **Privilege Escalation** by spoofing user info or session details retrieved from poisoned API payloads. * **UI Hijacking** and redirection by spoofing configuration endpoints.

### Patched Versions

* 22.0.1 * 21.2.17 * 20.3.25

### Workarounds

If you cannot immediately update to a patched Angular version, apply the following workarounds:

#### A. Avoid Dynamic/User-Controlled IDs

Avoid binding raw user-supplied values or dynamic CMS IDs directly to element attributes. If dynamic IDs are required, sanitize them or prepend a static safe prefix:

```html <!-- Vulnerable Pattern --> <div [id]="userControlledInput">...</div>

<!-- Mitigated Pattern --> <div [id]="'safe-prefix-' + userControlledInput">...</div> ```

#### B. Configure a Custom Application ID

Declaring a unique, non-predictable `APP_ID` changes the ID suffix of the state element, making it harder for attackers to predict and target:

```ts // app.config.ts

import { APP_ID } from '@angular/core'; import { provideClientHydration } from '@angular/platform-browser';

export const appConfig = { providers: [ { provide: APP_ID, useValue: 'unique-obfuscated-app-id' }, provideClientHydration() ] };

```

This changes the state element lookup ID from `ng-state` to `unique-obfuscated-app-id-state`.