Betroffene Einrichtungen
Bereich
Ein Angreifer nutzte ein kompromittiertes npm-Publish-Token, um zwischen dem 11. Mai 2025 20:19 UTC und 22:56 UTC insgesamt 18 bösartige Versionen (0.1.2 bis 0.1.19) des NestJS-Authentifizierungsmoduls @beproduct/nestjs-auth zu veröffentlichen, die über ein Postinstall-Skript aktiv Credentials aus der Entwicklungs- und Build-Umgebung ausleiten. Konkret wurden npm-Tokens, GitHub Personal Access Tokens, AWS-Zugangsdaten sowie HashiCorp Vault Tokens und weitere Umgebungsvariablen exfiltriert. Sofern dieses Paket in Klinikumgebungen zur Absicherung von NestJS-basierten Backend-Diensten – etwa für Authentifizierung gegenüber klinischen Informationssystemen oder Cloud-Schnittstellen – eingesetzt wird, besteht das Risiko einer vollständigen Kompromittierung der zugehörigen Cloud- und Infrastruktur-Zugänge, was im schlimmsten Fall den Zugriff auf Patientendaten oder kritische Systeme ermöglicht. Angesichts des maximalen CVSS-Scores von 10.0 und der aktiven Ausnutzung ist unverzügliches Handeln – Deinstallation, Secrets-Rotation und forensische Analyse – zwingend erforderlich.
1 Alle Versionen 0.1.2 bis 0.1.19 von @beproduct/nestjs-auth sofort deinstallieren und auf eine sichere, nicht kompromittierte Version außerhalb dieses Bereichs aktualisieren bzw. das Paket bis zur Klärung vollständig entfernen.
2. Sofortige Rotation aller potenziell kompromittierten Secrets: npm-Tokens (aus ~/.npmrc), GitHub Personal Access Tokens (inkl. gho_*-OAuth-Tokens), AWS-Zugangsdaten (Umgebungsvariablen und ~/.aws/credentials) sowie HashiCorp Vault Tokens auf allen betroffenen Systemen.
3. Audit der CI/CD-Pipelines und Build-Umgebungen auf Spuren des Postinstall-Payloads; Logs auf ungewöhnliche ausgehende Netzwerkverbindungen im Zeitraum 2025-05-11 20:19–22:56 UTC prüfen und ggf. forensische Analyse einleiten.
4. Überprüfung aller NestJS-basierten Backend-Dienste im Klinikumfeld auf Einsatz des betroffenen Pakets; Package-Lock-Dateien und node_modules aller relevanten Projekte sichten und ggf. vollständig neu aufbauen.
5. Für zukünftige npm-Abhängigkeiten Supply-Chain-Kontrollen einführen: Subresource-Integrity-Prüfungen, private Registry mit Allowlisting sowie Zwei-Faktor-Authentifizierung für alle npm-Publish-Tokens erzwingen.
NIS2-Relevanz: ••• B3S: ••• ISG: ••ˆ Meldepflicht DE: ja