Schädliches Paket installiert: Ausführung eindämmen, bevor Zugangsdaten ersetzt werden

Ziel

Stand: 25. Oktober 2026. Die Ausführung schädlicher Pakete eindämmen und die Sicherheit der Identitäten und Artefakte wiederherstellen, die davon betroffen sein könnten. Dieses vorgeschlagene Verfahren stützt sich auf die Dokumentation zur Vorfallsreaktion von GitHub und npm, die am 8. Oktober veröffentlichte Tensorlake-Sicherheitsmeldung und den am 21. Oktober, 22:01:01 UTC, geänderten OSV-Eintrag zu LiteLLM. Vor dem Handeln paketspezifische Warnungen und überarbeitete Indikatoren erneut prüfen.

Voraussetzungen

Ein sauberer Administrationsrechner; die Befugnis, betroffene Systeme zu isolieren und Releases auszusetzen; Zugriff auf die Verwaltungsfunktionen von Registries, Repositories und Ausstellern von Zugangsdaten; sowie geschützter Speicher für Beweise. Eine verantwortliche Person für den Vorfall benennen und Massnahmen in UTC protokollieren. Verdächtige Dateien mit vertrauenswürdigen Werkzeugen untersuchen, ohne ihre Installations-Hooks, den beim Interpreter-Start ausgeführten Code oder Projektaufgaben auszuführen.

Schritte

1. Ausführung und Verbreitung eindämmen. Betroffene Arbeitsrechner und Runner isolieren, betroffene Jobs abbrechen und Veröffentlichungen aussetzen. Vor der Bereinigung verfügbare Logs, Paketmetadaten, Lock-Dateien, Artefakt-Digests und relevante Dateisystembeweise sichern. Verwaltungsfunktionen ausserhalb der verdächtigen Umgebung verwenden. Keine Ersatzzugangsdaten auf einem noch untersuchten Rechner hinterlegen.
2. Sofort auf destruktive Mechanismen zur dauerhaften Verankerung prüfen. Bei Tensorlake 0.5.144 muss gh-token-monitor deaktiviert werden, bevor GitHub-Tokens widerrufen werden. Die Linux-Anweisung beginnt mit systemctl --user disable --now gh-token-monitor.service, ausgeführt in der Sitzung des betroffenen Benutzers; die plattformspezifische Bereinigung aus der Sicherheitsmeldung vollständig durchführen. Falls sich die Eindämmung nicht sicherstellen lässt, den betroffenen Rechner anhalten und vor weiteren Schritten seine Datenträger offline untersuchen. Bei LiteLLM 1.107.0 kann bereits der Python-Start die schädlichen Dateien ausführen: Zur Untersuchung dieser Umgebung weder Python noch pip starten.
3. Gefährdete Zugangsdaten vom sauberen Rechner aus widerrufen. Veröffentlichungsrechte und Schreibzugriffe auf Repositories priorisieren, anschliessend alle weiteren erreichbaren Geheimnisse und Sitzungen beim jeweiligen Aussteller berücksichtigen. Für npm npm token list ausführen, die betroffene Token-ID ermitteln und npm token delete TOKEN_ID verwenden; dabei den Platzhalter durch diese ID ersetzen. Die Tokens erneut auflisten. npm dokumentiert eine mögliche Verzögerung beim Widerruf; deshalb die Eindämmung aufrechterhalten, während der Status beim Aussteller geprüft wird. Ersatzdaten nur an wiederhergestellte Nutzer oder Systeme ausgeben.
4. Den gesamten Umfang der Gefährdung erfassen. Jeden betroffenen Rechner, Installationszeitpunkt, jede zugängliche Identität und jedes danach erzeugte Artefakt dokumentieren. Der GitHub-Leitfaden zur Vorfallsreaktion empfiehlt, betroffene Workflows und Zugangsdaten zu erfassen und bei neuen Erkenntnissen die Eindämmung erneut zu prüfen. CI- und Registry-Caches als mögliche Quellen späterer Neuinstallationen untersuchen.
5. Zugriffe und dauerhafte Verankerungen prüfen. Workflow-Änderungen, Release-Freigaben, neue Runner und unbekannte ausführbare Dateien prüfen. GitHubs Hinweise zur Kontosicherheit verlangen ausserdem eine Prüfung von Deploy-Schlüsseln, SSH-Schlüsseln, App-Autorisierungen, Webhooks, Mitwirkenden und jüngsten Commits. Befunde mit dem freigegebenen Zustand vor dem Vorfall vergleichen. Releases prüfen, die mit gefährdeten Veröffentlichungsidentitäten erstellt wurden, und das Zurückziehen nachweislich schädlicher Artefakte mit der Registry abstimmen.
6. Neu aufbauen und überprüfen. Betroffene Umgebungen mit vertrauenswürdigen Images, geprüftem Quellcode und freigegebenen Abhängigkeiten ersetzen; verdächtige Caches oder ausführbare Dateien nicht wiederverwenden. Identitäten der Ersatzartefakte dokumentieren und die Anwendung testen. Den Widerruf von Zugangsdaten und die Autorisierung von Zugriffen bestätigen, dann den Betrieb schrittweise wiederaufnehmen und dabei Repository-, Veröffentlichungs-, Cloud-Zugriffs- und Endgeräte-Logs überwachen.

Erwartetes Ergebnis

Die Vorfallsdokumentation ordnet jeder gefährdeten Identität und jedem betroffenen Artefakt eine Eindämmungsmassnahme und eine Wiederherstellungsprüfung zu. Veröffentlichungen werden aus einer freigegebenen Umgebung mit auf den nötigen Umfang beschränkten Zugangsdaten wiederaufgenommen. Eine verantwortliche Person bleibt für die Prüfung späterer verdächtiger Aktivitäten und ungeklärter Gefährdungen zuständig.

Grenzen und Prüfbasis

Dies ist ein quellenbasierter Vorschlag zur Vorfallsreaktion, keine erprobte Wiederherstellungsübung. Fehlende Indikatoren können nicht beweisen, dass weder Diebstahl noch weitere Codeausführung stattgefunden haben. Das Entfernen eines Pakets allein kann die Vertrauenswürdigkeit nicht wiederherstellen. Vorsichtsmassnahmen gegen destruktive Verankerungsmechanismen sind vorfallspezifisch; die aktuellen Herstelleranweisungen befolgen und gleichzeitig dringende Eindämmungsmassnahmen über saubere Verwaltungszugänge fortsetzen.