Skip to content

← Public intelligence

npm package

@angular/common

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 5.9npmAmendedPublished

    @angular/common: XSRF Token Leakage via URL Parsing Discrepancy in Angular HTTP Client (Incomplete fix for CVE-2025-66035)

    CVE-2026-111753 · GHSA-jfgx-762w-99vr

    Affected
    • npm @angular/common >= 21.0.0, < 21.0.3; >= 20.0.0, < 20.3.34; <= 19.2.25
    Fixed in
    20.3.3421.0.3· Partial vendor fix
    Issue
    An incomplete fix for GHSA-58c5-g7wp-6w37 (CVE-2025-66035) in @angular/common's HTTP Client (HttpClient) allows Cross-Site Request Forgery (XSRF) tokens to be leaked to attacker-controlled cross-origin domains when requests use URLs that exploit parsing discrepancies between regular expressions and the browser's WHATWG URL parser. Technical Description To address CVE-2025-66035, xsrfInterceptorFn introduced a regular expression (const ABSOLUTEURLREGEX = /^(?:https?:)?\/\//i) to detect and skip absolute and protocol-relative URLs before attaching the X-XSRF-TOKEN header. However, browsers resolve request URLs passed to fetch() and XMLHttpRequest.open() using the WHATWG URL parser. For http: and https: schemes, the WHATWG URL standard performs several normalizations prior to resolving the authority/origin: Backslashes (\) are treated as forward slashes (/) — e.g., /\evil.example/x, \\evil.example/x, \/evil.example/x, https:\\evil.example/x, https:/\evil.example/x. Leading and trailing…

    Recommended action: Upgrade to 21.0.3 or 20.3.34 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  2. Medium, CVSS 4.0npmAmendedPublished

    Angular: Information Leak via HttpTransferCache Bypass When Using withRequestsMadeViaParent

    CVE-2026-88059 · GHSA-p297-fm68-3q8c

    Affected
    • npm @angular/common >= 22.0.0, < 22.1.1; >= 21.0.0, < 21.2.20; >= 20.0.0, < 20.3.28; <= 19.2.25
    Fixed in
    22.1.120.3.2821.2.20· Partial vendor fix
    Issue
    A security bypass vulnerability was discovered in @angular/common when Server-Side Rendering (SSR) and hydration are enabled in applications using a hierarchical HttpClient configuration with withRequestsMadeViaParent(). 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 (serialized as JSON in <script id="ng-state"). Following the remediation of CVE-2026-50170, HttpTransferCache automatically skips caching requests that contain authentication headers or credentials (Authorization, Cookie, withCredentials, etc.). However, when a child HttpClient delegates to a parent client via withRequestsMadeViaParent(), the child's TransferCache interceptor evaluates whether the request is eligible for caching before delegating to the parent client's interceptor chain. If an outgoing request originates as anonymous from the child client, the child TransferCache…

    Recommended action: Upgrade to 22.1.1, 21.2.20 or 20.3.28 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  3. High, CVSS 8.8npmPublished

    Angular: Cache-Key Ambiguity in HttpTransferCache Leading to Cross-Request Response Reuse and State Poisoning

    CVE-2026-68945 · GHSA-jhpw-976m-542j

    Affected
    • npm @angular/common >= 22.0.0-next.0, < 22.0.2; >= 21.0.0-next.0, < 21.2.19; >= 20.0.0-next.0, < 20.3.27; <= 19.2.25
    Fixed in
    22.0.221.2.1920.3.27· Partial vendor fix
    Issue
    Angular's HttpTransferCache caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration. During SSR, HttpTransferCache previously generated identical key material for distinct request parameters when repeated values were present because repeated values were joined with commas: Both requests previously serialized as role=user,admin, allowing distinct HttpClient requests to produce the same transfer-cache key material. Impact In an SSR application, this cache-key ambiguity can make a later security-sensitive HttpClient request receive the response from an earlier semantically different request in the same render. For example, an attacker-influenced scalar-comma request can be cached and then replayed as the response for a trusted repeated-param authorization or data request to the same URL. As a result, Angular's server-rendered output can be based on the wrong backend response because the trusted request is not dispatched. This…

    Recommended action: Upgrade to 22.0.2, 21.2.19 or 20.3.27 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  4. High, CVSS 8.2npmAmendedPublished

    @angular/common: Denial of Service (DoS) via OOM in Date Formatting (formatDate)

    CVE-2026-54268 · GHSA-48r7-hpm6-gfxm

    Affected
    • npm @angular/common >= 22.0.0-next.0, < 22.0.1; >= 21.0.0-next.0, < 21.2.17; >= 20.0.0-next.0, < 20.3.25; <= 19.2.25
    Fixed in
    20.3.2522.0.121.2.17· Partial vendor fix
    Issue
    A Denial of Service (DoS) vulnerability exists in the @angular/common package of the Angular framework. The formatDate function, which is also utilized by the standard Angular DatePipe, does not properly limit or validate the length of the format parameter. When parsing a maliciously crafted, excessively long date format string (e.g., a repeating pattern or very large string), the internal parser splits the string iteratively using a regular expression loop. This results in uncontrolled resource consumption (high CPU utilization and excessive memory allocations), leading to a Denial of Service (DoS). Impact 1. Server-Side Rendering (SSR) In Angular applications that leverage Server-Side Rendering, an attacker can supply a malicious payload with an excessively long date format string. Processing this on the server causes high CPU usage and triggers a JavaScript heap out of memory crash, rendering the application unavailable to all users. 2. Client-Side Rendering (CSR) In standard…

    Recommended action: Upgrade to 22.0.1, 21.2.17 or 20.3.25 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  5. High, CVSS 8.8npmAmendedPublished

    @angular/common: Weak 32-Bit Cache Key Hashing in HttpTransferCache Leading to Cross-Request Data Leakage and State Poisoning

    CVE-2026-54266 · GHSA-39pv-4j6c-2g6v

    Affected
    • npm @angular/common >= 22.0.0-next.0, < 22.0.1; >= 21.0.0-next.0, < 21.2.17; >= 20.0.0-next.0, < 20.3.25; <= 19.2.25
    Fixed in
    20.3.2522.0.121.2.17· Partial vendor fix
    Issue
    Angular's HttpTransferCache caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration. This avoids repeating the same HTTP requests on the client. The cached responses are stored in TransferState using a cache key generated by hashing request properties (method, response type, mapped URL, serialized body, and sorted query parameters). The cache keys are generated using a weak 32-bit DJB2-like polynomial rolling hash. The 32-bit hash space is extremely small, allowing attackers to find hash collisions. An attacker can easily find a query parameter string (e.g., q=aaCAZMMM for a search request) that produces the exact same 32-bit hash as a sensitive endpoint (e.g., /api/user/profile). When a victim visits a crafted link containing the colliding parameter, the SSR process executes both the search request and the profile request. Due to the hash collision, the search response overwrites the profile response in the TransferState…

    Recommended action: Upgrade to 22.0.1, 21.2.17 or 20.3.25 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  6. High, CVSS 8.2npmAmendedPublished

    @angular/common: Denial of Service (DoS) via OOM in Number Formatting (digitsInfo)

    CVE-2026-50171 · GHSA-p3vc-36g9-x9gr

    Affected
    • npm @angular/common >= 22.0.0-next.0, < 22.0.0-rc.2; >= 20.0.0-next.0, < 20.3.22; >= 19.0.0-next.0, < 19.2.23; <= 18.2.14; >= 21.0.0-next.0, < 21.2.15
    Fixed in
    22.0.0-rc.219.2.2320.3.2221.2.15· Partial vendor fix
    Issue
    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…

    Recommended action: Upgrade to 22.0.0-rc.2 (pre-release), 21.2.15, 20.3.22 or 19.2.23 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  7. High, CVSS 8.2npmAmendedPublished

    @angular/common: Information Leak via Default Caching of Credentialed Requests in HttpTransferCache

    CVE-2026-50170 · GHSA-q6f4-qqrg-jv6x

    Affected
    • npm @angular/common >= 22.0.0-next.0, < 22.0.0-rc.2; >= 20.0.0-next.0, < 20.3.22; >= 19.0.0-next.0, < 19.2.23; <= 18.2.14; >= 21.0.0-next.0, < 21.2.15
    Fixed in
    22.0.0-rc.219.2.2320.3.2221.2.15· Partial vendor fix
    Issue
    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…

    Recommended action: Upgrade to 22.0.0-rc.2 (pre-release), 21.2.15, 20.3.22 or 19.2.23 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  8. High, CVSS 7.7npmAmendedPublished

    Angular is Vulnerable to XSRF Token Leakage via Protocol-Relative URLs in Angular HTTP Client

    CVE-2025-66035 · GHSA-58c5-g7wp-6w37

    Affected
    • npm @angular/common >= 21.0.0-next.0, < 21.0.1; >= 20.0.0-next.0, < 20.3.14; < 19.2.16
    Fixed in
    21.0.120.3.1419.2.16· Vendor fix available
    Issue
    The vulnerability is a Credential Leak by App Logic that leads to the unauthorized disclosure of the Cross-Site Request Forgery (XSRF) token to an attacker-controlled domain. Angular's HttpClient has a built-in XSRF protection mechanism that works by checking if a request URL starts with a protocol (http:// or https://) to determine if it is cross-origin. If the URL starts with protocol-relative URL (//), it is incorrectly treated as a same-origin request, and the XSRF token is automatically added to the X-XSRF-TOKEN header. Impact The token leakage completely bypasses Angular's built-in CSRF protection, allowing an attacker to capture the user's valid XSRF token. Once the token is obtained, the attacker can perform arbitrary Cross-Site Request Forgery (CSRF) attacks against the victim user's session. Attack Preconditions 1. The victim's Angular application must have XSRF protection enabled. 2. The attacker must be able to make the application send a state-changing HTTP request…

    Recommended action: Upgrade to 21.0.1, 20.3.14 or 19.2.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →