question Re: Question about Angular dependency strategy in CFM 4.12.x in Support Questions

Question about Angular dependency strategy in CFM 4.12.x

ksw — Sun, 23 Aug 2026 14:49:46 GMT

Apache NiFi 2.6.0 upstream ships with Angular 19.2.14. Apache did not change the Angular dependency within the NiFi 2.6.x release line. Instead, the Angular dependency update was introduced as part of the NiFi 2.7.0 development cycle.

In contrast, CFM modified the Angular dependency while continuing to ship NiFi 2.6.0.

CFM 4.12.0.0 upgraded Angular from 19.2.14 to 19.2.19. After this change, the frontend no longer sent the Request-Token header with API requests, causing NiFi’s XSRF protection to reject legitimate UI operations. This regression was later addressed in CFM 4.12.0.1.

However, instead of remaining on the Angular 19.x patch line, CFM 4.12.0.1 upgraded Angular again to 20.2.4.

After inspecting the compiled frontend bundled with CFM 4.12.0.1, I confirmed that it is built with Angular 20.2.4. I also verified that the bundled frontend still follows the pre-fix implementation for GHSA-58c5-g7wp-6w37 and does not contain the upstream security fix. According to Angular’s official security advisory, Angular 20.2.4 is also below the first fixed Angular 20 release (20.3.14).

From a release engineering perspective, this dependency strategy is difficult to understand.

Apache chose not to introduce this dependency change into the NiFi 2.6.x release line. Instead, it was delivered as part of NiFi 2.7.0, allowing the framework update to be integrated and validated together with the rest of the release.

In contrast, CFM introduced major frontend dependency changes into a maintenance release based on NiFi 2.6.0. This not only introduced a functional regression in 4.12.0.0, but also further diverged from the Apache NiFi upstream while selecting an Angular version that still does not contain the official upstream security fix.

Could you please explain the rationale behind this dependency strategy?

Re: Question about Angular dependency strategy in CFM 4.12.x

vafs — Tue, 25 Aug 2026 17:19:37 GMT

Helllo @ksw,

I was checking and trying to understand the reason of that change.

In big words, looks like the Angular upgrade was done to solve a separete CVE.
So it was not focused on that specific point you mentioned.

Do you have the CVE you refer to see what are the plans with it?

Re: Question about Angular dependency strategy in CFM 4.12.x

ksw — Wed, 26 Aug 2026 07:04:56 GMT

Thanks for checking.

The issue I am referring to is CVE-2025-66035 / GHSA-58c5-g7wp-6w37:

https://github.com/angular/angular/security/advisories/GHSA-58c5-g7wp-6w37

According to the Angular security advisory, the affected versions include:

Angular 19: versions below 19.2.16
Angular 20: versions below 20.3.14
Angular 21: versions below 21.0.1

The first patched releases are therefore 19.2.16, 20.3.14, and 21.0.1 respectively.

CFM 4.12.0.1 is bundled with Angular 20.2.4, so it still falls within the affected Angular 20 version range.

I also inspected the compiled frontend bundled with CFM 4.12.0.1 and it appears to still contain the pre-fix XSRF implementation, which is consistent with the Angular advisory.

So my concern is that, although the Angular upgrade may originally have been introduced to address a separate CVE, the resulting CFM version moved from the NiFi 2.6 upstream dependency (Angular 19.2.14) to Angular 20.2.4, while still remaining vulnerable to CVE-2025-66035.

Could you please check whether there is already a plan to update the Angular dependency to a fixed version, such as Angular 20.3.14 or later?

I would also be interested to understand which separate CVE originally motivated the Angular 20 upgrade, if you have that information.

Re: Question about Angular dependency strategy in CFM 4.12.x

ksw — Wed, 26 Aug 2026 07:12:02 GMT

My concern is not only why Angular was upgraded in the first place. The earlier move from the NiFi 2.6 upstream version, Angular 19.2.14, to 19.2.19 already caused a major UI regression because the Request-Token header was no longer sent, making many legitimate NiFi UI operations fail due to XSRF protection.

Given that experience, I am trying to understand why the follow-up fix in CFM 4.12.0.1 moved even further away from the NiFi 2.6 upstream baseline by upgrading to Angular 20.2.4, instead of using a compatible Angular 19.x fix or otherwise aligning with the version validated by upstream NiFi.

The CVE I am referring to is CVE-2025-66035 / GHSA-58c5-g7wp-6w37. Angular 20.2.4 is still within the affected range, with 20.3.14 being the first fixed Angular 20 release.

So I would like to understand both the CVE that originally motivated the Angular upgrade and the rationale for selecting Angular 20.2.4 specifically after the earlier 19.2.19 regression.

Re: Question about Angular dependency strategy in CFM 4.12.x

vafs — Wed, 26 Aug 2026 17:20:00 GMT

Hello @ksw,

Sorry, just checking more looks like it was to solve an UI bug. Not an specific CVE.

For CVE-2025-66035 / GHSA-58c5-g7wp-6w37 I suggest to open a ticket so we can report this with the security team.
Can you do that please?

If you have a CVE scanner and can run a report would be even better.