Repository navigation
@angular/build@21 depends on undici@7.29.1 which is vulnerable to multiple CVEs #34518
Description
Command
other
Is this a regression?
- Yes, this behavior used to work in the previous version
The previous version in which this bug was not present was
No response
Description
@angular/build v21 depends on undici v7.29.1 which is vulnerable to CVE-2026-109924, CVE-2026-109841 and CVE-2026-109869. Fixed version is v7.30.1.
As far as I can tell, @angular/build v20 and v22 do not depend on undici at all and are therefore not affected.
Minimal Reproduction
- npm install @angular/build@21
- npm audit
Exception or Error
Your Environment
Angular CLI : 21.2.27
Angular : 21.2.25
Node.js : 24.22.1
Package Manager : npm 11.19.0
Operating System : linux x64
┌───────────────────────────┬───────────────────┬───────────────────┐
│ Package │ Installed Version │ Requested Version │
├───────────────────────────┼───────────────────┼───────────────────┤
│ @angular/build │ 21.2.27 │ ^21.2.27 │
│ @angular/cdk │ 21.2.14 │ ^21.2.14 │
│ @angular/cli │ 21.2.27 │ ^21.2.21 │
│ @angular/common │ 21.2.25 │ ^21.2.20 │
│ @angular/compiler │ 21.2.25 │ ^21.2.25 │
│ @angular/compiler-cli │ 21.2.25 │ ^21.2.25 │
│ @angular/core │ 21.2.25 │ ^21.2.25 │
│ @angular/elements │ 21.2.25 │ ^21.2.20 │
│ @angular/forms │ 21.2.25 │ ^21.2.20 │
│ @angular/platform-browser │ 21.2.25 │ ^21.2.20 │
│ @angular/router │ 21.2.25 │ ^21.2.25 │
│ @angular/service-worker │ 21.2.25 │ ^21.2.20 │
│ ng-packagr │ 21.2.7 │ ^21.2 │
│ rxjs │ 7.8.2 │ ^7.8.2 │
│ typescript │ 5.9.3 │ ^5.9.3 || ^6 │
│ vitest │ 4.1.12 │ ^4.1.7 │
│ zone.js │ 0.16.3 │ ^0.15 || ^0.16 │
└───────────────────────────┴───────────────────┴───────────────────┘
Anything else relevant?
Since I open issues to update vulnerable dependencies fairly often now, I want to ask a few questions:
- What is the reason for pinning versions in package.json? In this case doing a ~7.29.1 would not help, I know, but in many other cases it would.
- Should there be some kind of security scanner, a scheduled GitHub action running
npm auditor something similar? This would probably detect vulnerable dependencies way faster than I do. - The time to fix those vulnerable dependencies measured from release of the fix for the dependency until release of @angular/xxx is sometimes very long (> 1 week), which in my opinion is too much nowadays. This is my general concern and the first two questions already try to find solutions to this. Any other ideas?
Activity
florimond-collette commentedon Oct 25, 2026
Adding the advisory IDs and a per-branch check. All three advisories are fixed in undici 7.30.1:
>= 7.18.0, < 7.30.1>= 7.0.0, < 7.30.1>= 7.15.0, < 7.30.1Affected lines, confirming the assessment above:
v21-lts):@angular/buildhas"undici": "7.29.1"in itsdependencies, so every v21 install gets the vulnerable version.node-gyp(^6.25.0), which is already patched, andnpm auditreports 0 vulnerabilities. The repo still pins 7.29.1 as a devDependency (root and@angular-devkit/build-angular).npm install @angular/build@21followed bynpm audit:Fix PRs, in the same shape as the previous undici backports (#34053, #34052):
fix(@angular-devkit/build-angular): bump undici to 7.30.1
fix(@angular/build): bump undici to 7.30.1
cracksalad commentedon Oct 26, 2026
@alan-agius4 what about the additional questions I stated above?
alan-agius4 commentedon Oct 26, 2026
Hi @cracksalad,
To answer your questions:
Pinning versions: We deliberately pin dependencies in the CLI to guarantee deterministic builds and prevent unexpected regressions. With build tooling and compilers (such as Vite, esbuild, and TypeScript), upstream patch and minor updates frequently introduce subtle behavioral changes or breakages. Pinning ensures that what users install has been fully verified against our test suites. If an application needs an immediate patch before a CLI release, package manager overrides (npm or pnpm) or resolutions (yarn) can be used in the workspace
package.json.Automated security scanning: We already use automated tooling Renovate across the repository that tracks security advisories and opens PRs for dependency updates. While updates on LTS branches are handled more conservatively to maintain stability, we prioritize critical security updates whenever necessary.
Release cadence: We ship regular releases every Wednesday. If a critical zero-day vulnerability directly impacts the production runtime, we issue an immediate out-of-band release. However, for build-time tooling where high-severity CVEs often turn out to be false alarms or unexplainable in CLI usage we follow our regular weekly schedule to ensure thorough testing and validation before releasing
cracksalad commentedon Oct 26, 2026
@alan-agius4 thannk you very much for the explanations. I get your points.
It might be a partial solution though to check which dependencies stick to SemVer fairly closely and replace their pinned version by a "~x.y.z" style constraint. I mean expecting every maintainer of an Angular dependent project to override the pinned version constraint in one of Angular's packages on their own risk just to see the same change being made by the Angular maintainers about a week or so later does not seem like a proper way to handle this. Maybe I am the only one seeing a problem there. Then feel free to ignore me 😁 I am just trying to help make this project even better.