Node. js zählt zu den weltweit beliebtesten JavaScript-Runtime-Umgebungen und wird sowohl von Einzelentwicklern als auch großen Unternehmen wie Netflix, LinkedIn, Uber oder PayPal verwendet. Die stetige Weiterentwicklung und der offene Charakter des Projekts verlangen eine zuverlässige und sichere CI/CD-Pipeline, die automatisierte Tests, Code-Integration und Auslieferung gewährleistet. Doch wie eine tiefgreifende Sicherheitsuntersuchung im Jahr 2025 zeigte, kann gerade die komplexe Verzahnung verschiedener DevOps-Plattformen wie GitHub, GitHub Actions und Jenkins zu kritischen Sicherheitslücken führen, die Angreifern ermöglichen, durch manipulierte Pull Requests in interne Testinfrastrukturen einzudringen und potenziell unbemerkt Schadcode in den Produktions-Workflow einzuschleusen. Die daraus entstehende Gefahr einer Supply-Chain-Attacke betrifft nicht nur Node. js selbst, sondern auch alle Softwareprojekte und Unternehmen, die Node. js als Basis verwenden oder davon abhängig sind.
Die untersuchte CI/CD-Umgebung von Node. js setzt auf ein sogenanntes Triplet-Modell: eine maßgeschneiderte GitHub-App, die hauptsächlich PR-Labels verwaltet, GitHub Actions Workflows, die Tests steuern und bei Bedarf Jenkins-Pipelines anstoßen, sowie die Jenkins-Systeme selbst, welche das Bauen, Testen und schlussendlich das Mergen der Änderungen überwachen. Dieses Zusammenspiel gewährleistet zwar eine effiziente Automation, bringt jedoch Sicherheitsherausforderungen mit sich, da mehrere unterschiedliche Systeme miteinander kommunizieren und sich gegenseitig Vertrauen schenken müssen. Im Kern der Sicherheitslücke steht der Umstand, dass GitHub Actions basierend auf Labels wie „needs-ci“ und „request-ci“ festlegen, welche Pull Requests (PRs) geprüft und welche Jenkins-Pipelines gestartet werden dürfen.
Die Absicht dahinter ist, dass Code erst dann getestet wird, wenn er von Maintainerinnen oder Maintainers überprüft und freigegeben wurde, sodass keine unbewerteten Änderungen ungeprüft in den Build gelangen. Dabei spielt die sogenannte Zeitstempelüberprüfung eine entscheidende Rolle: Das System überprüft, ob der letzte Commit vor dem Setzen des Labels stattgefunden hat, was sicherstellen soll, dass nach der Freigabe keine weiteren Änderungen eingepflegt wurden. Die Analyse offenbarte jedoch, dass diese Zeitstempelüberprüfung unzureichend umgesetzt wurde. Git-Commit-Timestamps lassen sich lokal manipulieren, indem man Umgebungsvariablen setzt, die das Datum des Commits auf einen Zeitpunkt vor dem „request-ci“-Label zurückdatieren. Da GitHub die Commit-Daten vom Client übernimmt und nicht serverseitig validiert, ist diese Anpassung technisch möglich.
Dadurch wird die kritische Prüfung unterlaufen: Ein Angreifer kann zunächst legitimen und von Maintainerinnen freigegebenen Code in den Pull Request einfügen, anschließend jedoch innerhalb des engen Zeitfensters nach der Freigabe einen zusätzlichen Commit mit manipuliertem Zeitstempel einreichen. Dieser neue Commit entfaltet seine Wirkung in den Jenkins-Pipelines, die nach dem Label-Setzen ausgelöst werden und den Code ausführen. Über die entwickelte Payload konnten Sicherheitsforscher remote Code auf internen Testagenten des Node. js-Projekts ausführen. Die Angreiferin oder der Angreifer baute hierbei ein Skript ein, das eine selbstständige GitHub-Runner-Instanz auf den Jenkins-Agenten installierte und so eine dauerhafte Zugriffsmöglichkeit schuf – ohne dass der reguläre Build-Prozess gestört wurde.
Zudem nutzten einzelne Systeme Jenkins-Builds mehrfach, was eine weitere Eskalation erlaubte, beispielsweise das Stehlen von Jenkins-Zugangsdaten und potenzielle laterale Bewegungen innerhalb des Netzwerks. Damit nicht genug, wurde über das sogenannte „commit-queue“-Label noch eine weitere Schwachstelle entlarvt, die ähnlich aufgebaut und sogar noch weitreichender gewesen wäre. Dieser Prozess führt PRs vollautomatisch in den Hauptzweig (main) der Codebasis zusammen, sobald Tests bestanden sind und Maintainer zustimmen. Die gleiche Manipulation der Commit-Zeitstempel hätte es einem Angreifer erlaubt, Schadcode in den Haupt-Branch einzuschleusen, was eine langfristige Supply-Chain-Komponente bedeutet. Somit würden alle Nutzerinnen und Nutzer zukünftiger Node. js-Versionen unwissentlich kompromittierte Software erhalten - ein Szenario, das für die gesamte Software-Lieferkette katastrophale Folgen haben könnte. Die zeitnahe Meldung dieser Schwachstellen an das Node.
js-Sicherheitsteam führte zu einem schnellen und konsequenten Reaktionsprozess. Innerhalb weniger Tage wurden das Einreichen neuer Jenkins-Jobs vorübergehend gestoppt, um potenzielle Angriffe zu unterbinden. Die Jenkins-Infrastruktur wurde vollständig neu aufgebaut, potenziell kompromittierte Systeme bereinigt und ein Ausgleichsupdate für die verwendeten „node-core-utils“ (NCU-CI) implementiert. Die vorherigen Zeitstempelchecks wurden zugunsten einer Validierung mittels genehmigter Commit-SHAs ausgetauscht, was Manipulationen effektiv ausschließt. Die betreffende Änderung wurde Anfang April 2025 in die Codebasis integriert, und umgehend wurde ein Retest durchgeführt, der bestätigte, dass die Lücke geschlossen ist. Die fundierte und transparente Offenlegung durch Node. js verdient Anerkennung.
Die Organisation führte umfangreiche Audits in mehr als 140 Jenkins-Jobs durch, fokussierte sich auf häufig genutzte Pipelines und zeigte deutlich, dass Sicherheit in Open-Source-Projekten auch in komplexen Build-Umgebungen oberste Priorität haben muss. Dieses Ereignis offenbart jedoch einen gefährlichen Trend: Die zunehmende Komplexität von DevOps-Workflows mit mehreren, teils externen Systemen kann neue Angriffsvektoren eröffnen, wenn die Interaktion zwischen Komponenten nicht ganzheitlich betrachtet und abgesichert wird. GitHub Actions, Jenkins und proprietäre Bots müssen in ihrer Zusammenarbeit auf Integrität, Authentizität und zeitliche Konsistenz geprüft werden, um Manipulationen auszuschließen. Explizit erwähnt werden sollte, dass der verantwortliche Forscher bei Praetorian das Szenario unter kontrollierten Bedingungen testete und die möglichen Auswirkungen abwog, um den produktiven Betrieb weder zu gefährden noch unnötigen Schaden zu verursachen.
Ebenfalls bemerkenswert ist die Empfehlung von Node. js an Sicherheitsforscher, vor öffentlichkeitswirksamen Tests stets zuerst Kontakt aufzunehmen, um Koordination und Schutz der Infrastruktur sicherzustellen. Unternehmen und Entwickler sollten aus diesem Fall lernen, wie wichtig ein umfassendes Sicherheitskonzept in CI/CD-Pipelines ist. Die alleinige Kontrolle von Codequalität oder Review-Prozessen reicht nicht aus, wenn zeitbasierte Validierungen über Git-Metadaten unzureichend sind. Stattdessen rücken technische Maßnahmen wie signierte Commits, Genehmigung von bekannten Commit-Hashes oder striktere Berechtigungsmodelle für das Ausführen kritischer Jobs in den Fokus. Kontinuierliches Monitoring der Build-Agenten erlaubt es zudem, ungewöhnliches Verhalten frühzeitig zu erkennen. Darüber hinaus gewinnen Lösungen für Continuous Threat Exposure Management (CTEM) an Bedeutung, welche fortlaufend Angriffsvektoren in DevOps-Prozessen aufdecken können, bevor tatsächlicher Schaden entsteht.
Die Integration solcher Technologien in den Lebenszyklus von Softwareentwicklung kann die unterschiedliche Plattformen umfassende Sicherheitsarchitektur nachhaltig stärken. Abschließend zeigt der Fall Node. js, dass selbst Projekte mit hoher Bekanntheit und großer Nutzerbasis nicht frei von Sicherheitsherausforderungen sind. Die Kombination aus Open-Source-Kollaboration und moderner CI/CD-Infrastruktur verlangt permanente Wachsamkeit, transparente Kommunikation und ein proaktives Sicherheitsmanagement. Nur so lassen sich die mittlerweile komplexen Lieferketten digitaler Infrastruktur gegen raffinierte Angriffe schützen und langfristig Vertrauen und Stabilität gewährleisten.
