31. August 2026

6 MIN.

Zwei Jahre Vertrauen, eine Hintertür: Was die XZ-Backdoor über Lieferkettenrisiken lehrt

Im Juni 2026 tauchten im Darknet mehr als 200.000 Dateien aus dem Apple-Zulieferernetzwerk von Tata Electronics auf: Fertigungsunterlagen, Bauteillisten und interne Kommunikation zum neusten iPhone 18 Pro. Der Angriffsweg ist bis heute nicht öffentlich aufgeklärt.

Dass dabei eine Software-Schwachstelle den Einstieg lieferte, ist plausibel, aber bislang nicht belegt. Wie ein solcher Angriff abläuft, lässt sich dafür an einem anderen Fall lückenlos nachvollziehen, dem Fall der XZ-Backdoor, CVE-2024-3094.

Der Fall: Eine unsichtbare Hintertür mit unbeschränktem Zugriff

Ende Februar und Anfang März 2024 gelangte Schadcode in die Release-Versionen 5.6.0 und 5.6.1 von XZ Utils, genauer in die Bibliothek liblzma, eine zentrale Kompressionskomponente, die von nahezu allen Linux-Distributionen genutzt wird und Bestandteil zahlreicher Software- und Build-Prozesse ist.

Der eingeschleuste Code manipulierte die SSH-Authentifizierung: Ein Angreifer mit dem passenden Schlüssel hätte sich ohne Zugangsdaten anmelden und beliebigen Code mit Root-Rechten ausführen können. Die Schwachstelle erhielt den höchstmöglichen Schweregrad (CVSS-Wert von 10.0), da sie vollständigen Fernzugriff auf Systemebene ermöglichte, und das versteckt in einer Bibliothek, die im Hintergrund einfach funktioniert und die kaum jemand prüft.

Bemerkenswert ist die Tarnung: Der Code blieb in Test- und Scan-Umgebungen inaktiv und aktivierte sich nur im Produktivbetrieb. Wer die Bibliothek prüfte, sah nichts.

Zwei Jahre Vertrauen, ein Zufallsfund

Eingeschleust wurde der Code nicht durch einen externen Angriff, sondern durch einen der offiziellen Maintainer, der unter dem Pseudonym „Jia Tan“ auftrat. Der Werdegang dieses Accounts ist das eigentlich Beunruhigende. Gut zwei Jahre lang lieferte er unauffällige, hilfreiche Beiträge, baute Vertrauen zum überlasteten Hauptmaintainer auf und erhielt schrittweise mehr Verantwortung bis er schließlich Commit-Rechte und die Rolle des zweiten Maintainers erhielt. Dieses erarbeitete Vertrauen war am Ende das Werkzeug: Es verschaffte ihm den Zugang, die Hintertür dort zu platzieren, wo niemand mehr genauer hinsah.

Gefunden wurde sie nicht durch Audit oder Scanner, sondern durch reinen Zufall. Der Entwickler Andres Freund bemerkte im März 2024 bei Performance-Tests, dass SSH-Logins ungewöhnlich viel CPU-Zeit beanspruchten, und ging der Ursache nach. Da war der Code bereits in Rolling-Release-Distributionen ausgeliefert, wenige Wochen vor dem Einzug in die nächsten Long-Term Support (LTS)-Releases.

Damit stehen sich zwei Arbeitsweisen gegenüber: zwei Jahre methodische Vorbereitung auf der einen Seite und ein aufmerksamer Entwickler auf der anderen. Der Angriff war ein Prozess, die Entdeckung war ein Zufall.

Eine Schwachstelle, tausend betroffene Produkte

Zufälle lassen sich nicht planen und auf einen aufmerksamen Entwickler zur richtigen Zeit baut man kein Sicherheitskonzept. Planbar ist dagegen, wie schnell eine solche Entdeckung bei denen ankommt, die das Problem in ihren Produkten haben.

Denn die Schwachstelle selbst ist schnell im operativen Betrieb angekommen. Ein Maschinenhersteller aktualisiert seine Engineering-Workstation oder liefert ein Edge-Gateway aus. Die kompromittierte Bibliothek erreicht die Produktionsumgebung also nicht über einen Netzwerkangriff, sondern über ein reguläres Update. Sie ist Bestandteil des als vertrauenswürdig eingestuften Systems, bevor dieses in Betrieb geht. Genau das macht Lieferketten-Kompromittierungen so gefährlich: Sie unterlaufen jede Kontrolle am Netzwerkrand.

Auf fremde Komponenten zu verzichten, ist dabei keine Option, denn kein Produkt dieser Klasse entsteht heute ohne externe Bibliotheken. Bleibt also nur der andere Hebel: bekannte Schwachstellen so früh wie möglich finden, beheben und offenlegen. Genau hier setzt der Cyber Resilience Act (CRA) an.

Beheben, offenlegen, wiederfinden

Drei Pflichten greifen ineinander

Die Behebung: Wer ein Produkt in Verkehr bringt, muss bekannt gewordene ausnutzbare Schwachstellen unverzüglich schließen und Updates über den gesamten Supportzeitraum kostenlos bereitstellen. Im XZ-Backdoor-Fall kam der Patch vom Open-Source-Projekt selbst, obwohl es auch unter dem CRA nicht dazu verpflichtet wäre.

Die Offenlegung: Behobene Schwachstellen müssen öffentlich benannt werden, samt aller betroffenen Komponenten.

Und die Stückliste (SBOM): Jeder Hersteller muss dokumentieren und analysieren, was in seinem Produkt steckt.

Erst zusammen wirken sie: Die Offenlegung benennt die Komponente, in der gerade eine Schwachstelle behoben wurde, und die SBOM sagt jedem Hersteller, ob sie in seinem Produkt steckt. Ohne SBOM bleibt die Veröffentlichung folgenlos – weder Hersteller noch Betreiber können feststellen, ob ihre eigenen Produkte betroffen sind.

Die Kette endet erst beim Endnutzer

Für den nächsten Hersteller in der Kette beginnt die Arbeit mit der Offenlegung. Die SBOM-Analyse zeigt, dass eine gemeldete Schwachstelle eine Komponente im eigenen Produkt betrifft. Ob sie dort auch ausnutzbar ist, sagt sie nicht. Das klärt erst eine Bewertung im eigenen Kontext: Wird die betroffene Funktion überhaupt genutzt, ist die Komponente extern erreichbar?

Ergibt die Bewertung eine ausnutzbare Schwachstelle, wiederholt sich der Zyklus: beheben, ausliefern, gegenüber den eigenen Kunden offenlegen. Für deren Hersteller beginnt er dann von vorn. Abgeschlossen ist die Kette erst beim Endnutzer.

Für jeden Beteiligten heißt das: eingehende Meldungen überwachen und bewerten, ausgehende selbst erzeugen. Zwei Kanäle, die dauerhaft gepflegt werden müssen. Dafür braucht es sauber definierte, auf das eigene Unternehmen abgestimmte Prozesse.

Wir haben diesen Prozess als Hersteller eines OT-Sicherheitsprodukts selbst aufgesetzt und dabei gemerkt, wie sehr er sich von der gewohnten Softwareentwicklung unterscheidet. Aus dem, was wir dabei gelernt haben, ist unser CRA-Beratungsservice entstanden. Wir helfen Ihnen, die Abläufe sinnvoll in Ihr Unternehmen einzupassen, damit die Umsetzung im Alltag trägt und nicht in der Ablage landet.

Drei Takeaways

Vertrauen ist kein Sicherheitskonzept. Zwei Jahre unauffälliger Beiträge reichten für Commit-Rechte in einem kritischen Projekt. Der Angriff lief durch die Zugangskontrolle, nicht gegen sie.

Die Schwachstelle kommt durch die Vordertür. Sie erreicht die Anlage über ein reguläres Update als Teil der vertrauenswürdigen Software-Lieferkette.

Die Kette hält nur, wo die Übergaben sitzen. SBOM, Bewertung und Offenlegung wirken nur zusammen, wenn sie mit möglichst wenig Aufwand ins Tagesgeschäft passen. Je schlanker der Ablauf, desto zuverlässiger läuft er.

Was der Prozess nicht abfängt

Der CRA stellt sicher, dass gefundene Schwachstellen behoben und offengelegt werden. Er hilft aber nicht dabei, die Zeit zu überbrücken, in der niemand von der Lücke weiß. Im XZ-Backdoor-Fall war dieses Fenster kurz. Das ist nicht die Regel, denn viele Schwachstellen bleiben monate- oder jahrelang unentdeckt. Bei dem anfänglich benannten Fall von Tata Electronics ist der Angriffsweg bis heute unbekannt und könnte zu weiteren Vorfällen führen. Und manchmal lassen sich selbst bekannte Lücken nicht mehr schließen, denn viele Anlagen laufen längst außerhalb ihres Supportzeitraums weiter, ohne Aussicht auf Updates.

Für diese beiden Fälle braucht es eine Ebene, die nicht davon abhängt, ob eine Schwachstelle bekannt ist oder ob sich das System noch aktualisieren lässt. Eine strukturelle Trennung zwischen IT und OT, wie sie der edge.SHIELDOR herstellt, kann helfen.

Übrigens: Für Maschinenhersteller, die ihre ausgelieferten Produkte im Zuge des CRA gegen solche Risiken absichern müssen, haben wir mit edge.PSL eine eigene Antwort entwickelt.

Jetzt den ersten Schritt machen

Ob Sie Ihre CRA-Pflichten aufsetzen, Ihre Produktion absichern oder Ihre ausgelieferten Maschinen schützen wollen oder mehreres davon: Wir gehen die Ausgangslage gemeinsam mit Ihnen durch.

Autorin: Dr. Madline Kniebusch

Madline Kniebusch ist seit 2021 als Data Scientist bei der TRIOVEGA GmbH tätig, bringt Erfahrung aus dem Projektmanagement mit und verantwortet seit 2026 die Umsetzung des Cyber Resilience Acts.

BUCHEN SIE IHR UNVERBINDLICHES BERATUNGSGESPRÄCH