Ein Lieferketten-Angriff auf npm-Pakete von Red Hat zeigt erneut, wie verwundbar die Software-Lieferkette ist. Anfang Juni tauchten manipulierte Versionen von 30 Paketen aus dem offiziellen Scope der Red Hat Cloud Services auf. Betroffen sind weit verbreitete Frontend-Bausteine, die in zahllosen Unternehmensanwendungen stecken. Der Fall trifft einen Nerv bei jedem Team, das auf Open-Source-Komponenten baut.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Das Wichtigste in Kürze
- Am 1. Juni 2026 wurden 30 npm-Pakete im Scope
@redhat-cloud-services/mit manipulierten Versionen veröffentlicht. - Betroffen sind unter anderem die weit genutzten Frontend-Components und mehrere Client-Bibliotheken.
- Der Sicherheitsdienstleister StepSecurity meldete den Vorfall und listete die kompromittierten Versionen auf.
- Teams sollten betroffene Versionen sperren und ihre Abhängigkeiten gezielt prüfen.
Die manipulierten Pakete erschienen unter dem echten, offiziellen Namensraum von Red Hat. Genau das macht solche Angriffe so heimtückisch, denn die Entwickler vertrauen einem etablierten Anbieter und ziehen die Aktualisierung ohne Argwohn. Zu den betroffenen Paketen zählen zentrale Bausteine wie @redhat-cloud-services/frontend-components in Version 7.7.2 und mehrere Client-Bibliotheken für Compliance, Inventar und Benachrichtigungen.
Warum sind Supply-Chain-Angriffe so gefährlich?
Moderne Webanwendungen bestehen zu großen Teilen aus fremdem Code. Ein einzelnes Projekt zieht über npm oft hunderte Pakete als Abhängigkeiten nach, und jedes davon kann weitere Pakete mitbringen. Wird ein einziges populäres Paket kompromittiert, verteilt sich der Schadcode automatisch über alle Projekte, die es einbinden. Der Angriff zielt nicht auf eine einzelne Firma, sondern auf die gemeinsame Infrastruktur vieler.
Im konkreten Fall verschärft die Reichweite das Problem. Die Red-Hat-Frontend-Bausteine sind in vielen Enterprise-Oberflächen verbaut, und die Versionsnummern der manipulierten Pakete liegen dicht an den legitimen Releases. Ein Team, das ohne festgepinnte Versionen arbeitet, kann die Schadversion bei der nächsten Installation unbemerkt einziehen.
Die Software-Lieferkette ist heute die größte ungeschützte Flanke vieler Unternehmen. Wer hunderte Pakete blind aktualisiert, lädt sich das Risiko frei Haus ins eigene Haus.
— Michael Dobler, Herausgeber Dr. Web
Was sollten Entwicklerteams jetzt tun?
Der erste Schritt ist eine Bestandsaufnahme. Prüfen Sie, ob eine der gemeldeten Versionen in Ihren Projekten steckt, und sperren Sie diese gezielt. Die vollständige Liste der kompromittierten Pakete und Versionen veröffentlichte Red Hat im offiziellen GitHub-Repository. Wer eine betroffene Version installiert hat, sollte die Abhängigkeit entfernen, auf eine saubere Version zurückgehen und betroffene Systeme auf verdächtige Aktivität untersuchen.
Mittelfristig hilft nur eine diszipliniertere Lieferketten-Hygiene. Pinnen Sie Versionen fest, statt automatisch die neueste zu ziehen, und prüfen Sie neue Releases vor dem Einsatz. Eine Software-Stückliste (SBOM) macht transparent, welche Komponenten überhaupt im Einsatz sind. Automatisierte Prüfwerkzeuge können verdächtige Paketversionen erkennen, bevor sie in die Produktion gelangen.
Für deutsche Unternehmen kommt die Compliance-Dimension hinzu. Das BSI und die NIS2-Richtlinie verlangen zunehmend nachvollziehbare Lieferketten-Sicherheit, und eine SBOM ist hier kein Selbstzweck, sondern wird zur Nachweispflicht. Klären Sie, wer in Ihrem Haus für die Überwachung von Open-Source-Abhängigkeiten zuständig ist, denn ohne klare Verantwortung bleibt diese Flanke offen.
