Infinite-loop denial of service in Angular Server-Side Rendering

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.31, 21.2.23, and 22.1.6, the @angular/platform-server DOM emulation parser can enter an infinite synchronous loop when Angular server-side rendering processes attacker-controlled HTML containing an incomplete DOCTYPE that ends with whitespace at end of input. In Domino lib/HTMLParser.js, after_doctype_name_state emits doctype and EOF tokens without advancing nextchar or leaving the fixed-lookahead state, so the scanner repeatedly handles the same EOF marker. A remote unauthenticated attacker can use this condition through server-side HTML parsing paths such as innerHTML binding to consume a Node.js SSR worker at full CPU, starve the event loop, and stop concurrent and subsequent requests. This issue is fixed in versions 20.3.31, 21.2.23, and 22.1.6.

• @angular/platform-server and the corresponding Angular product record are affected in these ranges:
• <= 19.2.25.
• >= 20.0.0, < 20.3.31.
• >= 21.0.0, < 21.2.23.
• >= 22.0.0, < 22.1.6.
• The advisory marks the <= 19.2.25 line as end of support or expired LTS and states that it will not be patched on that line.
• Confirmed patched releases by branch are 20.3.31, 21.2.23, and 22.1.6. The status of other parallel or later branches should not be inferred without separate verification.

Angular Server-Side Rendering uses the Domino DOM emulation parser inside @angular/platform-server to process untrusted HTML, including data that reaches server-side bindings such as [innerHTML] or server-side DOM operations. When input contains an incomplete DOCTYPE ending in whitespace at EOF, after_doctype_name_state in lib/HTMLParser.js emits doctype and EOF tokens without advancing nextchar or leaving the fixed-lookahead state. The scanner therefore repeatedly processes the same EOF marker and cannot terminate the synchronous loop. Because Node.js executes synchronous JavaScript on the event loop, the loop can consume the SSR worker's CPU and block other requests. Actual exposure depends on whether the application routes attacker-controlled data into a server-side HTML parsing path; the available evidence does not establish that every Angular SSR deployment is reachable in the same way. The issue maps to CWE-400 and CWE-835.

The issue is network-reachable when an Angular SSR application parses attacker-controlled HTML, such as data passed through an [innerHTML] binding or another server-side markup-generation path. The record and advisory describe remote exploitation without authentication, without user interaction, and with low complexity. An incomplete DOCTYPE ending in whitespace can lock an SSR worker in a synchronous loop, preventing that worker from processing concurrent and subsequent requests. The record marks public exploit as available, and the advisory includes a proof of concept, but the supplied evidence does not name a campaign, victim, or observed exploitation activity. The service-level effect depends on the deployment's worker, process, and redundancy topology.

• The primary technical result is an unterminated synchronous loop in the Domino parser, causing uncontrolled CPU consumption and loss of SSR worker availability.
• An affected worker may be unable to process concurrent or subsequent requests because its event loop is occupied.
• The available evidence does not describe privilege escalation, data disclosure, or data modification; the confirmed impact is concentrated on availability of the affected system.
• Service-level disruption depends on worker count, process isolation, failover behavior, and whether requests can be routed to unaffected replicas. Multiple replicas may limit the blast radius, but they do not remove exposure from workers that still run an affected release.

• A locked SSR worker can stop serving concurrent and subsequent requests, reducing capacity or causing service disruption.
• If requests can reach multiple affected workers, the condition can become a broader SSR degradation or outage, depending on replica count, load balancing, and restart behavior.
• Because the issue is described as resource consumption and is not described as enabling data access or modification, the available evidence does not establish a direct confidentiality or integrity impact.
• Operations teams should prioritize the dependency update, identify paths that accept untrusted HTML, and verify worker behavior after deployment.

1. Upgrade the active branch: update @angular/platform-server to the matching confirmed patched release, 20.3.31, 21.2.23, or 22.1.6. Verify both the manifest and lockfile so the deployed dependency actually changes.
2. For the <= 19.2.25 line, do not wait for a patch to the end-of-support or expired-LTS branch. Move to a supported branch with a confirmed fix, and test application compatibility before release.
3. Reduce exposure during the transition: avoid passing untrusted data directly to [innerHTML] in server-rendered templates. When raw HTML is not required, use text interpolation or [textContent].
4. If untrusted HTML must be rendered, validate or sanitize it before it reaches the server-side [innerHTML] path. The advisory identifies removing or rejecting strings matching ^<!DOCTYPE/i as a temporary workaround.
5. After updating, run staging regression tests for HTML parsing paths, monitor SSR worker CPU and event-loop lag, and then expand deployment. Workarounds do not replace the upgrade.

• Inventory direct and lockfile dependencies to determine whether the application uses @angular/platform-server, then compare the deployed branch and version with the affected ranges.
• Identify deployments with Angular SSR enabled and review data flows from requests, user content, or stored content into [innerHTML], server-generated markup, sanitization code, or DOM APIs.
• In a controlled staging environment, run the advisory's regression case for an incomplete DOCTYPE ending in whitespace and confirm that parsing terminates without hanging the worker. Do not perform this test in production.
• Monitor for CPU saturation, event-loop lag, unresponsive SSR workers, or request timeouts that coincide with HTML parsing activity. Treat this as precautionary telemetry, not as a confirmed IOC.
• The available evidence does not define a specific production IOC. Absence of unusual log evidence does not prove that a deployment is unaffected.