Skip to content

fix(deps): update dependency @angular/common to v20 [security] - #800

Open
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/npm-angular-common-vulnerability
Open

fix(deps): update dependency @angular/common to v20 [security]#800
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/npm-angular-common-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Nov 27, 2025

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
@angular/common (source) ~18.2.0~20.0.0 age confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.


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

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

More information

Details

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 (e.g., POST) to a protocol-relative URL (e.g., //attacker.com) that they control.
Patches
  • 19.2.16
  • 20.3.14
  • 21.0.1
Workarounds

Developers should avoid using protocol-relative URLs (URLs starting with //) in HttpClient requests. All backend communication URLs should be hardcoded as relative paths (starting with a single /) or fully qualified, trusted absolute URLs.

Severity

  • CVSS Score: 7.7 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


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

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

More information

Details

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.

Severity

  • CVSS Score: 8.2 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


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

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

More information

Details

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

Severity

  • CVSS Score: 8.2 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


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

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

More information

Details

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 (e.g., POST) to a protocol-relative URL (e.g., //attacker.com) that they control.
Patches
  • 19.2.16
  • 20.3.14
  • 21.0.1
Workarounds

Developers should avoid using protocol-relative URLs (URLs starting with //) in HttpClient requests. All backend communication URLs should be hardcoded as relative paths (starting with a single /) or fully qualified, trusted absolute URLs.

Severity

  • CVSS Score: 7.7 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


@​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

More information

Details

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 cache.

Impact

When the application attempts to retrieve the cached response for the sensitive endpoint (such as the user's profile), it receives the attacker-controlled response instead. This results in:

  • State Poisoning: The application runs with attacker-forged data, which can lead to bypassing client-side security controls or DOM-based Cross-Site Scripting (XSS) if the data is rendered unsafely.
  • Information Leakage: If the sensitive response is mistakenly associated with the attacker's search results and rendered on the page, the victim's sensitive data may be disclosed to the attacker.
Patched Versions
  • 22.0.1
  • 21.2.17
  • 20.3.25
Framework-Level Fix

The logic has been updated to use a cryptographically secure SHA-256 hash algorithm for generating TransferState cache keys in HttpTransferCache. The cache keys are now 256-bit hexadecimal strings.

Workarounds

If you cannot upgrade immediately, configure your HttpClient requests to skip transfer caching for sensitive endpoints:

this.http.get('/api/user/profile', {
  transferCache: false
});

Alternatively, disable the HTTP transfer cache globally in your application bootstrap config:

import { provideClientHydration, withNoHttpTransferCache } from '@angular/platform-browser';

export const appConfig = {
  providers: [
    provideClientHydration(
      withNoHttpTransferCache()
    )
  ]
};
Credits

This vulnerability was discovered and reported by CodeMender from Google DeepMind.

Severity

  • CVSS Score: 8.8 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


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

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

More information

Details

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 client-side applications, executing the vulnerable function with an excessively long format string blocks the browser's main thread, causing the browser tab to freeze and become completely unresponsive.

Patched Versions
  • 22.0.1
  • 21.2.17
  • 20.3.25
Attack Preconditions

For this vulnerability to be exploitable, both of the following conditions must be met:

  1. Vulnerable Component Usage: The application must format dates using the formatDate utility or the DatePipe.
  2. Attacker-Controlled Parameter: The date format string passed to these utilities must be customizable or directly controlled by untrusted user input (e.g., parsed from query parameters, user preferences, or API responses).

If the date format is hardcoded (e.g., 'mediumDate', 'shortTime', or static strings) or properly validated to be within a reasonable length limit, the application is not vulnerable.

Severity

  • CVSS Score: 8.2 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


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

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

More information

Details

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:

new HttpParams().set('role', 'user,admin')
new HttpParams().append('role', 'user').append('role', 'admin')

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 can lead to:

  • State Poisoning: Using incorrect or attacker-influenced cached responses for subsequent application logic.
  • Cross-Request Response Reuse: Reusing cached responses across requests with semantically different parameters.
Patched Versions
  • 22.0.2
  • 21.2.19
  • 20.3.27
Workarounds

If you cannot upgrade immediately, configure your HttpClient requests to skip transfer caching for sensitive endpoints where repeated parameter keys are used:

this.http.get('/api/resource', {
  transferCache: false
});

Alternatively, disable the HTTP transfer cache globally in your application bootstrap config:

import { provideClientHydration, withNoHttpTransferCache } from '@angular/platform-browser';

export const appConfig = {
  providers: [
    provideClientHydration(
      withNoHttpTransferCache()
    )
  ]
};

Severity

  • CVSS Score: 8.8 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Angular: Information Leak via HttpTransferCache Bypass When Using withRequestsMadeViaParent

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

More information

Details

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 marks the request as cacheable. When the request reaches a parent interceptor that injects sensitive authentication credentials (such as an Authorization header or API token), the parent TransferCache correctly skips caching the authenticated request. However, when the backend returns the private, authenticated response, the child TransferCache still stores the response in TransferState based on its initial pre-delegation evaluation.

Impact

Successful exploitation allows sensitive, user-specific information belonging to an authenticated user to be leaked to unauthenticated or unauthorized users. This occurs when:

  1. During SSR, a child HttpClient initiates an unauthenticated request that is subsequently authenticated by a parent interceptor.
  2. The authenticated response body is cached into the SSR-rendered HTML page (TransferState).
  3. The rendered HTML page is stored by a shared caching layer (e.g., CDN, edge cache, or reverse proxy) or served across user sessions.
  4. Subsequent visitors requesting the same page receive the cached HTML containing the previous user's private data.
Attack Preconditions & Vulnerable Configurations

An application is affected only if all of the following conditions are met:

  • SSR and Hydration Enabled: The application uses Server-Side Rendering with hydration enabled (e.g., via provideClientHydration()).
  • Hierarchical HttpClient with Delegation: The application configures a child HttpClient using withRequestsMadeViaParent().
  • Parent-Level Authentication Injection: Authentication credentials (such as Authorization headers, session cookies, or custom API tokens filtered via withHttpTransferCacheOptions) are attached by an interceptor in the parent injector chain rather than on the initial child request.
  • Shared HTML Caching: The SSR HTML responses are cached by a shared caching layer (CDN, reverse proxy, or application-level HTML cache).
Vulnerable Code Pattern Example
// Parent Injector / Application Config
export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(
      // Parent interceptor attaches sensitive Authorization header
      withInterceptors([
        (req, next) => next(req.clone({ setHeaders: { Authorization: `Bearer ${getToken()}` } }))
      ])
    ),
  ],
};

// Child Injector / Feature or Component Config
const childClient = createEnvironmentInjector(
  [
    // Child delegates to parent; TransferCache evaluates req BEFORE parent auth interceptor runs
    provideHttpClient(withRequestsMadeViaParent()),
  ],
  parentInjector
).get(HttpClient);

// Request originates without auth headers -> marked cacheable by child TransferCache
childClient.get('/api/user/profile').subscribe();
Patches

The issue is resolved by updating @angular/common to run root interceptors in the terminal request chain so that delegated clients leave inherited root interceptors to the parent chain, preventing duplicate execution and ensuring HttpTransferCache evaluates cache eligibility after parent request interceptors run.

  • 22.1.1
  • 21.2.20
  • 20.3.28
Workarounds & Mitigations

For applications that cannot immediately upgrade to a patched version, use one of the following mitigations:

  1. Attach Credentials Before or Within the Child Client: Ensure authentication headers (e.g., Authorization) are attached directly when constructing the request or via an interceptor configured directly on the child HttpClient, rather than relying solely on parent interceptors.
  2. Apply Explicit Cache Filters on the Child Client: Configure withHttpTransferCacheOptions with a filter on the child client that explicitly excludes endpoints returning user-specific or sensitive data:
    provideClientHydration(
      withHttpTransferCacheOptions({
        filter: (req) => !req.url.includes('/api/private/'),
      })
    )
  3. Disable HTTP Transfer Cache for Sensitive Routes: If specific SSR routes handle user-authenticated data, disable transfer caching for those requests or ensure the SSR response sets Cache-Control: no-store / private headers at your edge/CDN layer so personalized HTML is never shared.

Severity

  • CVSS Score: 4.0 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Release Notes

angular/angular (@​angular/common)

v20.0.0

Compare Source

Blog post: https://blog.angular.dev/announcing-angular-v20-b5c9c06cf301

Breaking Changes

common
  • Using the Y formatter (week-numbering year) without also including w (week number) is now detected as suspicious date pattern, as y is typically intended.
  • AsyncPipe now directly catches unhandled errors in
    subscriptions and promises and reports them to the application's
    ErrorHandler. For Zone-based applications, these errors would have
    been caught by ZoneJS and reported to ErrorHandler so the result is
    generally the same. The change to the exact mechanism for reporting can
    result in differences in test environments that will require test
    updates.
compiler
  • 'in' in an expression now refers to the operator

  • void in an expression now refers to the operator

    Previously an expression in the template like {{void}} referred to a
    property on the component class. After this change it now refers to the
    void operator, which would make the above example invalid. If you have
    existing expressions that need to refer to a property named void,
    change the expression to use this.void instead: {{this.void}}.

  • Parenthesis are always respected.

    This can lead to runtime breakages when a nullish coalescing operator is nested within parentheses.
    eg. {{ (foo?.bar).baz }} will throw if foo is nullish. This is the same behavior as native JavaScript.

core
  • TypeScript versions less than 5.8 are no longer supported.

  • the TestBed.flushEffects() was removed - use
    the TestBed.tick() instead.

  • provideExperimentalCheckNoChangesForDebug has several
    breaking changes:

    • It is renamed to provideCheckNoChangesConfig
    • The behavior applies to all checkNoChanges runs
    • The useNgZoneOnStable option is removed. This wasn't found to be generally
      more useful than interval
  • provideExperimentalZonelessChangeDetection is
    renamed to provideZonelessChangeDetection as it is now "Developer
    Preview" rather than "Experimental".

    • InjectFlags has been removed.
    • inject no longer accepts InjectFlags.
    • Injector.get no longer accepts InjectFlags.
    • EnvironmentInjector.get no longer accepts InjectFlags.
    • TestBed.get no longer accepts InjectFlags.
    • TestBed.inject no longer accepts InjectFlags.
    • TestBed.get has been removed. Use TestBed.inject instead.
  • afterRender was renamed to afterEveryRender.

    • Angular no longer supports Node.js v18.
    • Node.js versions 22.0 to 22.10 are also no longer supported.

    Before upgrading to Angular v20, ensure the Node.js version is at least 20.11.1.
    For the full list of supported versions, visit: https://angular.dev/reference/versions

  • PendingTasks.run no longer returns the result of the
    async function. If this behavior is desired, it can be re-implemented
    manually with the PendingTasks.add. Be aware, however, that promise rejections
    will need to be handled or they can cause the node process to shut down
    when using SSR.

  • Uncaught errors in listeners which were previously only reported to
    ErrorHandler are now also reported to Angular's internal error
    handling machinery. For tests, this means that the error will be
    rethrown by default rather than only logging the error. Developers
    should fix these errors, catch them in the test if the test is
    intentionally covering an error case, or use rethrowApplicationErrors: false in configureTestingModule as a last resort.

  • The any overload has been removed from
    injector.get. It now only supports ProviderToken<T> and (deprecated
    since v4) string.

  • Animations are guaranteed to be flushed when Angular
    runs automatic change detection or manual calls to ApplicationRef.tick.
    Prior to this change, animations would not be flushed in some situations
    if change detection did not run on any views attached to the
    application. This change can affect tests which may rely on the old
    behavior, often by making assertions on DOM elements that should have
    been removed but weren't because DOM removal is delayed until animations
    are flushed.

  • ApplicationRef.tick will no longer catch and report
    errors to the application ErrorHandler. Errors will instead be thrown out of
    the method and will allow callers to determine how to handle these
    errors, such as aborting follow-up work or reporting the error and
    continuing.

  • This commit deprecates ng-reflect-* attributes and updates the runtime to stop producing them by default. Please refactor application and test code to avoid relying on ng-reflect-* attributes.

    To enable a more seamless upgrade to v20, we've added the provideNgReflectAttributes() function (can be imported from the @angular/core package), which enables the mode in which Angular would be producing those attribites (in dev mode only). You can add the provideNgReflectAttributes() function to the list of providers within the bootstrap call.

router
  • The RedirectFn can now return Observable or
    Promise. Any code that directly calls functions returning this type
    may need to be adjusted to account for this.
  • Several methods in the public API of the Router which
    required writable arrays have now been updated to accept readonly
    arrays when no mutations are done.
  • The guards arrays on Route no longer include any in
    the type union. The union includes functions for the functional guards
    as well as a type matching Injector.get: ProviderToken<T>|string.
    Note that string is still deprecated on both the route guards and
    Injector.get.

Deprecations

core
  • ngIf/ngFor/ngSwitch are deprecated. Use the control flow blocks instead (@for/@if/@switch).
platform-browser
  • All entries of the @angular/platform-browser-dynamic
  • HammerJS support is deprecated and will be removed in a future major version.
platform-server
  • @angular/platform-server/testing

    Use e2e tests to verify SSR behavior instead.

common
Commit Type Description
2e5362a469 feat accept undefined inputs in NgTemplateOutlet (#​61404)
b7d3f3dbfc feat Allow passing ScrollOptions to ViewportScroller (#​61002)
74cceba587 feat throw error for suspicious date patterns (#​59798)
255c79e048 fix cleanup updateLatestValue if view is destroyed before promise resolves (#​58041)
739cadae62 fix Handle errors in async pipe subscriptions (#​60057)
cbbea70fa3 fix issue a warning instead of an error when NgOptimizedImage exceeds the preload limit (#​60879)
fc4a56d5c5 fix rename httpResource function in factory (#​60022)
785a1110e6 fix resolve host binding type issues (#​60481)
compiler
Commit Type Description
7a971766dc feat add extended diagnostic for uninvoked track function on @for blocks (#​60495)
f2d5cf7edd feat support exponentiation operator in templates (#​59894)
51b8ff23ce feat support tagged template literals in expressions (#​59947)
1b8e7ab9fe feat support the in keyword in Binary expression (#​58432)
0361c2d81f feat support void operator in templates (#​59894)
8b990a31c3 fix error if rawText isn't estimated correctly (#​60529)
4fe489f1b4 fix exponentiation should be right-to-left associative (#​60101)
ef1fd137a9 fix incorrect spans for template literals (#​60323)
e0d378d20e fix incorrectly handling let declarations inside i18n (#​60512)
b70ad3c4e6 fix proper handling of typeof, void in RecursiveAstVisitor (#​60101)
e25e6c95a2 fix remove TypeScript from linker (#​61635)
768239a89c perf reduce allocations for let declarations only used in the same view (#​60512)
compiler-cli
Commit Type Description
bec1610da2 feat add extended diagnostic for invalid nullish coalescing (#​60279)
c889382a20 feat detect missing structural directive imports (#​59443)
1971e57a45 feat support type checking of host bindings (#​60267)
9ec9c7e1b8 fix avoid fatal diagnostics for invalid module schemas (#​61220)
a1cacc5b17 fix avoid fatal diagnostics for missing template files (#​58673)
1e6faad479 fix correctly parse event name in HostListener (#​60561)
ffb19e64f1 fix preserve required parens for nullish coalescing (#​60060)
7c9b4892e9 fix preserve required parens in exponentiation expressions (#​60101)
7e03af898e fix set correct target when type checking events (#​60561)
2d51a203dc fix wrong event name for host listener decorators (#​60460)
core
Commit Type Description
22d3f0562c feat add hook for producer creation side effects (#​60333)
fe57332fc5 feat add input binding support to dynamically-created components (#​60137)
65adb3024d feat Add provider which reports unhandled errors on window to ErrorHandler (#​60704)
b154fb3911 feat add support for two-way bindings on dynamically-created components (#​60342)
82aa2c1a52 feat add the ability to apply directives to dynamically-created components (#​60137)
326d48afb4 feat drop support for TypeScript older than 5.8 (#​60197)
d260ca3091 feat emit template function for template related profiler hooks (#​60174)
a4bad8d361 feat export signalGetFn from signal primitives (#​60497)
4812215a7b feat Expose Injector.destroy on Injector created with Injector.create (#​60054)
c1bcae91dd feat expose performance data in Chrome DevTools (#​60789)
809b5b4596 feat introduce new DI profiling event (#​60158)
d5fd7349fb feat introduce TestBed.tick() (#​60993)
4e88e18a8e feat mark toObservable as stable (#​60449)
727cda3856 feat mark linkedSignal API as public (#​60865)
644d9f3bbd feat mark the toSignal API as stable (#​60442)
e711f99d81 feat move provideExperimentalCheckNoChangesForDebug to provideCheckNoChangesConfig (#​60906)
7ccec1494f feat move DOCUMENT token into core (#​60663)
953c4b2580 feat Move zoneless change detection to dev preview (#​60748)
611baaf069 feat remove InjectFlags from public API (#​60318)
5e209cb560 feat remove TestBed.get (#​60414)
d8fbb909ce feat rename afterRender to afterEveryRender and stabilize (#​60999)
567522398f feat stabilize incremental hydration api (#​60888)
8d050b5bfc feat stabilize linkedSignal API (#​60741)
866cea9a05 feat Stabilize PendingTasks Injectable (#​60716)
bf8492b871 feat stabilize withI18nSupport() api (#​60889)
be44cc8f40 feat support listening to outputs on dynamically-created components (#​60137)
[fe9b79b615](https://redirect.github.com/angular/angular/commit/fe9b79b615bb72989498c2dc9e84

Important

✂ PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate

renovate Bot commented Nov 27, 2025

Copy link
Copy Markdown
Contributor Author

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: package-lock.json
npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error
npm error While resolving: @heap-code/nna@0.0.0
npm error Found: @angular/core@18.2.14
npm error node_modules/@angular/core
npm error   @angular/core@"~18.2.0" from the root project
npm error
npm error Could not resolve dependency:
npm error peer @angular/core@"20.0.7" from @angular/common@20.0.7
npm error node_modules/@angular/common
npm error   @angular/common@"~20.0.0" from the root project
npm error
npm error Fix the upstream dependency conflict, or retry
npm error this command with --force or --legacy-peer-deps
npm error to accept an incorrect (and potentially broken) dependency resolution.
npm error
npm error
npm error For a full report see:
npm error /runner/cache/others/npm/_logs/2026-09-10T20_47_05_507Z-eresolve-report.txt
npm error A complete log of this run can be found in: /runner/cache/others/npm/_logs/2026-09-10T20_47_05_507Z-debug-0.log

@renovate
renovate Bot force-pushed the renovate/npm-angular-common-vulnerability branch 3 times, most recently from ec7c8ec to 0082bd3 Compare December 2, 2025 10:15
@renovate
renovate Bot force-pushed the renovate/npm-angular-common-vulnerability branch 2 times, most recently from 6f8f81a to 235ab72 Compare December 13, 2025 05:16
@renovate
renovate Bot force-pushed the renovate/npm-angular-common-vulnerability branch from 235ab72 to 84c42aa Compare February 10, 2026 14:57
@renovate
renovate Bot force-pushed the renovate/npm-angular-common-vulnerability branch from 84c42aa to e62909e Compare March 27, 2026 05:02
@renovate
renovate Bot force-pushed the renovate/npm-angular-common-vulnerability branch from e62909e to 2219a3e Compare April 10, 2026 01:52
@renovate
renovate Bot force-pushed the renovate/npm-angular-common-vulnerability branch from 2219a3e to 1e01c7c Compare May 5, 2026 22:30
@renovate
renovate Bot force-pushed the renovate/npm-angular-common-vulnerability branch from 1e01c7c to 347908e Compare May 29, 2026 22:46
@renovate
renovate Bot force-pushed the renovate/npm-angular-common-vulnerability branch from 347908e to beb5924 Compare July 16, 2026 01:00
@renovate renovate Bot changed the title fix(deps): update dependency @angular/common to v19 [security] fix(deps): update dependency @angular/common to v20 [security] Jul 16, 2026
@renovate
renovate Bot force-pushed the renovate/npm-angular-common-vulnerability branch from beb5924 to e108af3 Compare July 20, 2026 05:13
@renovate renovate Bot changed the title fix(deps): update dependency @angular/common to v20 [security] fix(deps): update dependency @angular/common to v19 [security] Jul 20, 2026
@renovate
renovate Bot force-pushed the renovate/npm-angular-common-vulnerability branch from e108af3 to 6cce9be Compare July 20, 2026 23:11
@renovate renovate Bot changed the title fix(deps): update dependency @angular/common to v19 [security] fix(deps): update dependency @angular/common to v20 [security] Jul 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants