Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

@angular/build@21 depends on [email protected] which is vulnerable to multiple CVEs

Offen
  • Stimmt etwas nicht?
#34,518 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@florimond-collette arbeitet bereits daran.

Seit 25.10.2026.

  • #34521 von @florimond-collette — offen

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
30/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
node.js, typescript
Bereich
build-system

Rechercherichtung

Two open pull requests (#34521, #34522) already target this bump, so the fix is effectively claimed. If picking it up anyway, look at the undici dependency of @angular/build in the package.json / lockfile for the v21 branch, bump it to v7.30.1, and verify with npm audit that the CVEs are resolved.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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
  1. npm install @angular/build@21
  2. 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:

  1. 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.
  2. Should there be some kind of security scanner, a scheduled GitHub action running npm audit or something similar? This would probably detect vulnerable dependencies way faster than I do.
  3. 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?
Vorherrschende Sprache
TypeScript
Sterne
27k
Forks
11.8k
Ø Merge
1 T. 1 Std.
Gemergte PRs (30 T.)
223

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus angular/angular-cli

Alle Issues in angular/angular-cli

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.