Provenance ist kein Beweis: Was vor dem `npm install -g` eines Tunnel CLI zu prüfen ist

Im November 2026 gelten zwei Dinge. npm 12 verweigert jetzt standardmäßig das Ausführen von Abhängigkeits-Installationsskripten, wodurch der häufigste Lieferketten-Lieferpfad geschlossen wird. Und im gleichen Jahr haben Angreifer schädliche npm-Veröffentlichungen ausgeliefert, die gültige Provenance-Bestätigungen trugen, sowie Payloads, die überhaupt kein Installationsskript berühren.

Wenn Sie kurz davor stehen, npm install -g auf einem Tunnel-Client auszuführen, zählen beide Fakten. Ein Tunnel-CLI ist ein lang laufender Prozess, der ein Authentifizierungstoken hält, die Umgebungsvariablen Ihrer Shell übernimmt und den Traffic zwischen dem öffentlichen Internet und Ihrem localhost weiterleitet. Dieser Leitfaden erklärt, was sich mit npm 12 ändert, was Provenance beweist und nicht beweist, und eine Vor-Installations-Checkliste: Versions-Pinning, ignore-scripts, prüf­summenverifizierte eigenständige Binärdateien und Ausgehenden-Verkehr-Whitelist.

Warum ein Tunnel-Client ein lohnendes Ziel ist

Ein Tunnel-Client läuft über Stunden oder Tage, mit den Privilegien Ihres Benutzers, auf der Maschine, auf der Ihr Code, Ihre Schlüssel und .env-Dateien liegen, und auf einem Netzwerkpfad, auf dem eine manipulierte Kopie alles lesen kann, was er weiterleitet. PALO Alto Networks’ Zusammenfassung des gehackten @bitwarden/cli-Release listet die Ziele: SSH-Keys, .npmrc Token, .env-Dateien, AWS-Zugangsdaten, Git-Konfigurationen, GitHub CLI Tokens, npm-Auth-Tokens und AI/MCP-Konfigurationen. Das eigene Authentifikations-Token eines Tunnel-Clients würde natürlich neben diesen liegen, und ein Prozess mit Outbound-Verbindung ist gut positioniert, um es irgendwohin zu senden.

Was npm 12 geändert hat, und was nicht

GitHub kündigte npm 12 im Juli 2026 an, wobei allowScripts standardmäßig ausgeschaltet ist. Laut Berichterstattung von The Hacker News werden preinstall, install und postinstall-Skripte aus Abhängigkeiten sowie implizite node-gyp-Builds nicht mehr ausgeführt, es sei denn, sie werden explizit erlaubt. Git-Abhängigkeiten und Remote-URL-Tarballs sind ebenfalls aus, es sei denn, Sie stimmen mit --allow-git oder --allow-remote zu. Das Changelog von GitHub zu den Breaking Changes datiert auf den 9. Juni 2026.

Drei praktische Folgen für Tunnel-CLIs:

• Wrapper-Pakete, die zur Installationszeit eine Binärdatei herunterladen, werden damit aufhören. Der Node.js-Wrapper für ngrok dokumentiert, dass npm install die plattformspezifische Binary während seines postinstall-Schritts von ngrok-hosting bezieht. Unter npm 12 wird dieser Download blockiert, bis Sie ihn genehmigen. Das ist eine Funktion: Sie müssen entscheiden, ob Sie diesem Download-Pfad vertrauen.
• Globale Installationen benötigen ein Flag, nicht eine Allowlist. Berichte im npm CLI-Tracker zeigen, dass bei npm install -g die Warnung auf npm install -g --allow-scripts=<pkg> verweist oder npm config set allow-scripts=<pkg> --location=user, um es dauerhaft zu speichern. Ein Community-Beitrag bemerkt zudem, dass npm approve-scripts bei globalen Installationen Fehler wirft, eine bekannte Lücke.
• Ältere npm-Versionen benötigen weiterhin ignore-scripts. Der PR, der die Standardeinstellung geändert hat, lässt ignore-scripts=true als Fallback für ältere Versionen bestehen. Behalten Sie es in Ihrer Konfiguration, bis jedes Maschine in Ihrem Fleet npm 12 ausführt.

Die Lücke: Payloads, die laufen, wenn der Code läuft

Das Blockieren von Install-Skripten nützt nichts gegen Code, der beim Verwenden des Pakets ausgeführt wird. Microsofts Juli-2026-Analyse zum AsyncAPI-Verstoß fand eine Payload, die beim Modul-Ladezeitpunkt ausgelöst wurde, und besagte, dass --ignore-scripts dieses Muster nicht neutralisiert. Berichte zum Vorfall besagen, dass vier @asyncapi-Pakete mit Trojanern versehen waren, darunter @asyncapi/specs, das ca. 2,66 Mio. wöchentliche Downloads hat.

Der Bitwarden-CLI-Fall zeigt denselben Blindspot aus einer anderen Perspektive. Die schädliche Veröffentlichung 2026.4.0, veröffentlicht am 22. April 2026, hat sowohl einen preinstall-Hook als auch den Binärübungs-Einstiegspunkt von bw auf ein Loader-Skript umgeleitet. Eine OpenReplay-Analyse verweist darauf, dass der bin-Eintrag dafür sorgte, dass der Payload weiterhin lief, sobald jemand den Befehl aufrief, selbst mit gesetztem --ignore-scripts.

Wenden Sie das auf einen globalen CLI an. Man installiert ihn genau, damit man ihn ausführen kann. Für einen Tunnel-Client ist die Grenze zwischen “installiert” und “ausgeführt” nur ein Befehl lang, daher bringt Script-Blocking weniger Nutzen als bei einem Front-End-Abhängigkeitsbaum. Es ist dennoch sinnvoll, es zu haben. Es ist jedoch nicht ausreichend.

Provenance: was es beweist und was nicht

npm-Provenance verlinkt ein veröffentlichtes Paket mit dem Quell-Repository und Build-Anweisungen, die es erzeugt haben. Die offizielle Dokumentation von npm ist eindeutig darüber, dass Provenance nicht garantiert, dass kein schädlicher Code enthalten ist. Sie liefert Ihnen einen überprüfbaren Nachweis zur Auditierung, keine endgültige Beurteilung.

2026 lieferte drei klare Demonstrationen.

Datum	Vorfall	Was gültige Provenance trägt
11. Mai 2026	TanStack-Wurm: 84 bösartige Versionen über 42 @tanstack/*-Pakete	Veröffentlicht aus der echten Vertriebs-Pipeline, nachdem ein OIDC-Token gestohlen wurde
9. Sept. 2026	GHAPPIER: @dforge-core/dforge-mcp@0.2.21	Von GitHub Actions via OIDC vertrauenswürdiger Veröffentlichung gebaut; die Bestätigung benennt den Angreifer-Commit
Okt. 2026	“Slugfest”-Veröffentlichung: 1.500+ Pakete exponiert	Eine Veröffentlichung aus einem Repo, das einen vernachlässigten Namen beanspruchte, trug ebenfalls eine gültige Attestation

Zur TanStack-Vorfall beschreibt Pal o Alto’s Unit 42, es sei der erste dokumentierte Wurm, der bösartige Pakete mit gültiger SLSA Build Level 3-Provenance veröffentlicht, und fasst das Problem so zusammen: Provenance bestätigt, welche Pipeline ein Paket gebaut hat, nicht, ob diese Pipeline sauber war. Die Analyse ergänzt, dass die Bindung des Trusted-Publisher das gesamte Repository umfasste, statt nur einen Workflow auf einem geschützten Branch.

GHAPPIER macht denselben Punkt durch eine andere Tür deutlich. CloudSEK berichtet, dass ein Angreifer die Berechtigungen eines Maintainers knapp 105 Minuten lang nutzte, den Release-Workflow so bearbeitete, dass Pushes automatisch veröffentlicht wurden, und Version 0.2.21 lieferte, die etwa 35 Minuten lang die neueste Version blieb. Da das Registry die CI-Identität des Repos vertraute, hätte die Veröffentlichung npm audit signatures bestanden.

Bloom Securitys Slugfest-Forschung fand heraus, dass jeder, der einen GitHub-Repository-Namen registrierte, den ein Maintainer aufgegeben hatte, immer noch Pakete veröffentlichen konnte, denen vertraut wurde. GitHub sagt, dass Fixes ausgeliefert wurden, und unverifizierte Konfigurationen laufen nun nach 48 Stunden ab. Blooms Rat an Verbraucher: Prüfen Sie, ob die Attestation das Repository benennt, von dem das Projekt stammen soll.

Fehlende Provenance ist immer noch ein Signal

Nichts davon macht Provenance nutzlos. Berichte zum axios-Sicherheitsvorfall vom 31. März 2026 vermerken, dass die schädlichen Veröffentlichungen nicht dieselbe GitHub Actions-Provenance hatten wie die legitimen Veröffentlichungen, was ein zentrales Erkennungs-Signal war. Eine Sicherheitsanalyse von Mondoo fügt eine verwandte Warnung hinzu: Nichts hindert Sie daran, eine Version zu installieren, der Provenance fehlt. Die Regel lautet daher: Eine fehlende oder nicht übereinstimmende Attestation ist ein Grund zum Abbruch; eine gültige Attestation ist ein Grund, weiter zu prüfen.

Die Vor-Installations-Checkliste

1. Identität bestätigen und eine genaue Version pinnen

Prüfen Sie den Paketnamen, den Geltungsbereich und die Version anhand der Dokumentation des Anbieters. JFrog-Analysen zeigen, dass die entführte Bitwarden-Version, 2026.4.0, in der echten Veröffentlichungs-Historie nicht existiert, obwohl legitime Metadaten vorhanden waren. Pins setzen Sie dann auf genau das, was Sie überprüft haben, statt @latest zu installieren:

npm install -g some-tunnel-cli@1.2.3

3. Eine Release-Age-Gate hinzufügen

npm 11.10 (Februar 2026) fügte min-release-age hinzu, gemessen in Tagen. Schädliche Versionen werden oft innerhalb von Stunden erkannt und zurückgezogen. GHAPPIERs fehlerhafte Veröffentlichung war etwa 35 Minuten lang aktuell, und das Bitwarden-Fenster wurde auf ungefähr eineinhalb Stunden angegeben. Eine sieben-Tage-Gate hätte beide übersprungen.

# ~/.npmrc
min-release-age=7
ignore-scripts=true

Zwei von Nutzern dokumentierte Unregelmäßigkeiten: npm config get min-release-age kann null ausgeben, weil npm es intern in einen before-Zeitstempel umwandelt, und man kann es nicht mit --before kombinieren. Um einen kritischen Hotfix sofort zu installieren, überschreiben Sie pro Befehl mit --min-release-age=0.

4. Das Manifest prüfen, bevor installiert wird

Schauen Sie sich an, was das Paket deklariert, bevor es Ihr System berührt:

npm view some-tunnel-cli@1.2.3 scripts bin dependencies --json
npm pack some-tunnel-cli@1.2.3   # downloads the tarball only
tar -tzf some-tunnel-cli-1.2.3.tgz

Rote Flaggen: irgendwelche preinstall/install/postinstall, die ein reiner CLI keinen Grund zu benötigen hat, ein bin-Eintrag, der auf eine Setup- oder Loader-Datei statt auf den eigentlichen Einstiegspunkt zeigt, und neu hinzugefügte Abhängigkeiten. Beide Signale tauchten im Bitwarden-Manifest auf.

5. In einem temporären Verzeichnis prüfen und Attestationen verifizieren

npm audit signatures prüft Registry-Signaturen und Provenance-Attestationen, funktioniert aber auf installierten Abhängigkeiten in einem Projekt, nicht direkt bei einer globalen Installation. Installieren Sie in einem Scratch-Verzeichnis mit deaktivierten Skripten und prüfen Sie anschließend:

mkdir /tmp/vet  cd /tmp/vet  npm init -y
npm install --ignore-scripts some-tunnel-cli@1.2.3
npm audit signatures

Npm-Dokumentation erfordert npm 9.5.0 oder neuer. Lesen Sie dann die Attestation selbst. Das Registry stellt Attestationen unter registry.npmjs.org/-/npm/v1/attestations/\u003cpackage\u003e@\u003cversion\u003e bereit. Bestätigen Sie, dass das Quell-Repository und der Workflow dem offiziellen Repository des Anbieters entsprechen und dass die Version überhaupt eine Attestation hat, falls frühere Versionen dies hatten.

6. Welche Skripte dürfen laufen?

Unter npm 12 genehmigen Sie nur das, was Sie verstehen. Für ein globales Werkzeug, das wirklich eine Postinstall benötigt:

npm install -g --allow-scripts=some-tunnel-cli some-tunnel-cli@1.2.3

Wenn das Paket nur ein Skript ist, das einen Binär-Downloader herunterlädt, ist das Ihr Hinweis auf den nächsten Abschnitt.

Bevorzugen Sie checksum-verifizierte eigenständige Binärdateien

Viele Tunnel-Clients werden als einzelne statische Binärdatei ausgeliefert. Die Binärdatei direkt zu installieren entfernt den npm-Abhängigkeitsbaum, den Wrapper-Postinstall-Download und die Angriffsfläche der Import-Zeit in einem Schritt.

Cloudflare veröffentlicht SHA-256-Prüfsummen für jedes cloudflared-Asset in seinen GitHub-Releases. Eine gepinnte, verifizierte Installation sieht so aus:

VERSION=<reviewed-release-tag>
curl -fsSLO "https://github.com/cloudflare/cloudflared/releases/download/${VERSION}/cloudflared-linux-amd64"
echo "<sha256-you-recorded-at-review-time>  cloudflared-linux-amd64" | sha256sum -c -
install -m 0755 cloudflared-linux-amd64 /usr/local/bin/cloudflared

Seien Sie ehrlich darüber, was dies beweist. Eine Prüfsumme, die von derselben Release-Seite wie die Binärdatei stammt, schützt vor Beschädigung und vor einem manipulierten Download-Pfad, nicht vor einer kompromittierten Veröffentlichung. Notieren Sie den Hash in Ihrem eigenen Repository oder in Ihrer Infrastruktur, wenn ein Mensch die Veröffentlichung prüft, und lassen Sie Ihr Bereitstellungs-Skript dagegen vergleichen.

Wenn ein Projekt GitHub-Artifakt-Attestationen veröffentlicht, fügen Sie gh attestation verify ./some-binary --repo owner/repo hinzu. Die gh-CLI muss auch für öffentliche Repositories authentifiziert sein; einige Installer überspringen die Verifikation, wenn eine Veröffentlichung keine Attestation hat (Foundry-Dokumentation besagt, dass sein Installer dies tut). Stellen Sie also sicher, dass Ihr eigenes Skript fehlschlägt. Diese Attestationen teilen das Limit der npm-Provenance: Sie identifizieren den Build, nicht die Absicht des Autors.

Ausgangsverkehr absichern

Ein Tunnel-Client benötigt sehr wenig ausgehenden Zugriff. Die meisten bösartigen Payloads benötigen mehr: irgendwohin, um gestohlene Dateien zu senden, und manchmal, um eine zweite Stufe abzurufen. Der Bitwarden Loader lud die Bun-Laufzeit von GitHub herunter, und sein Exfiltrations-Endpunkt war so gestaltet, dass er einem Sicherheitsanbieter- telemetrie ähnelte.

Dokumentierte Anforderungen für zwei beliebte Clients:

• cloudflared verbindet sich ausgehend auf Port 7844, TCP für HTTP/2 oder UDP für QUIC, und öffnet vier ausgehende Verbindungen zu mindestens zwei Cloudflare-Rechenzentren. Die Firewall-Anleitung von Cloudflare listet region1.v2.argotunnel.com und region2.v2.argotunnel.com, ergänzt Hostnamen wie cftunnel.com für SNI-vorbeugende Firewalls, und behandelt Ziele auf Port 443 wie api.cloudflare.com (Updateprüfungen) als optional. Es wird empfohlen, alle Eingänge zu blockieren.
• ngrok-Agenten stellen eine ausgehende TLS-Verbindung auf Port 443 zu connect.ngrok-agent.com her. Die Dokumentation von ngrok besagt, dass sich IP-Adressen rotieren und per Hostname auf die Whitelist gesetzt werden sollten, und dass die *.ngrok-agent.com-Familie aufgrund latenzbasierter Weiterleitung benötigt werden könnte. Sie können auch die Connect-URL white-labeln und ngrok diagnose ausführen, um die Konnektivität zu testen.

Da die Ziele Hostnamen sind, reichen einfache IP-basierte Regeln nicht aus. Verwenden Sie eine FQDN-unterstützende Firewall, einen Proxy oder eine Cilium-ähnliche toFQDNs-Richtlinie und wenden Sie sie auf den Benutzer oder Container an, der den Tunnel ausführt, nicht nur auf den gesamten Host.

Ein Whitelist verengt die Auswirkungszone, beseitigt sie aber nicht: Die Endpunkte des Tunnel-Anbieters bleiben zulässig.

Führen Sie es so aus, als könnte es kompromittiert sein

Gehen Sie davon aus, dass der Client eines Tages der schlechte Release sein könnte, den Sie nicht erkannt haben. Führen Sie ihn als dedizierten Benutzer oder in einem Container ohne Cloud-Credentials, SSH-Schlüssel oder Publish-Tokens, starten Sie ihn aus einer sauberen Umgebung statt einer Shell voller exportierter Secrets, und verwenden Sie ein eng begrenztes Authtoken, das Sie rotieren können. Öffnen Sie nur den Port, den Sie benötigen.

Alles Obige handelt davon, dem Client zu vertrauen. Das Erkennen von Tunneln, die Sie nicht autorisiert haben, ist ein separates Problem, das in unserem früheren Beitrag zur Erkennung von Rogue-Reverse-SSH-Tunneln behandelt wird.

FAQ

Macht npm 12 npm install -g sicher? Nein. Es blockiert standardmäßig Abhängigkeits-Installationsskripte, wodurch ein wichtiger Angriffsweg geschlossen wird. Code, der beim Importieren eines Moduls oder beim Aufruf der CLI ausgeführt wird, bleibt unberührt.

Ist npm-Provenance ausreichend, um ein Paket zu vertrauen? Nein. Provenance zeigt, wo und wie ein Paket gebaut wurde. Mehrere Vorfälle im Jahr 2026 haben schädliche Veröffentlichungen durch legitime Pipelines mit gültigen Attestationen verschickt, daher verifizieren Sie, dass die Attestation mit dem erwarteten Repository übereinstimmt, und kombinieren Sie sie mit Versions-Pinning und Manifest-Review.

Das Fazit

npm 12 hebt die Grundlage an, und Angreifer bewegen sich in Bereiche, die es nicht abdeckt. Behandeln Sie Provenance als eine von mehreren Hinweisen darauf, wo eine Veröffentlichung herkommt, nicht als beantwortende Antwort darauf, ob Sie sie ausführen sollten. Für einen langlebigen, berechtigungsstarken, netzwerkorientierten Tunnel-Client: pinnen Sie eine überprüfte Version, warten Sie die ersten Tage einer Veröffentlichung ab, bevorzugen Sie Hash-verifizierte Binärdateien, und lassen Sie den Prozess nur die Hosts erreichen, die er benötigt.

Quellen

• npm 12 Deaktiviert Install-Skripte standardmäßig, The Hacker News (Jul 2026)
• Upcoming breaking changes for npm v12, GitHub Changelog (Jun 9, 2026)
• npm CLI PR #9424: block unreviewed install scripts by default (v12)
• npm CLI issue #9797: global install allow-scripts warning
• npm approve-scripts vs allow-scripts, DEV Community
• Unpacking the AsyncAPI npm supply chain compromise and import-time payload delivery, Microsoft Security Blog
• AsyncAPI npm Attack: Import-Time Malware Defense Guide, Digital Applied
• TeamPCP Campaign Spreads to npm via a Hijacked Bitwarden CLI, JFrog
• Bitwarden CLI Impersonation Attack, Palo Alto Networks
• A Simple Defense Against npm Supply Chain Attacks, OpenReplay
• The npm Threat Landscape: Attack Surface and Mitigations, Unit 42
• Why npm Provenance Didn’t Stop the TanStack Compromise, AppSec Santa
• Attackers Abuse npm Trusted Publishing in GHAPPIER Campaign, Infosecurity Magazine
• npm Trusted Publishing flaw exposed 1,500+ npm packages to takeover, Help Net Security
• Your node_modules Is an Attack Surface: npm Security Checklist for 2026, DEV Community
• npm Supply Chain Security in 2026, Mondoo
• Generating provenance statements, npm Docs
• Viewing package provenance, npm Docs
• npm audit, npm Docs
• Configuring minimum release age across npm, pnpm, and yarn (gist)
• ngrok Node.js wrapper README
• cloudflared releases, GitHub
• Tunnel with firewall, Cloudflare Docs
• Cloudflare Tunnel configuration, Cloudflare Docs
• ngrok network egress, ngrok Docs
• ngrok custom connect URL, ngrok Docs
• Use artifact attestations, GitHub Docs
• Verifying releases, Foundry docs
• Integrity verification, Qlty docs