Wie man einen CVE liest, ohne in Panik zu geraten

Eine CVE-ID taucht in Ihrem Terminal auf, in Verbindung mit einem Paket, das Sie nie absichtlich installiert haben, und der erste Reflex ist, das Schlimmste anzunehmen. Das haben wir alle schon erlebt. Diese Codes sind so etwas wie ein Notsignal in der Cybersicherheit, und sobald man versteht, wie sie aufgebaut sind, sind sie nicht mehr beängstigend, sondern werden nützlich.

Ich habe bereits darüber geschrieben, wollte dieses Mal aber tiefer ins Detail gehen: Was sagen die Metadaten eigentlich aus, wie kommt eine Schwachstelle durch eine Abhängigkeit zum Vorschein, die man nie selbst ausgewählt hat, und wie erspart SecureChain einem einen Großteil des Aufwands beim Patchen? Eine echte Sicherheitslücke zieht sich durch das Ganze: CVE-2026-27606 im Rollup-Bundler.

Was ist ein CVE?

Früher hatten Sicherheitslücken Namen, die sich konkret auf den jeweiligen Fehler bezogen, wie zum Beispiel „IIS-Pfadtraversal“. Das funktionierte gut, bis sich die Schwachstellen über Jahrzehnte hinweg häuften und jeder Anbieter und jede Datenbank ihre eigenen Bezeichnungen für ein und dasselbe Problem erfand.

Eine CVE-Kennung (Common Vulnerabilities and Exposures) ist eine standardisierte Bezeichnung für eine öffentlich bekannte Sicherheitslücke. Sie bietet Sicherheitsexperten und Anbietern eine gemeinsame Fachsprache für eine bestimmte Schwachstelle. Dies ist vor allem in Umgebungen mit vielen externen Komponenten von Bedeutung, in denen die Identifizierung von CVEs es einem Team ermöglicht, die Installation von Patches zu priorisieren und Fehler zu beheben, bevor jemand diese ausnutzt.

Stellen Sie sich eine CVE-Nummer wie eine Sendungsnummer für ein Paket vor, das Sie online bestellt haben. Es handelt sich nicht um das Paket selbst, sondern um die Nummer, mit der Sie (und alle anderen) genau nachverfolgen können, um welchen Fehler es sich handelt und welche Versionen davon betroffen sind.

Zwei Dinge werden jedoch ständig miteinander verwechselt. Die CVE-ID ist lediglich eine Kennung und enthält keine Einstufung des Schweregrads. Der dahinterstehende CVE-Eintrag kann betroffene Versionen, Verweise, eine Schwachstellenklasse und eine Schweregradbewertung desjenigen enthalten, der die ID vergeben hat. Andere Organisationen führen zusätzlich eigene Analysen durch, und diese stimmen nicht immer überein.

Der Aufbau einer CVE-ID

Nehmen wir das Beispiel aus dem folgenden Terminalbeispiel: CVE-2026-27606. Es besteht aus drei Teilen:

• CVE: Gibt an, dass es sich um einen Eintrag in der CVE-Liste handelt
• 2026: das Jahr, in dem die ID vergeben wurde, oder das Jahr, in dem die Sicherheitslücke bekannt wurde, je nachdem, was zuerst eintrat
• 27606: eine von einer CVE-Nummerierungsstelle vergebene Sequenznummer

Gerade dieser mittlere Teil wird oft missverstanden, und die FAQ des CVE-Programms bringen es auf den Punkt: Die Jahresangabe bezieht sich darauf, wann die ID vergeben wurde oder wann die Sicherheitslücke veröffentlicht wurde – niemals darauf, wann sie entdeckt wurde. Eine Sicherheitslücke, die 2015 veröffentlicht, aber erst 2016 eine ID erhalten hat, trägt weiterhin die Nummer CVE-2015. Die Jahresangabe gibt also an, wann die Sicherheitslücke öffentlich bekannt wurde, nicht, wie lange Angreifer bereits davon wussten.

Die Laufnummer hat lediglich den Zweck, die Eindeutigkeit zu gewährleisten. Sie stellt weder einen Schweregrad noch eine Position in der Warteschlange dar und ist nicht auf vier Ziffern festgelegt: 27606 besteht aus fünf Ziffern, und das Format erlaubt seit 2014 vier oder mehr Ziffern.

Diese Nummern werden von CVE-Nummerierungsstellen (CNAs) vergeben. MITRE hat das Programm 1999 ins Leben gerufen und betreibt es nach wie vor unter der Schirmherrschaft der CISA, doch die Vergabe verteilt sich auf Hunderte autorisierter CNAs – von Anbietern wie Microsoft und Red Hat bis hin zu Open-Source-Stiftungen und Bug-Bounty-Plattformen. Nicht jede CVE-Nummer, die Sie sehen, wird von MITRE vergeben. CVE-2026-27606 stammt von GitHub, das als CNA für die von ihm gehosteten Projekte fungiert.

Was passiert nach der Veröffentlichung einer CVE?

Ein veröffentlichter Datensatz enthält für jeden eine einheitliche Kennung, eine Beschreibung und Referenzen. Darauf aufbauend fügen andere Datenbanken weitere Kontextinformationen hinzu. Die National Vulnerability Database (NVD) wird mit der CVE-Liste synchronisiert und ergänzt die Datensätze um Metadaten, die deren weitere Verarbeitung erleichtern. Laut NIST umfasst dies die Überprüfung der eingereichten Referenzen, die Zuweisung einer CWE, die Zuweisung von CVSS-v3.1- oder v4.0-Metriken, die Verknüpfung mit einer CPE-Erklärung sowie eine Qualitätssicherung durch einen leitenden Analysten.

Hier liegt der Punkt, bei dem viele Tools noch nicht auf dem neuesten Stand sind. Seit dem 15. April 2026 räumt das NIST der Anreicherung von drei Gruppen Priorität ein: Datensätze im KEV-Katalog der CISA, Software der Bundesregierung und kritische Software im Sinne der Executive Order 14028. Alles andere landet weiterhin im NVD, wird in der Regel mit „niedrigster Priorität“ gekennzeichnet und ist nicht für eine sofortige Anreicherung vorgesehen. Da eine Analyse angefordert werden kann, handelt es sich eher um eine Priorisierung als um einen festen Ausschluss. Der Rückstand aus der Zeit vor März 2026 wurde ebenfalls in den Status „Nicht geplant“ verschoben.

Ein Datensatz kann also ohne vom NVD erstellte CVSS-Bewertung, CWE-Zuordnung oder CPE-Konfiguration eingehen und dennoch die eigene Bewertung und Schwachstellenklasse des zuordnenden CNA enthalten. Ein leeres NVD-Feld bedeutet nicht, dass es sich um einen harmlosen Fehler handelt, und es bedeutet auch nicht immer, dass keine Daten vorliegen. Datensätze ändern sich zudem nach der Veröffentlichung, und das NIST analysiert einen geänderten Datensatz nun nur dann erneut, wenn die Änderung wesentliche Auswirkungen auf die Anreicherung hat. Lesen Sie daher alles noch einmal durch, was Sie zurückgestellt haben.

Drei Abkürzungen also, auf die Sie ständig stoßen werden.

CWE (Common Weakness Enumeration) gibt Auskunft über die Fehlerkategorie: Pufferüberlauf, Cross-Site-Scripting, Pfadtraversierung. Während die CVE-Nummer den konkreten Fall bezeichnet, steht die CWE-Nummer für das Muster, zu dem dieser Fall gehört. CVE-2026-27606 ist mit CWE-22, „Pfadtraversierung“, verknüpft. Die Kenntnis der Fehlerklasse hilft Ihnen dabei, denselben Fehler an anderer Stelle zu erkennen, beweist jedoch nicht, dass ein weiterer anfälliger Fall existiert.

CVSS (Common Vulnerability Scoring System) beschreibt den technischen Schweregrad. Es ist ein Anhaltspunkt dafür, ob ein Patch warten kann, aber kein Urteil darüber, wie dringend Sie handeln müssen, und es handelt sich nicht um eine Zahl, die von oben vorgegeben wird. CVE-2026-27606 verdeutlicht dies. Die Rollup-Beratungsseite stuft es als „moderat“ ein, während es im Abschnitt zu den Auswirkungen als „kritisch“ bezeichnet wird; der CVE-Eintrag weist unter CVSS v4.0 von GitHub als zuordnender CNA den Wert 8,8 („hoch“) auf, das NVD bewertete es unter v3.1 mit 9,8 („kritisch“) und Red Hats Security ADP stufte es unter v3.1 mit 9,1 („kritisch“) ein. Vier Einstufungen für einen einzigen Fehler, und bei keiner davon wird berücksichtigt, ob der Code in einem Build-Container oder auf einem mit dem Internet verbundenen Host ausgeführt wird. Achten Sie auf den Angriffsvektor und die CVSS-Version, nicht nur auf das Adjektiv. Informationen zur Wahrscheinlichkeit einer Ausnutzung finden Sie bei EPSS und im KEV-Katalog.

CPE (Common Platform Enumeration) beschreibt betroffene Plattformen und Versionen in standardisierter Form, sodass Sie einen Eintrag mit Ihrer eigenen Umgebung abgleichen können. NVD ordnet diese CVE zu cpe:2.3:a:rollupjs:rollup:*:*:*:*:*:node.js:*:*. Nützlich, aber eher eine Datenbankzuordnung als die tatsächliche Bestandslage, und das Feld, das derzeit am ehesten fehlt.

So sieht ein CVE in Ihrem Terminal tatsächlich aus

Jetzt wird es ernst. Los geht’s npm audit, oder installieren Sie einfach ein Paket, und möglicherweise werden Ihnen 7 Sicherheitslücken mit hohem Schweregrad angezeigt. In der Ausgabe werden die betroffenen Pakete und Versionen aufgeführt, nicht die CVE-Nummern. So sieht das beispielsweise bei der Installation von Angular v18 aus (bei älteren Versionen wie Angular 16, bei denen sich die veralteten Abhängigkeiten über ein Jahr hinweg angesammelt haben, ist die Ausgabe umfangreicher):

rollup  4.0.0 - 4.58.0
Severity: high
Rollup 4 has Arbitrary File Write via Path Traversal - https://github.com/advisories/GHSA-mw96-cpmx-2vgc
fix available via `npm audit fix --force`
Will install @angular-devkit/[email protected], which is a breaking change
node_modules/rollup
  @angular/build  18.1.0-next.0 - 19.2.21 || 20.0.0-next.0 - 20.2.0-rc.1 || 20.3.4 - 20.3.17
  Depends on vulnerable versions of rollup
  node_modules/@angular/build
    @angular-devkit/build-angular  *
    Depends on vulnerable versions of @angular/build
    Depends on vulnerable versions of copy-webpack-plugin
    node_modules/@angular-devkit/build-angular

Beachten Sie, dass in dieser Ausgabe keine CVE-ID enthalten ist. npm verweist auf den GitHub-Hinweis GHSA-mw96-cpmx-2vgc, der der CVE-2026-27606 zugeordnet ist. Übersetzung: „Rollup“ wurde als transitive Abhängigkeit erkannt; die Versionen 4.0.0 bis 4.58.0 weisen eine Schwachstelle mit hohem Schweregrad auf, die als „Arbitrary File Write via Path Traversal“ bezeichnet wird, und Version 4.59.0 behebt diese Schwachstelle in der 4.x-Reihe.

Dieser Fehler kommt häufig vor. Der Dateinamen-Sanitizer von Rollup hat eine Liste ungültiger Zeichen entfernt, wobei der Punkt und beide Schrägstriche ausgelassen wurden, sodass ../ wurde weitergereicht und an … übergeben path.resolve. Jeder, der den Namen einer Ausgabedatei über eine als „input“ bezeichnete Befehlszeilenanweisung, einen Chunk-Alias oder ein bösartiges Plugin steuern kann, kann eine Datei an jedem Ort schreiben, für den der Build-Prozess die entsprechenden Berechtigungen besitzt. Überschreiben ~/.ssh/authorized_keys oder ein Shell-Profil, was zu einer dauerhaften Codeausführung führt.

Das ist ein klassisches Beispiel für eine Schwachstelle in der Software-Lieferkette: Sie haben ein Paket installiert, und das Rollup wurde mitinstalliert. Es lohnt sich, sich darin zu üben, den Abhängigkeitspfad zu lesen.

@angular-devkit/build-angular
└── @angular/build (vulnerable versions)
    └── rollup (4.0.0 - 4.58.0)  ← the vulnerable package

Das Problem beheben, ohne es noch schlimmer zu machen

Ermitteln Sie zunächst, wo das anfällige Paket ausgeführt wird. npm audit --omit=dev konzentriert die Prüfung auf den ohne devDependencies installierten Baum, der bei einem Angular-Projekt die Laufzeitabhängigkeiten von einem Großteil der Build-Toolchain trennt. Dadurch wird die Sicherheitslücke in einen neuen Kontext gerückt, ohne dass ein Fehler zur Build-Zeit dadurch harmlos wird, da Build-Systeme Anmeldedaten speichern und das Ergebnis liefern, das Sie ausliefern.

Beginnen Sie mit der kompatiblen Lösung

Einfach npm audit fix wendet Korrekturmaßnahmen an, die innerhalb der Abhängigkeitsbereiche liegen, die npm bereits erfüllen kann. Wenn das anfällige transitive Paket auf eine gepatchte Version umgestellt werden kann, ohne dass Ihre obersten Abhängigkeiten dabei außerhalb ihrer deklarierten Bereiche geraten, sollten Sie diese Möglichkeit nutzen; die beiden folgenden Optionen kommen nur dann in Frage, wenn dies nicht möglich ist. Ein anschließend durchgeführtes sauberes Audit ist kein Beweis dafür, dass die App sicher ist, sondern lediglich dafür, dass die Sicherheitswarnung aus dem von Ihnen aufgelösten Baum entfernt wurde.

Behandeln Sie „npm audit fix –force“ wie ein leistungsstarkes Werkzeug

Manchmal gibt npm an, dass die Korrektur Folgendes erfordert --force, wie oben beschrieben. In der Dokumentation von npm wird beschrieben, dass dieses Flag Folgendes ermöglicht: npm audit fix um Module außerhalb des von Ihnen angegebenen Abhängigkeitsbereichs zu installieren, einschließlich größerer Änderungen gemäß SemVer. Hier wird @angular-devkit/build-angular auf 19.2.22 aktualisiert, was als kompatibilitätsbrechende Änderung gekennzeichnet ist, die sich auf Ihre Build-Konfiguration und APIs auswirken könnte. Das mag richtig sein. Es könnte aber auch dazu führen, dass Ihr Build nicht mehr funktioniert. Bevor Sie den Befehl ausführen:

• Lesen Sie das Changelog für @angular-devkit/build-angular zwischen Ihrer Version und der Zielversion.
• Verwenden Sie npm audit fix --dry-run um zu sehen, was dort zur Umsetzung vorgeschlagen wird
• Führe es auf einem NEUEN Branch aus, NIEMALS auf „main“

Verwenden Sie eine Überschreibung, wenn Sie einen Grund dafür haben

Mit einem Override kann das Stammprojekt die Art und Weise ändern, wie npm eine Abhängigkeit auflöst, und so ein anfälliges transitives Paket auf eine gepatchte Version festlegen, ohne das übergeordnete Paket zu aktualisieren. In package.json:

{
  "overrides": {
    "rollup": "4.59.0"
  }
}

ausführen. npm install, dann npm audit noch einmal. Dann führe Folgendes aus: npm ls rollup und es auch wirklich zu lesen, denn eine Überschreibung gibt genau die Auflösung an, die man möchte, während npm ls zeigt die Version an, die du erhalten hast, und kennzeichnet sie als „überschrieben“, sobald die Anweisung ausgeführt wurde. Im Hintergrund teilst du npm damit mit: „Egal was passiert, keine Ausreden – installiere diese Version.“, ganz gleich, was die Eltern verlangt haben. Nehmt das mit einem Körnchen Salz.

Überschreibungen sind sinnvoll, wenn Sie die Version veröffentlichen müssen, eine gepatchte Version vorliegt und Sie den Build getestet und sichergestellt haben, dass nichts kaputt gegangen ist. Sie sollten dennoch nur vorübergehend sein. Sie unterdrücken die Warnung, ohne die technische Schuld zu beseitigen, da Sie eine Version ausführen, die im Vergleich zu den Erwartungen des restlichen Code-Baums ungetestet ist. Wenn ein kompatibler Patch vorhanden ist, solltest du diesen Weg einschlagen. Sobald die übergeordnete Version die gepatchte Version unterstützt, lösche die Überschreibung. Überschreibungen sind der Ausweg, nicht der Plan. DAS ist der Vorbehalt.

Warum das bei großem Umfang anstrengend wird

All das ist bei einer einzigen Sicherheitslücke in einem Projekt noch überschaubar. Bei achtzehn Diensten, von denen drei auf einer Framework-Version basieren, deren Lebensdauer vor zwei Jahren abgelaufen ist, ist dies jedoch nicht mehr zu bewältigen. Die Kluft zwischen „Es gibt einen Patch“ und „Wir können ihn sicher einsetzen“ ist der Punkt, an dem das Schwachstellenmanagement kostspielig wird.

Genau dieses Problem löst SecureChain. Anstatt auf jede einzelne CVE nacheinander zu reagieren, umgibt SecureChain Ihre Lieferkette mit einer proaktiven Schutzschicht – sozusagen einer Schutzhülle: Die Pakete werden als verifizierte, signierte Builds aus geprüften Quellen über ein von TuxCare verwaltetes Register bereitgestellt und kontinuierlich auf neue Schwachstellen gepatcht, anstatt dass Sie jedes Mal, wenn eine Sicherheitswarnung veröffentlicht wird, wie bei „Whack-a-Mole“ gegen öffentliche Register vorgehen müssen.

Das hat zwei Seiten:

• Schutz vor dem Ende der Lebensdauer (EOL): Bei aktiv gepflegten Komponenten wenden die Entwickler vorgelagerte Korrekturen an oder erstellen direkt maßgeschneiderte Patches, die sowohl direkte als auch transitive Abhängigkeiten abdecken.
• Schutz nach Ablauf der Produktlebensdauer (EOL): Sobald der Support durch den Hersteller endet, sorgt der „Endless Lifecycle Support“ (ELS) dafür, dass CVE-Patches für ältere Software weiterhin bereitgestellt werden, sodass ein Hersteller, der eine Version nicht mehr unterstützt, kein Notfall-Upgrade erzwingt.

Der zweite Punkt ist wichtiger, als es zunächst klingt, denn die transitive Abhängigkeit, die Ihre Überprüfung zum Scheitern bringt, ist in der Regel jene, die von niemandem im Upstream mehr gepflegt wird. SecureChain veröffentlicht zudem maschinenlesbare VEX-Dokumente, aus denen hervorgeht, welche bekannten CVEs bestimmte Paketversionen betreffen – und genau darin liegt der Unterschied zwischen einer Liste von Sicherheitshinweisen und einer konkreten Lösung.

Das Fazit

Wenn Sie eine CVE-Nummer sehen, brauchen Sie nicht in Panik zu geraten. Es handelt sich um eine Identifikationsnummer, an die sich eine Dokumentenkette knüpft – und diese Kette ist heute kürzer als früher, was ein Grund dafür ist, sie umso sorgfältiger zu lesen, statt sie zu überfliegen.

Entschlüsseln Sie die ID. Prüfen Sie, wer die Bewertung vorgenommen hat und nach welcher CVSS-Version, und achten Sie darauf, welche Felder fehlen. Verwenden Sie CWE für die Schwachstellenklasse, CVSS für den technischen Schweregrad und CPE oder Herstellerdaten, um festzustellen, ob Sie in den Anwendungsbereich fallen. Verfolgen Sie dann die Schwachstelle durch Ihre Struktur und wählen Sie die Lösung mit den geringsten Beeinträchtigungen, die Sie zu einer gepatchten Version führt. Die Zahl ist der einfache Teil. Das, was dahintersteckt, in eine besonnene, überprüfbare und vertretbare Entscheidung umzuwandeln, ist der nützliche Teil.

Zusammenfassung

Artikel Name

Wie man einen CVE liest, ohne in Panik zu geraten

Beschreibung

Eine CVE-ID ist ein Nachschlagsschlüssel, keine Bewertung. Entschlüsseln Sie CWE, CVSS und CPE und verfolgen Sie die Schwachstelle anschließend durch Ihren Abhängigkeitsbaum zurück.

Autor

Chris DeMars

Name des Herausgebers

TuxCare

Logo des Herausgebers