Skip to content

fix(deps): update dependency @angular/platform-server to v20 [security] - #813

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

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

Conversation

@renovate

@renovate renovate Bot commented Jul 16, 2026 •
edited
Loading

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/platform-server (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 SSR: Global Platform Injector Race Condition Leads to Cross-Request Data Leakage

CVE-2025-59052 / GHSA-68x2-mx4q-78m7

More information

Details

Impact

Angular uses a DI container (the "platform injector") to hold request-specific state during server-side rendering. For historical reasons, the container was stored as a JavaScript module-scoped global variable. When multiple requests are processed concurrently, they could inadvertently share or overwrite the global injector state.

In practical terms, this can lead to one request responding with data meant for a completely different request, leaking data or tokens included on the rendered page or in response headers. As long as an attacker had network access to send any traffic that received a rendered response, they may have been able to send a large number of requests and then inspect the responses for information leaks.

The following APIs were vulnerable and required SSR-only breaking changes:

  • bootstrapApplication: This function previously implicitly retrieved the last platform injector that was created. It now requires an explicit BootstrapContext in a server environment. This function is only used for standalone applications. NgModule-based applications are not affected.
  • getPlatform: This function previously returned the last platform instance that was created. It now always returns null in a server environment.
  • destroyPlatform: This function previously destroyed the last platform instance that was created. It's now a no-op when called in a server environment.

For bootstrapApplication, the framework now provides a new argument to the application's bootstrap function:

// Before:
const bootstrap = () => bootstrapApplication(AppComponent, config);

// After:
const bootstrap = (context: BootstrapContext) =>
  bootstrapApplication(AppComponent, config, context);

As is usually the case for changes to Angular, an automatic schematic will take care of these code changes as part of ng update:

##### For apps on Angular v20:
ng update @angular/cli @angular/core

##### For apps on Angular v19:
ng update @angular/cli@19 @angular/core@19

##### For apps on Angular v18:
ng update @angular/cli@18 @angular/core@18

The schematic can also be invoked explicitly if the version bump was pulled in independently:

##### For apps on Angular v20:
ng update @angular/core --name add-bootstrap-context-to-server-main

##### For apps on Angular v19:
ng update @angular/core@19 --name add-bootstrap-context-to-server-main

##### For apps on Angular v18:
ng update @angular/core@18 --name add-bootstrap-context-to-server-main

For applications that still use CommonEngine, the bootstrap property in CommonEngineOptions also gains the same context argument in the patched versions of Angular.

In local development (ng serve), Angular CLI triggered a codepath for Angular's "JIT" feature on the server even in applications that weren't using it in the browser. The codepath introduced async behavior between platform creation and application bootstrap, triggering the race condition even if an application didn't explicitly use getPlatform or custom async logic in bootstrap. Angular applications should never run in this mode outside of local development.

Patches

The issue has been patched in all active release lines as well as in the v21 prerelease:

  • @angular/platform-server: 21.0.0-next.3

  • @angular/platform-server: 20.3.0

  • @angular/platform-server: 19.2.15

  • @angular/platform-server: 18.2.14

  • @angular/ssr: 21.0.0-next.3

  • @angular/ssr: 20.3.0

  • @angular/ssr: 19.2.16

  • @angular/ssr: 18.2.21

Workarounds
  • Disable SSR via Server Routes (v19+) or builder options.
  • Remove any asynchronous behavior from custom bootstrap functions.
  • Remove uses of getPlatform() in application code.
  • Ensure that the server build defines ngJitMode as false.
References

Severity

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

References

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

Angular: SSRF via protocol-relative and backslash URLs in Angular Platform-Server

CVE-2026-41423 / GHSA-45q2-gjvg-7973

More information

Details

Impact

A Server-Side Request Forgery (SSRF) vulnerability exists in @angular/platform-server due to improper handling of URLs during Server-Side Rendering (SSR).

When an attacker sends a request such as GET /\evil.com/ HTTP/1.1 the server engine (Express, etc.) passes the URL string to Angular’s rendering functions.

Because the URL parser normalizes the backslash to a forward slash for HTTP/HTTPS schemes, the internal state of the application is hijacked to believe the current origin is evil.com. This misinterpretation tricks the application into treating the attacker’s domain as the local origin. Consequently, any relative HttpClient requests or PlatformLocation.hostname references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services.

Affected APIs:

  • renderModule
  • renderApplication
  • CommonEngine (from @angular/ssr)

Non-Affected APIs:

  • AngularAppEngine (from @angular/ssr)
  • AngularNodeAppEngine (from @angular/ssr)
Attack Preconditions
  • The server has outbound network access.
  • The application uses Angular SSR via the affected APIs.
  • A pathname is passed as URL to the rendering method (e.g. using req.url).
  • The server-side code performs HTTP requests using HttpClient with relative URLs or uses PlatformLocation.hostname to build URLs.
Patches
  • 22.0.0-next.8
  • 21.2.9
  • 20.3.19
  • 19.2.21
Workarounds

Developers should implement a middleware to sanitize the request URL before it reaches Angular. This involves stripping or normalizing leading slashes:

app.use((req, res, next) => {
  // Sanitize the URL to ensure it starts with a single forward slash
  if (req.url.startsWith('//') || req.url.startsWith('/\\') || req.url.startsWith('\\')) {
     req.url = '/' + req.url.replace(/^[/\\]+/, '');
  }
  next();
});
References

Severity

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

References

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

Angular SSR: Global Platform Injector Race Condition Leads to Cross-Request Data Leakage

CVE-2025-59052 / GHSA-68x2-mx4q-78m7

More information

Details

Impact

Angular uses a DI container (the "platform injector") to hold request-specific state during server-side rendering. For historical reasons, the container was stored as a JavaScript module-scoped global variable. When multiple requests are processed concurrently, they could inadvertently share or overwrite the global injector state.

In practical terms, this can lead to one request responding with data meant for a completely different request, leaking data or tokens included on the rendered page or in response headers. As long as an attacker had network access to send any traffic that received a rendered response, they may have been able to send a large number of requests and then inspect the responses for information leaks.

The following APIs were vulnerable and required SSR-only breaking changes:

  • bootstrapApplication: This function previously implicitly retrieved the last platform injector that was created. It now requires an explicit BootstrapContext in a server environment. This function is only used for standalone applications. NgModule-based applications are not affected.
  • getPlatform: This function previously returned the last platform instance that was created. It now always returns null in a server environment.
  • destroyPlatform: This function previously destroyed the last platform instance that was created. It's now a no-op when called in a server environment.

For bootstrapApplication, the framework now provides a new argument to the application's bootstrap function:

// Before:
const bootstrap = () => bootstrapApplication(AppComponent, config);

// After:
const bootstrap = (context: BootstrapContext) =>
  bootstrapApplication(AppComponent, config, context);

As is usually the case for changes to Angular, an automatic schematic will take care of these code changes as part of ng update:

##### For apps on Angular v20:
ng update @angular/cli @angular/core

##### For apps on Angular v19:
ng update @angular/cli@19 @angular/core@19

##### For apps on Angular v18:
ng update @angular/cli@18 @angular/core@18

The schematic can also be invoked explicitly if the version bump was pulled in independently:

##### For apps on Angular v20:
ng update @angular/core --name add-bootstrap-context-to-server-main

##### For apps on Angular v19:
ng update @angular/core@19 --name add-bootstrap-context-to-server-main

##### For apps on Angular v18:
ng update @angular/core@18 --name add-bootstrap-context-to-server-main

For applications that still use CommonEngine, the bootstrap property in CommonEngineOptions also gains the same context argument in the patched versions of Angular.

In local development (ng serve), Angular CLI triggered a codepath for Angular's "JIT" feature on the server even in applications that weren't using it in the browser. The codepath introduced async behavior between platform creation and application bootstrap, triggering the race condition even if an application didn't explicitly use getPlatform or custom async logic in bootstrap. Angular applications should never run in this mode outside of local development.

Patches

The issue has been patched in all active release lines as well as in the v21 prerelease:

  • @angular/platform-server: 21.0.0-next.3

  • @angular/platform-server: 20.3.0

  • @angular/platform-server: 19.2.15

  • @angular/platform-server: 18.2.14

  • @angular/ssr: 21.0.0-next.3

  • @angular/ssr: 20.3.0

  • @angular/ssr: 19.2.16

  • @angular/ssr: 18.2.21

Workarounds
  • Disable SSR via Server Routes (v19+) or builder options.
  • Remove any asynchronous behavior from custom bootstrap functions.
  • Remove uses of getPlatform() in application code.
  • Ensure that the server build defines ngJitMode as false.
References

Severity

  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/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/platform-server: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

CVE-2026-50555 / GHSA-hqr9-c56f-3x7f

More information

Details

A Cross-Site Scripting (XSS) vulnerability exists in @angular/platform-server's DOM emulation dependency (domino) when serializing the content of raw-text elements (such as <script>, <style>, and <iframe>).

domino supports escaping raw-text elements during serialization to prevent closing-tag breakout. However, a Unicode index alignment bug existed in this escaping logic.

In JavaScript, string lengths and character indices are calculated based on UTF-16 code units (where astral characters—such as emojis—occupy 2 code units / 4 bytes). If the bound dynamic text contained astral Unicode characters before the closing tag (e.g. </script>, </style>, or </iframe>), the index offset calculation in domino's replacement logic shifted.

This misalignment caused domino to fail to replace or escape the closing tag, leaving it raw and unescaped in the output HTML.

An attacker who controls the dynamic text can supply a payload containing both an astral Unicode character and a closing tag (e.g., 😀</iframe><script>alert(1)</script>). When serialized on the server during SSR, the browser parses the unescaped closing tag, exits the raw-text context early, and executes the subsequent <script> block, leading to same-origin Cross-Site Scripting (XSS).

Impact

This vulnerability allows an attacker to perform same-origin Cross-Site Scripting (XSS) attacks against any user visiting an SSR-rendered page that binds user-controlled data inside raw-text elements. This can lead to session hijacking, credentials theft, unauthorized actions on behalf of users, and defacement.

Patched Versions
  • 22.0.0-rc.2
  • 21.2.16
  • 20.3.24
  • 19.2.25
Workarounds

If you cannot immediately update your dependencies, you can:

  • Avoid binding user-controlled values inside <iframe> or other raw-text elements.
  • Sanitize any user input placed inside raw-text elements to explicitly strip closing tags before passing it to the template.

Severity

  • CVSS Score: 8.6 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/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/platform-server: SSRF via Hostname Hijacking

CVE-2026-46417 / GHSA-rfh7-fxqc-q52v

More information

Details

Impact

A Server-Side Request Forgery (SSRF) vulnerability exists in @angular/platform-server. The issue stems from how the server-side rendering (SSR) engine processes the request URL provided to the rendering entry points.

When an absolute-form URL (e.g., http://evil.com) is passed to the rendering engine, the internal ServerPlatformLocation can be manipulated into adopting the attacker-controlled domain as the "current" hostname.

Consequently, any relative HttpClient requests or PlatformLocation.hostname references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services.

Fix Information

The vulnerability is mitigated by introducing an Allowlist Mechanism directly into the core rendering APIs.
The renderModule and renderApplication functions now include an allowedHosts configuration option. The rendering engine validates the hostname extracted from the request URL against this list before proceeding. If the hostname does not match an allowed entry, the engine prevents the hostname hijacking, ensuring that HttpClient requests remain restricted to trusted domains.

Patches
  • 22.0.0-next.12
  • 21.2.13
  • 20.3.21
  • 19.2.22
Workarounds

Developers unable to update immediately should implement strict URL validation in their server entry point (e.g., server.ts). Ensure that req.url is validated against a known list of trusted hostnames or normalized to a relative path before being passed torenderApplication or renderModule.

// Example manual normalization in Express
app.get('*', (req, res, next) => {
  const trustedHost = 'localhost:4000';
  // Ensure the request target matches expectations
  if (req.headers.host !== trustedHost) {
     return res.status(403).send('Forbidden');
  }
  next();
});

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:L/SI:L/SA:N

References

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

@​angular/platform-server: URL Parser Differential leading to SSRF Allowlist Bypass

CVE-2026-50168 / GHSA-xrxm-cp7j-8xf6

More information

Details

An issue in the @angular/platform-server package allows remote attackers to bypass host allowlist constraints and direct server-side outgoing requests to arbitrary external endpoints. This occurs due to a parser differential between the strict WHATWG URL parser used for allowlist validation and the lenient Domino URL parser used to initialize the server emulated DOM.

When a server-side request contains a malformed URL with a double port structure (e.g., http://evil.com:80:80/path), Node's strict URL.canParse(url) logic returns false and skips host check validation entirely. However, the same malformed URL is later accepted and parsed leniently by Domino's internal parser, which resolves the origin to http://evil.com:80. The Angular SSR HTTP request interceptor (relativeUrlsTransformerInterceptorFn) then resolves all relative backend HTTP requests against this adopted origin, executing the SSRF attack.

Impact

Any Angular application utilizing server-side rendering (@angular/platform-server) that configures host routing allowlists (allowedHosts) is vulnerable to this allowlist bypass.

By sending an HTTP request with a malformed Host header (e.g. Host: evil.com:80:80) or an absolute-form request URI, an attacker can bypass the allowlist logic completely (even when configured with a strict default deny setup). The SSR application will then route all relative HttpClient outgoing API queries—which commonly carry sensitive credentials, session cookies, and internal authorization tokens—to the attacker-controlled server instead of the intended backend services. Additionally, the attacker can supply custom payloads back to the emulated DOM, leading to response injection and content poisoning within the rendered HTML served to users.

Attack Preconditions

To successfully exploit this vulnerability, the following environment parameters and application states must all concurrently exist:

  1. Active Server-Side Rendering (SSR): The application must be configured to run with Angular Server-Side Rendering (@angular/platform-server).
  2. Host Header/URI Propagation: The SSR handler must reconstruct the request URL using raw client inputs (such as request Host headers or absolute-form URIs) and pass it as config.url to the rendering API (renderApplication or renderModule).
  3. Outbound Relative HTTP Requests: The server application must perform outbound backend API requests using relative paths (e.g., this.http.get('/api/data')) that undergo base-URL interceptor rewriting.
  4. Enabled Allowed Hosts Check: The server must use the framework-provided allowedHosts options to limit valid server locations.
Patches
  • 22.0.0-rc.2
  • 21.2.15
  • 20.3.22
  • 19.2.23

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 SSR: Missing Fallback Raw-Content Serialization Escaping leads to Cross-Site Scripting (XSS)

CVE-2026-69149 / GHSA-vpx6-8pjr-4g3v

More information

Details

A Cross-Site Scripting (XSS) vulnerability exists in @angular/platform-server's DOM emulation dependency (domino) when serializing the content of fallback raw-content elements (<iframe>, <noembed>, <noframes>, and <noscript>).

When rendering dynamic text content inside fallback raw-content elements via template bindings, the template engine expects the browser to render the content safely. Under Server-Side Rendering (SSR), domino is configured with scripting enabled, meaning these elements are treated as raw-text elements.

However, domino's serializer previously did not escape text nodes within fallback raw-content elements (<iframe>, <noembed>, <noframes>, <noscript>) during DOM serialization. As a result, any occurrence of closing tags in the bound dynamic text was not escaped.

The unescaped closing tag could be serialized directly into the output HTML. When parsed by a browser or re-parsed during SSR post-processing without preserving raw-content parser state, an injected closing tag closes the element early, allowing an injected script block to execute in the user's browser context, causing same-origin Cross-Site Scripting (XSS).

Impact

This vulnerability allows an attacker to perform same-origin Cross-Site Scripting (XSS) attacks against any user visiting an SSR-rendered page that binds user-controlled data inside fallback raw-content elements (<iframe>, <noembed>, <noframes>, <noscript>). This can lead to session hijacking, credentials theft, unauthorized actions on behalf of users, and defacement.

Patched Versions
  • 22.0.7
  • 21.2.19
  • 20.3.27
Workarounds

If you cannot immediately update your dependencies, you can mitigate this issue using any of the following approaches:

  • Disable critical CSS inlining: Critical CSS inlining in Angular SSR post-processes the rendered HTML using domino. Disabling this step prevents domino from re-parsing and re-serializing the HTML during server-side rendering.
    • In angular.json, set inlineCritical to false under style optimization options: 
      {
  "projects": {
    "my-app": {
      "architect": {
        "build": {
          "builder": "@angular/build:application",
          "options": {
            "optimization": {
              "styles": {
                "inlineCritical": false
              }
            }
          }
        }
      }
    }
  }
}
    • When rendering programmatically with CommonEngine, set inlineCriticalCss: false in your render options.
  • Avoid binding user-controlled values inside fallback raw-content elements (<iframe>, <noembed>, <noframes>, <noscript>).
  • Sanitize user input placed inside these elements to explicitly strip or escape closing tags before passing it to the template.

Severity

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

References

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

Release Notes

angular/angular (@​angular/platform-server)

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 feat update Node.js version support (#​60545)
e170d24240 fix add migration away from InjectFlags (#​60318)
7eb59d3887 fix added @​angular/compiler as a peer dependency (#​55610)
7232ce5b17 fix Catch and report rejections in async function of PendingTasks.run (#​60044)
fd12220a35 fix defer block render failures should report to application error handler (#​60149)
3459faadbf fix do not allow setInput to be used with inputBinding (#​60137)
0ac949c266 fix do not run change detection on global error events (#​60944)
4fe34f4cfe fix enable stashing only when withEventReplay() is invoked (#​61077)
962b59b14e fix Ensure ComponentFixture does not duplicate error reporting from FakeAsync (#​60104)
7b819be83f fix Ensure errors in listeners report to the application error handler (#​60251)
ff772d7800 fix fix typing on injector.get to omit 'any' (#​60202)
13d1c8ab38 fix fixes timing of hydration cleanup on control flow (#​60425)

✂ Note

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 Jul 16, 2026 •
edited
Loading

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/common@18.2.14
npm error node_modules/@angular/common
npm error   @angular/common@"~18.2.0" from the root project
npm error
npm error Could not resolve dependency:
npm error peer @angular/common@"20.0.7" from @angular/platform-server@20.0.7
npm error node_modules/@angular/platform-server
npm error   @angular/platform-server@"~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-08-03T17_11_21_588Z-eresolve-report.txt
npm error A complete log of this run can be found in: /runner/cache/others/npm/_logs/2026-08-03T17_11_21_588Z-debug-0.log

@renovate renovate Bot changed the title fix(deps): update dependency @angular/platform-server to v19 [security] chore(deps): update dependency @angular/platform-server to v18.2.14 [security] Jul 20, 2026
@renovate renovate Bot changed the title chore(deps): update dependency @angular/platform-server to v18.2.14 [security] fix(deps): update dependency @angular/platform-server to v19 [security] Jul 20, 2026
@renovate
renovate Bot force-pushed the renovate/npm-angular-platform-server-vulnerability branch from 6c74244 to 8eb0703 Compare August 3, 2026 17:11
@renovate renovate Bot changed the title fix(deps): update dependency @angular/platform-server to v19 [security] fix(deps): update dependency @angular/platform-server to v20 [security] Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies renovate security

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants