Supply-Chain-Angriffe: Was xz, npm-Würmer und vergiftete Docker-Images für dein Homelab bedeuten

Kurz gesagt: Bei einem Supply-Chain-Angriff (Lieferketten-Angriff) brechen Täter nicht bei dir ein — sie verstecken Schadcode in Software, die du freiwillig installierst. Das reicht von der xz-Hintertür 2024 über sich selbst verbreitende npm-Würmer 2025 bis zu manipulierten Docker-Images 2026, die stundenweise unter dem offiziellen Namen und sogar unter latest ausgeliefert wurden. Für dein Homelab heißt das: Images auf Versionen pinnen, Updates bewusst statt blind einspielen, Herkunft prüfen, wo es geht — und Zugangsdaten so ablegen, dass ein kompromittierter Container nicht alles verrät.

Warum Open Source so ein lohnendes Ziel ist #

Moderne Software besteht zu großen Teilen aus fremden Bausteinen. Eine Web-App zieht beim Bauen leicht Hunderte Pakete aus Registries wie npm (JavaScript) oder PyPI (Python); ein Docker-Image enthält ein ganzes Mini-Betriebssystem. Jeder dieser Bausteine wird von irgendwem gepflegt — oft von wenigen Freiwilligen.

Das ist die Stärke von Open Source: Jeder kann den Code lesen. Es ist aber auch die Angriffsfläche. Wer das Konto eines einzigen Maintainers (der Person, die Releases veröffentlichen darf) übernimmt, erreicht mit einem Update alle, die dieses Paket nutzen. Der Code im öffentlichen Repository und das, was am Ende als Paket oder Image verteilt wird, müssen außerdem nicht identisch sein — genau diese Lücke haben mehrere der folgenden Angriffe genutzt.

xz-utils 2024: die Hintertür, die fast durchgekommen wäre #

xz ist ein Kompressionsprogramm, das auf praktisch jedem Linux-System liegt. Ende März 2024 meldete die US-Behörde CISA, dass die Versionen 5.6.0 und 5.6.1 von XZ Utils Schadcode enthielten, der unbefugten Zugriff auf betroffene Systeme ermöglichen konnte (CVE-2024-3094), und empfahl die Rückkehr zu einer sauberen Version wie 5.4.6Belegt.

Bemerkenswert ist, wie sie versteckt war und wie sie auffiel. Der Entwickler Andres Freund bemerkte, dass SSH-Anmeldungen auf Testsystemen ungewöhnlich viel Rechenzeit brauchten, und verfolgte das bis in die Bibliothek liblzma. Der Schadcode steckte in den veröffentlichten Release-Archiven, nicht im öffentlichen Quellcode-Repository; im Repository lagen nur unauffällig wirkende Testdateien, die erst ein Skript aus den Release-Archiven beim Bauen auswerteteBelegt. Den SSH-Server erreichte die Hintertür über einen Umweg: Einige Distributionen binden für die Zusammenarbeit mit systemd eine Bibliothek ein, die wiederum liblzma lädt.

Glück im Unglück: Die betroffenen Versionen waren laut Freund im Wesentlichen nur in Vorab- und Testversionen der Distributionen angekommen. Die Lehre bleibt trotzdem: Wer Zugriff auf ein Projekt bekommt und Vertrauen aufbaut, kann Schadcode sehr gut tarnen.

npm-Würmer 2025: Malware, die sich selbst veröffentlicht #

Im September 2025 kam eine neue Qualität dazu. CISA beschrieb den Wurm „Shai-Hulud“, der über 500 npm-Pakete kompromittierte: Er suchte auf befallenen Rechnern nach Zugangsdaten wie GitHub-Tokens und Cloud-Schlüsseln, meldete sich damit als der betroffene Entwickler bei npm an und veröffentlichte selbstständig verseuchte Versionen weiterer PaketeBelegt. Ein Token ist dabei eine Art digitaler Dauerschlüssel, mit dem Programme sich ohne Passwort anmelden.

GitHub, der Betreiber von npm, kündigte daraufhin an, das Veröffentlichen von Paketen strenger abzusichern: Zwei-Faktor-Pflicht beim lokalen Veröffentlichen, kurzlebige Tokens und sogenanntes Trusted Publishing, bei dem kein dauerhafter Schlüssel mehr im Build-System liegen mussHerstellerangabe.

2026: Die Angriffe erreichen Container-Images #

Für Selbsthoster ist 2026 das wichtigere Jahr, weil die Angriffe dort ankamen, wo Homelabs Software beziehen: bei Docker-Images.

• Trivy, März 2026. Ausgerechnet ein Sicherheitsscanner wurde zum Einfallstor. Mit gestohlenen Zugangsdaten veröffentlichten Angreifer eine manipulierte Trivy-Version, verbogen 76 von 77 Versions-Tags der zugehörigen GitHub Action auf Schadcode, der Zugangsdaten abgriff, und stellten in einem zweiten Schritt manipulierte Images direkt auf Docker Hub — für rund zehn Stunden und ohne passende Version auf GitHubBelegt.
• ChainDrop, Sommer 2026. Microsoft beschreibt einen weiteren sich selbst verbreitenden npm-Wurm, der über 400 Pakete befiel; er nutzt ein Installations-Skript, das schon vor Abschluss der Installation läuft, und kann in bestimmten Build-Umgebungen sogar Pakete mit gültigem Herkunftsnachweis veröffentlichenHerstellerangabe. Das ist eine wichtige Lektion: Eine gültige Signatur beweist, woher etwas kommt — nicht, dass es harmlos ist.
• LiteLLM, Oktober 2026. Die Software ist im Homelab beliebt, um lokale und Cloud-KI-Modelle hinter einer Schnittstelle zu bündeln. Laut LiteLLM enthielt Version 1.107.0 am 21. Oktober 2026 Malware, die Zugangsdaten stiehlt; betroffen waren das Python-Paket auf PyPI und die offiziellen Docker-Images inklusive der Tags latest, main-latest und main-stable, für jeweils rund zwei bis zweieinhalb StundenHerstellerangabe. Das Projekt rät, bei jedem Host, auf dem die Version lief, von einem Abfluss der Daten auszugehen und alle erreichbaren Schlüssel zu tauschen. Die Untersuchung lief bei Redaktionsschluss noch.

Das Muster ist in allen drei Fällen gleich: gestohlene Zugangsdaten von Entwicklern oder Build-Systemen, ein offiziell aussehendes Release, ein kurzes Zeitfenster. Wer in diesem Fenster automatisch aktualisiert hat, hat den Schadcode selbst geholt.

Was heißt das für dich? #

Du kannst Lieferketten-Angriffe nicht verhindern. Du kannst aber beeinflussen, ob ein vergiftetes Update bei dir landet — und wie viel Schaden es dann anrichtet.

1. Pinne Images auf Versionen, nicht auf latest. In deiner compose.yaml steht dann image: example/app:1.4.2 statt example/app:latest. Noch strenger ist der Digest, die unveränderliche Prüfsumme eines Images: example/app:1.4.2@sha256:<DIGEST>. Die Docker-Doku beschreibt Tags als veränderlich und Digests als exakte Festlegung — mit dem Hinweis, dass Docker dann auch keine neueren Versionen mit Sicherheitsupdates mehr ziehtBelegt. Pinnen ist also kein Ersatz für Updates, sondern macht sie bewusst.
2. Updates mit kurzer Verzögerung statt sofort und blind. Die vergifteten Images von Trivy und LiteLLM waren nach Stunden entdeckt und entfernt. Für normale Feature-Updates schadet es nicht, ein, zwei Tage abzuwarten und in die Release Notes zu schauen. Ausnahme: echte Sicherheitsupdates für Dienste, die aus dem Internet erreichbar sind — die gehören sofort eingespielt. Tools wie Renovate oder Diun können dich über neue Versionen informieren, statt sie ungefragt einzuspielen.
3. Herkunft prüfen, wo Projekte signieren. Immer mehr Projekte signieren ihre Images mit Sigstore. Mit cosign verify lässt sich prüfen, ob die Signatur zum Image-Digest passt und — bei schlüssellosen Signaturen — welche Identität bei welchem Anbieter signiert hatBelegt. Denk an die ChainDrop-Lektion: Das zeigt dir, dass das Image aus der erwarteten Pipeline stammt, nicht, dass die Pipeline sauber war.
4. Offizielle Quellen bevorzugen. Images direkt vom Projekt oder aus offiziellen Docker-Hub-Bereichen, nicht von unbekannten Accounts mit ähnlichem Namen.
5. Container klein und arm an Geheimnissen halten. Gib einem Container nur die Zugangsdaten, die er wirklich braucht, und keine Cloud-Schlüssel mit Vollzugriff. Kein Docker-Socket in Container, die ihn nicht brauchen. Eine Trennung per VM oder LXC (siehe Docker in VM oder LXC) begrenzt zusätzlich, was ein kompromittierter Container erreicht.
6. Ausgehenden Verkehr einschränken. Die meisten dieser Schadprogramme müssen gestohlene Daten nach Hause schicken. Ein Dienst, der keinen Internetzugang braucht, sollte auch keinen haben.
7. Für den Ernstfall vorbereitet sein. Lief eine betroffene Version bei dir: Container stoppen, Image löschen, aus einer sauberen Version neu aufbauen, alle Schlüssel tauschen, auf die der Container Zugriff hatte. Ein Backup nach der 3-2-1-Regel macht das Neuaufsetzen deutlich entspannter.

Wie schnell Updates bei echten Sicherheitslücken gehen müssen, zeigt der Fall aus dem ersten Teil der Reihe: Dort hieß die richtige Antwort „sofort“. Bei Lieferketten-Angriffen ist das Dilemma, dass genau dieses „sofort“ ausgenutzt wird. Die Auflösung: Sofort nur bei bestätigten Sicherheitsupdates für erreichbare Dienste, sonst mit Verstand und kurzem Abstand.