PostHog: npm-Installationen ermöglichten für fünf Stunden die verdeckte Exfiltration von Secrets

Unternehmen und Produkt

PostHog ist eine Open-Source Product-Analytics-Plattform mit SDKs für Web- und Mobile-Apps. Die JavaScript-Pakete sind weit verbreitet und werden häufig aktualisiert, was den npm-Footprint nicht nur kritisch, sondern auch hochdynamisch macht. Am 24. November 2025 stand PostHog vor seinem bisher folgenreichsten Security-Incident: eine kurzlebige Kompromittierung mehrerer npm-Releases durch den Supply-Chain-Wurm Shai-Hulud 2.0.

‍

Der Computerwurm betraf neben PostHog, noch viele weitere Unternehmen, darunter Postman und Zapier. Wiz.io veröffentlichte eine Übersicht zu dem Incident.

Was genau ist vorgefallen?

Um 04:11 UTC am 24. Nov wurden bösartige Versionen mehrerer PostHog-JavaScript-Pakete auf npm veröffentlicht. Diese Builds enthielten ein preinstall-Skript, das mit TruffleHog die lokale Umgebung nach Secrets scannte, gefundene Credentials in ein neues öffentliches GitHub-Repository exfiltrierte und gestohlene npm-Tokens nutzte, um weitere bösartige Pakete zu veröffentlichen.  Dadurch konnte sich der Wurm selbst weiterverbreiten. PostHog entfernte die kompromittierten Releases und widerrief die betroffenen Tokens noch am selben Morgen.

Timeline

• Initialer Zugriff (18. Nov, ~17:40 lokal / 15:40 UTC): Ein Angreifer öffnete und schloss schnell einen PR von einem Wegwerf-Account, der ein Skript manipulierte, das von pull_request_target in GitHub Actions ausgeführt wird. Diese Änderung führte zur Ausführung nicht vertrauenswürdiger Codes und exfiltrierte den GitHub-PAT eines Bots aus CI. Mit diesem PAT schrieb der Angreifer später in Repositories und griff auf zusätzliche CI-Secrets zu.
• Rechteausweitung (23. Nov, ~15:28–15:45 UTC): Mit dem gestohlenen PAT löschte der Angreifer einen Workflow-Run (vermutlich ein Validitätstest) und pushte anschließend einen detached commit, der einen Workflow so modifizierte, dass alle GitHub-Secrets gedumpt wurden, unter anderem auch das npm-Publishing-Token von PostHog.
• Bösartige Veröffentlichung (24. Nov, 04:11 UTC): Kompromittierte npm-Versionen gingen live und starteten die Verbreitung des Wurms über preinstall. Erkennung und Eindämmung (24. Nov, bis 09:30 UTC): PostHog identifizierte und entfernte die Pakete, widerrief Credentials und startete eine breite Secret-Rotation.

‍

TTD (Time to Detect): ~5 h 19 min (04:11 → 09:30 UTC).

TTR (Time to initial remediation): ~5 h 19 min bis zum Entfernen der bösartigen Pakete und zum Widerruf der Tokens; weitere Härtungen und Rotationen folgten anschließend.

Wer war betroffen

Nutzerinnen und Nutzer, die bestimmte PostHog-JavaScript-Pakete im Zeitfenster zwischen 04:11 und 09:30 UTC am 24. Nov von npm installiert haben. Nutzer der script-Einbindung (Browser-CDN-Snippet) waren nicht betroffen, da der Wurm auf npm-Lifecycle-Hooks basierte.

Wie PostHog reagierte

Das Team entfernte die trojanisierten Releases von npm, widerrief Publishing-Tokens und rotierte vorsorglich potenziell exponierte Credentials. Anschließend härteten sie ihre Supply-Chain-Kontrollen indem sie auf npm Trusted Publisher wechselten, Review-Anforderungen für jede Änderung an Workflow-Dateien erhöhten, auf pnpm 10 aktualisierten (Install-Skripte deaktiviert und minimumReleaseAge aktiviert) und das GitHub-Secrets-Managements überarbeiteten, um Incident schneller und sicherer zu handhaben.

Wie PostHog kommunizierte

PostHog veröffentlichte zwei Tage später, am 26. November, ein offenes, technisch detailliertes Postmortem. Der Bericht listet betroffene Pakete und Versionen, präzise UTC-Zeitstempel, Containment-Schritte und umsetzbare Guidance für Kundinnen und Kunden (Datei-Indikatoren, npm-Log-Queries, Cache-Bereinigungen und Pinning auf bekannte Good-Versions). Dieses Maß an Spezifik half Downstream-Teams, Exposition schnell zu verifizieren und sich mit minimalem Rätselraten zu erholen.

Wichtige Learnings für andere Teams

• Behandeln Sie pull_request_target als per se gefährlich. Es läuft mit den Privilegien des Ziel-Repos; wenn Ihr Workflow PR-kontrollierten Code auscheckt (direkt oder via Helper-Skripte), entsteht eine RCE-Brücke in CI. Beschränken Sie den Checkout auf sichere Refs, vermeiden Sie die Ausführung von Repo-Skripten für untrusted PRs und verlangen Sie manuelle Approval-Gates für jeden Workflow, der dies tun würde.
• Minimieren und scopen Sie Maschinen-Credentials. Ersetzen Sie breite PATs durch kurzlebige, Least-Privilege-Tokens (z. B. GitHub OIDC → Cloud/Registry-gescopte Credentials; npm Trusted Publisher statt langlebiger Tokens). Ein einzelner hochprivilegierter PAT ermöglichte hier Schreibzugriff und Secret-Exfiltration.
• Härten Sie Package-Konsum-Pfade. Erzwingen Sie eine minimum release age (z. B. 72 Stunden) in Package-Managern, spiegeln und verifizieren Sie Dependencies und deaktivieren Sie Lifecycle-Hooks, wo möglich. Diese Kontrollen bremsen schnell agierende Supply-Chain-Würmer wie Shai-Hulud v2 in großen Ökosystemen aus.
• Instrumentieren Sie CI für schnelle Forensik. Aktivieren Sie umfassende Audit-Logs, bewahren Sie Workflow-Artefakte auf und alarmieren Sie bei Hochrisiko-Events: Force-Pushes, detached commits auf geschützte Branches, Änderungen an Workflow-Dateien, Token-Erstellung/-Nutzung und ungewöhnliche Repo-Erstellungen in Ihrer Organisation. PostHogs Fähigkeit, Angreiferhandlungen zu rekonstruieren, stützte sich stark auf GitHub-Audit-Trails.
• Sichern Sie „Helper“-Skripte. Logik in Repo-Skripte wie assign-reviewers.js auszulagern, ist bequem, aber riskant. Bevorzugen Sie deklarative Workflows oder geprüfte, versions-gepinnte Actions; führen Sie niemals PR-kontrollierten Code in privilegierten Jobs aus.
• Üben Sie Supply-Chain-Incident-Drills. Bereiten Sie Playbooks vor für: Registry-Tokens widerrufen, Versionen „yanken“, Nutzerinnen/Nutzer mit exakten Versionslisten informieren und Secrets massenhaft rotieren. Würmer mit Auto-Publish können sich schnell verstärken. Jede Minute zählt.

Kurzzusammenfassung

Der Incident ging auf einen GitHub-Actions-Workflow mit pull_request_target zurück, der Code aus einem externen Pull Request ausführte und dabei den Personal Access Token eines Bots leakte. Mit diesem Token zog der Angreifer zusätzliche CI-Secrets, darunter npm-Publishing-Credentials, und veröffentlichte bösartige PostHog-Package-Versionen auf npm, die bei Installation ein preinstall-Skript zur Secret-Exfiltration ausführten. Der Impact war auf PostHogs JavaScript-Pakete und ein Zeitfenster von rund fünf Stunden am 24. Nov 2025 begrenzt; Nutzerinnen und Nutzer, die PostHog über das Browser-<script>/CDN-Snippet luden, waren nicht betroffen. PostHog reagierte, indem es die kompromittierten Releases entfernte, Credentials widerrief und rotierte, auf npm Trusted Publisher wechselte, Review-Kontrollen für Workflow-Änderungen verschärfte, auf pnpm 10 mit sichereren Defaults aktualisierte und das Secrets-Management überarbeitete.

Wie ilert helfen kann

Diese Art von Incidents sind wie ein Rennen. Dort hilft ilert hilft, jede Minute zwischen Signal und Aktion zu verkürzen.

‍

• Smart Alerting und On-Call. Leite npm/Advisory-Feeds, GitHub-Audit-Anomalien und Registry-Telemetrie sofort an die richtige Ingenieur*in- mit Eskalationsketten.
• Automatisierungen (ilert Alert Actions). Starte aus jedem Alert One-Click-Aktionen über Ihre Outbound-Integrationen: in Slack oder Microsoft Teams posten, ein Jira-Ticket öffnen/aktualisieren, ein GitHub Issue erstellen, einen Webhook oder AWS Lambda triggern, um npm-Tokens zu deaktivieren oder eine Pipeline zu pausieren, und Ihre Statusseite aktualisieren. Solche Automationen verbessern die Geschwindigkeit der Incident-Behebung enorm.
• Stakeholder-Kommunikation. ilert kann aus dem Alert heraus einen privaten, invite-only War Room erstellen, sodass nur Security, Engineering, Legal und Comms sensible Details sehen. Benachrichtigen Sie zuerst betroffene Kundinnen/Kunden über Ihre angebundenen Kanäle (E-Mail, Slack/Teams, Ticketing) mit klarer Guidance „Was ist passiert / Wer ist betroffen / Was ist jetzt zu tun“. Nach der Eindämmung kann ilert vorab geprüfte, KI-gestützte Statusseiten-Entwürfe generieren, die Versionen und UTC-Timelines automatisch einfügen - für schnelle und präzise Veröffentlichungen
• Postmortems. Mit ilert AI erstellen Sie strukturierte Post-Incident-Dokumente, erfassen Root Causes, Timelines, TTD/TTR und präventive Maßnahmen. So werden mühsam erarbeitete Erkenntnisse in nachhaltige Praxis verwandelt.