Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Haben Sie schon einmal während einer Softwareinstallation „CVE-“Codes vorbeiziehen sehen und sich gefragt, was sie bedeuten? Da sind Sie nicht allein; das ist uns allen schon einmal passiert. Diese Codes sind wichtige Warnsignale für die Cybersicherheit. Ich werde Ihnen die Zusammensetzung einer CVE-Kennung erläutern, ihre Struktur erklären und auf Konzepte wie „transitive Abhängigkeiten“ sowie bewährte Verfahren zum Schließen von Sicherheitslücken eingehen.
Was ist ein CVE?
Früher hatten Sicherheitslücken Namen, die sich konkret auf den jeweiligen Fehler bezogen, wie beispielsweise „IIS-Pfadtraversal“, doch da sich die Sicherheitslücken über Jahrzehnte hinweg häuften, wurde eine standardisierte Kennung notwendig.
Eine CVE-Kennung (Common Vulnerabilities and Exposures) dient als standardisierte Bezeichnung für öffentlich bekannte, identifizierte Sicherheitslücken. Diese einheitliche Terminologie ermöglicht es Sicherheitsexperten und Anbietern, schnell und präzise über bestimmte Schwachstellen zu kommunizieren. Die Identifizierung von CVEs in Software ist unerlässlich – insbesondere in Umgebungen mit vielen externen Komponenten –, da sie es Sicherheitsteams ermöglicht, Patches zu priorisieren, Risiken einzuschätzen und Fehler rasch zu beheben, bevor sie ausgenutzt werden können, und so Daten und die Systemverfügbarkeit zu schützen.
Man kann sich eine CVE-Nummer wie eine Sendungsverfolgungsnummer vorstellen, so als würde man ein Paket bei seinem Lieblingshändler bestellen. Auf diese Weise lassen sich die Fehler nachverfolgen und man bleibt darüber auf dem Laufenden, welche Versionen eines Pakets von der Sicherheitslücke betroffen waren.
Einen umfassenden Überblick über bewährte Vorgehensweisen erhalten Sie in unserem ausführlichen Leitfaden zum Thema CVE-Patching.
Der Aufbau eines CVE
Ein CVE sieht wie folgt aus: ‘CVE-2025-1111“ – das Präfix CVE, gefolgt vom Jahr, in dem die Schwachstelle entdeckt wurde, gefolgt von einer eindeutigen Kennung.
Diese Nummer wird von der MITRE Corporation und einem weltweiten Netzwerk von über 490 CNAs vergeben. Zu diesen CNAs (CVE Numbering Authorities) gehören IT-Anbieter wie Microsoft, Red Hat und Oracle sowie verschiedene Organisationen und Sicherheitsforscher.
Die National Vulnerability Database (NVD) hat die Aufgabe, jeden CVE zu ergänzen, sobald er in der CVE-Liste veröffentlicht wurde. In der Praxis bedeutet dies, dass eine Übergabe zwischen MITRE und der NVD stattfindet, woraufhin die NVD den CVE mit zusätzlichen Metadaten anreichert. Nach Abschluss dieser Übergabe durchläuft der Eintrag einen bestimmten Prozess. Laut NISTumfasst der Prozess:
- Durchsicht des Materials, das mit dem CVE bereitgestellt wird.
- Ein CWE (CCommon Weakness Enumeration) wird der Schwachstelle eine ID zugewiesen, die sie kategorisiert.
- Es werden Metriken zur Ausnutzbarkeit (gemäß CVSS v3.1 oder v4.0) und zur Auswirkung zugewiesen.
- Mit dieser Sicherheitslücke ist eine CPE-Erklärung (Common Platform Enumerator) verbunden.
- Schließlich führt ein leitender Analyst eine Qualitätssicherung durch, bevor die aufbereiteten Daten veröffentlicht werden.
Sobald die CVE veröffentlicht ist, kann es in Zukunft zu weiteren Aktualisierungen kommen. Es könnten Änderungen vorgenommen, Referenzmaterial hinzugefügt oder Beschreibungen aktualisiert werden usw.
Die Anfälligkeit verstehen
Wenn Sie npm audit ausführen oder einfach nur ein Paket in Ihrem Projekt installieren, erhalten Sie möglicherweise eine Ausgabe wie: 7 Sicherheitslücken mit hohem Schweregrad. Sie fragen sich vielleicht: „Was ist das und wie sieht das aus?“ Die anfängliche Ausgabe listet nicht die CVEs auf, sondern die betroffenen Pakete und deren Versionen. Hier ist ein Beispiel für die Ausgabe von npm audit bei der Installation von Angular v18 (das Bild wird bei älteren Versionen wie Angular 16 unübersichtlicher, wo sich seit über einem Jahr veraltete Abhängigkeiten angesammelt haben):
Zusammenfassung 4.0.0 - 4.58.0 Schweregrad: hoch Rollup 4 weist eine Schwachstelle für beliebiges Schreiben von Dateien über Pfadtraversal auf – https://github.com/advisories/GHSA-mw96-cpmx-2vgc Korrektur verfügbar über `npm audit fix --force` Installiert @angular-devkit/build-angular@19.2.22, was eine kompatibilitätsbrechende Änderung darstellt node_modules/rollup @angular/build 18.1.0-next.0 - 19.2.21 || 20.0.0-weiter.0 - 20.2.0-rc.1 || 20.3.4 – 20.3.17 Hängt von anfälligen Versionen von Rollup ab node_modules/@angular/build @angular-devkit/build-angular * Hängt von anfälligen Versionen von @angular/build ab Hängt von anfälligen Versionen von copy-webpack-plugin ab node_modules/@angular-devkit/build-angular
Das bedeutet, dass die Rollup Paket als transitive Abhängigkeit installiert wurde. Betroffen sind die Versionen 4.0.0 – 4.58.0. Diese Versionen weisen eine Sicherheitslücke mit hohem Schweregrad auf. Die Sicherheitslücke wird als „Arbitrary File Write via Path Traversal“ bezeichnet. Das bedeutet, dass ein Angreifer Eingaben erstellen kann, die Rollup dazu verleiten, eine Datei an Orten zu speichern, an denen Sie dies nicht beabsichtigt haben. Dies ist ein klassisches Beispiel für eine Schwachstelle in der Software-Lieferkette. Sie haben ein Paket installiert, aber Rollup kam mitgeliefert, und Sie haben es nicht absichtlich installiert.
@angular-devkit/build-angular └── @angular/build (anfällige Versionen) └── rollup (4.0.0 – 4.58.0) ← das anfällige Paket
Mängel beheben
Wenn wir weiterhin auf der Grundlage des Rollup weiterarbeiten, gibt es verschiedene Möglichkeiten, diese Schwachstelle zu beheben, wenn Sie als Entwickler von Sicherheitsanwendungen nicht aktiv CVE-Korrekturen schreiben. Sie könnten npm audit fix –force ausführen, und das könnte das das Problem beheben, aber dieser Ansatz bringt seine eigenen Vor- und Nachteile mit sich.
Wenn Sie diesen Befehl ausführen, wird auch @angular-devkit/build-angular auf Version 19.2.22. Diese Version ist als „Breaking Change“ gekennzeichnet und könnte sich auf Build-Konfigurationen und APIs auswirken. Möglicherweise sind später Änderungen am Code erforderlich – und wer hat schon Zeit dafür?
Hier sind einige Möglichkeiten, wie du das Problem beheben kannst:
- Überprüfen Sie Ihre Angular-Version, um einzuschätzen, wie groß der Sprung zur neuen Version wäre.
- Siehe das Changelog von @angular-devkit/build-angular auf die aktualisierte Version.
- Erstelle einen neuen Zweig und führe die Korrektur dort durch, niemals im Hauptzweig.
- Nimm die Änderung zur Kenntnis und verschiebe sie, falls sie zu riskant ist.
Überschreibungen
Die Verwendung einer Überschreibung ist eine vorübergehende Lösung, die Ihnen weiterhilft, aber auch Risiken birgt. Sie kann eine gepatchte, bestimmte Version des Rollup Paket erzwingen, ohne auf das umwerfende Upgrade von @angular-devkit/build-angularzurückgreifen zu müssen.
Sie können die gepatchte Version in Ihr package.jsowie unten gezeigt hinzufügen. Die Version im Beispiel-JSON ist die aktuellste gepatchte Version vom Februar 2026.
{ "overrides": { "rollup": "^4.59.0" } }
Stelle sicher, dass du folgenden Befehl ausführst npm install ausführen, um die gepatchte Version zu installieren, und überprüfen Sie durch Ausführen von npm audit. Sie sollten sehen, dass die Sicherheitslücke behoben ist.
Der Grund, warum diese Lösung funktioniert, ist, dass die overrides npm mitteilt: „Egal was passiert, ohne Ausreden, installiere dieses Paket“. Es umgeht den transitiven Abhängigkeitsbaum mithilfe des „overrides“.
Überschreibungen sind eine gute Lösung, wenn:
- Du musst unbedingt versenden, wirst aber durch das anstehende Upgrade daran gehindert
- Da die Sicherheitslücke in einem Build-Tool und nicht in einem Produktions-Tool liegt, ist das Risiko geringer
- Der Build wurde getestet, und es wurde bestätigt, dass alles einwandfrei funktioniert
Es gibt bessere Möglichkeiten, dies anzugehen, da die Überschreibungen nur vorübergehend ist. Sie können die kompatibilitätsbrechende Änderung akzeptieren, solange Sie sie in einem Branch testen und die Tests bestehen. Wenn keine Probleme auftreten und sie geprüft wurde, fahren Sie fort. Wenn es einen Patch gibt, der nicht kompatibilitätsbrechend ist, verwenden Sie diesen. Überprüfen Sie das Changelog auf Major-/Minor-Patches, die den Build nicht unterbrechen. Zuletzt sollten Sie das tatsächliche Risiko bewerten.
Wie oben erwähnt, Rollup ein Build-Tool und kein Werkzeug für die Produktionsumgebung, sodass das Risiko geringer ist. Es wird in der Regel nicht in Produktionsumgebungen ausgeführt. Die Verwendung von Überschreibungen kann letztendlich ein falsches Gefühl der Sicherheit vermitteln. Sie erhalten keine Warnungen mehr von npm audit, , aber Sie führen auch ungetestete Änderungen in Ihr Projekt bzw. Ihren Build ein.
Die Schlussfolgerung ist einfach: Wenn Sie die inkompatible Änderung akzeptieren können, tun Sie es. Wenn nicht, verwenden Sie Überschreibungen.
