Lieferkette in der Praxis: npm vertraute einem Repository-Namen, GitLab stürzt über einen regulären Ausdruck

In der Woche vom 12. Oktober 2026 sind zwei Meldungen erschienen, die auf den ersten Blick nichts miteinander zu tun haben: eine Schwachstelle in der Vertrauensprüfung von npm Trusted Publishing und eine Lücke mit der Höchstwertung CVSS 10.0 im CI/CD-Teil von GitLab. Beide treffen dieselbe Stelle, nämlich das, was eine Pipeline einem Repository glaubt. Dieser Beitrag beruht auf den Quellen unten. Eigene Messungen haben wir dazu nicht gemacht.

npm: der Name blieb frei, das Recht ging mit

Trusted Publishing erlaubt, Pakete ohne gespeichertes Zugangstoken zu veröffentlichen: Die Registry vertraut einem Workflow in einem bestimmten GitHub-Repository. Bloom Security fand, dass npm dieses Repository über den Namen in der Form Besitzer/Repository und den Namen der Workflow-Datei band, nicht über die feste numerische ID, die GitHub vergibt. Wurde ein Repository umbenannt, übertragen oder gelöscht, oder ein Konto umbenannt oder gelöscht, war der alte Name frei. Ein Angreifer legte ihn neu an, fügte eine passende Workflow-Datei hinzu und bekam ein gültiges Veröffentlichungstoken für ein Paket, das ihm nicht gehört. Gestohlene Zugangsdaten brauchte er dafür nicht.

Nach Bloom waren mehr als 1.500 Pakete mit zusammen über 10 Millionen Downloads gefährdet, über eine Million im Monat. Ein Paket kam allein auf mehr als 200.000 monatliche Downloads. Bloom hat die Lücke in einem kontrollierten Test genutzt, um eine neue Version eines bestehenden Pakets zu veröffentlichen, und eine Ausnutzung in freier Wildbahn nicht beobachtet. Die Paketnamen veröffentlicht Bloom nicht.

Zum Zeitverlauf: Bloom meldete die Lücke nach Angabe von Help Net Security am 6. Juni 2026 über das HackerOne-Programm von GitHub, GitHub bestätigte sie am 9. Juni, und Bloom schreibt, mehrere Nachfragen seien danach unbeantwortet geblieben. Am 2. Oktober kündigte GitHub die Korrektur an: Nicht validierte Trusted-Publishing-Konfigurationen laufen 48 Stunden nach dem Anlegen ab und können dann nicht mehr zum Veröffentlichen berechtigen. Eine Konfiguration gilt nach dem ersten erfolgreichen Veröffentlichen als validiert. Außerdem lehnt npm jetzt Token ab, die über issue_comment-Ereignisse in GitHub Actions ausgestellt wurden. CSO Online weist darauf hin, dass der Fix die Gefahr durch nicht validierte Konfigurationen schließt, Maintainer ihre bestehenden Vertrauensbeziehungen aber weiter selbst prüfen müssen. Ob schon vor der Änderung gebundene Konfigurationen rückwirkend geschützt sind, sagt die Quelle nicht.

Bloom gibt an, dass KI-Agenten pro Endgerät und Monat etwa 70 Pakete installieren, auf Entwicklerrechnern rund 350, ohne transitive Abhängigkeiten. Das ist eine Herstellerangabe ohne unabhängige Nachprüfung.

GitLab: eine Zahl läuft über

CVE-2026-97229 ist ein Ganzzahlüberlauf im Compiler für reguläre Ausdrücke im CI/CD-Teil von GitLab, bewertet mit CVSS 10.0. Rapid7 beschreibt die Kette: Ein präparierter Ausdruck besteht die Prüfung, solange er als US-ASCII übersetzt wird. Wird er später gegen einen Repository-Pfad mit UTF-8-Zeichen ausgewertet, übersetzt Rubys Onigmo-Engine ihn neu, und ein Überlauf in der Berechnung der Programmgröße erzeugt ungültige Anweisungen. Daraus wird die Ausführung eines Betriebssystembefehls als Benutzer git. Rapid7 hat die Kette auf GitLab 19.4.1 CE mit aktivem ASLR nachgestellt und festgestellt, dass dieselbe Eingabe auf 19.4.2 nicht ausgeführt wird.

Behoben ist die Lücke in 19.2.8, 19.3.5 und 19.4.2 vom 12. Oktober 2026. Betroffen sind selbst betriebene Instanzen, GitLab.com ist bereits aktualisiert, und Kunden von GitLab Dedicated müssen nichts tun. heise zählt in demselben Release 24 geschlossene Lücken, die Beschreibung stützt sich dort auf sechs, eine davon kritisch.

Zur Einordnung der Einstufung „ohne Anmeldung": Nach Rapid7 muss der Angreifer eine .gitlab-ci.yml in ein Repository legen und einen Pfad mit UTF-8-Zeichen verwenden. Wo normale Konten öffentliche Projekte anlegen dürfen, genügt ein Konto, bei offener Selbstregistrierung entfällt auch das. Rapid7 hat eine Proof-of-Concept auf GitHub veröffentlicht und seinen Beitrag am 16. Oktober aktualisiert. Eine Ausnutzung in freier Wildbahn ist laut Rapid7 nicht bestätigt. Bis zum Update empfiehlt Rapid7, anonymen Zugriff auf öffentliche Projekte zu beschränken und nicht vertrauenswürdigen Benutzern das Anlegen oder Schreiben in öffentlichen Projekten zu untersagen. Das behebe den Fehler nicht, verringere aber die Angriffsfläche.

Wie lange die Korrekturen brauchten

Was beide Fälle gemeinsam haben

In beiden Fällen entscheidet eine Zeichenkette aus dem Repository über das, was eine Pipeline darf. Bei npm ist es der Name, bei GitLab der Ausdruck in der Konfigurationsdatei. In beiden Fällen lag der Fehler in der Plattform und nicht in der Arbeit des Betreibers. Und in beiden Fällen bleibt nach dem Fix eine Aufgabe, die die Plattform dem Betreiber nicht abnimmt: bestehende Bindungen zu prüfen.

Was Betreiber prüfen

1. npm-Maintainer: npm trust list ausführen und prüfen, ob jedes aufgeführte Repository noch zu einem gehört, das man kontrolliert. Bindungen an umbenannte oder übertragene Repositories löschen und neu anlegen. Vor dem Löschen eines Repositories zuerst die Bindung entfernen. Das empfiehlt Bloom.
2. npm-Nutzer: in der Provenance-Angabe eines Pakets prüfen, dass das genannte Repository zum Projekt gehört. Wer Software für Kunden baut, legt außerdem fest, was Entwickler und KI-Agenten installieren dürfen (Empfehlung von Bloom).
3. GitLab-Betreiber: Version prüfen, auf 19.2.8, 19.3.5 oder 19.4.2 aktualisieren und bis dahin das Anlegen öffentlicher Projekte einschränken.
4. Wer eine andere Plattform für Git und CI betreibt, zum Beispiel Gitea, sucht dort nach derselben Klasse: Wo entscheidet eine vom Benutzer gesetzte Zeichenkette über Rechte der Pipeline? Eine Aussage dazu für Gitea ist in den Quellen nicht enthalten.

Was Foren dazu sagen

Wir haben auf Hacker News gesucht und zu beiden Fällen keine Einreichung gefunden (Suche am 16.10.2026). Das GitLab-Thema behandelt noted.lol, ein Blog für selbst betriebene Software, mit einer Zusammenfassung.

So haben wir geprüft

Wir haben am 16. Oktober 2026 die Berichte von Help Net Security und CSO Online zu npm gelesen, den Beitrag von Rapid7 zu GitLab (Stand 16.10.) und den Bericht von heise. Quellen weichen ab: Help Net Security nennt für den npm-Fix den 2. Oktober, ein anderer Bericht datiert die verschärften Regeln von GitHub auf den 13. Oktober. Wir folgen dem Datum 2. Oktober, das CSO Online dem npm-Team zuschreibt und mit dem GitHub-Changelog verknüpft. Auch die betroffenen GitLab-Versionen wurden in den Berichten unterschiedlich angegeben. Rapid7, Help Net Security und heise nennen 19.2.8, 19.3.5 und 19.4.2 als Fixes, das Advisory von GitLab selbst haben wir nicht gelesen.

Weiterführende Quellen

Primärquellen

• GitHub, Unvalidated npm Trusted Publishing configurations now expire, 2.10.2026
• npm, Dokumentation zu Trusted Publishers
• Rapid7, CVE-2026-97229: Critical Unauthenticated Remote Code Execution in GitLab, 13.10.2026, aktualisiert 16.10.2026

Unabhängige Berichte

• Help Net Security, npm Trusted Publishing flaw exposed 1,500+ npm packages to takeover, 13.10.2026
• CSO Online, Over 1,500 npm packages exposed by Trusted Publishing validation flaw, 13.10.2026
• Help Net Security, GitLab admins urged to patch critical RCE flaw, 13.10.2026
• heise online, Sicherheitslücke mit maximalem Schweregrad bedroht GitLab, 13.10.2026

Herstellerangabe

• Bloom Security, SlugFest: millions of AI agents download exposed npm packages

Community

• noted.lol, GitLab Patches Critical Remote Code Execution Flaw, 12.10.2026