// LINUXNEWS.DE — LINUX & OPEN SOURCE
Reproducible Builds: Wie man Python-Software vor Supply-Chain-Angriffen schützt
3.286 potenziell unerwünschte Anwendungen, 2.155 Fälle von Secrets-Exfiltration und 1.326 Dropper, allein auf PyPI, allein im zweiten Quartal 2026, gezählt von der Sicherheitsfirma Sonatype in ihrem “Open Source Malware Index”. Macht zusammen fast 6.800 als bösartig eingestufte Python-Paket-Artefakte in drei Monaten, auf einem einzelnen Package-Index. Drei der Kampagnen dahinter sind gut genug dokumentiert (mehrere unabhängige Sicherheitsfirmen, übereinstimmende Details), um sie hier konkret durchzugehen.
Am 24. März 2026 erschienen zwei neue Versionen von litellm (einer Python-Bibliothek, die eine einheitliche Schnittstelle zu über hundert verschiedenen LLM-Anbietern wie OpenAI oder Anthropic bietet und allein im letzten Monat über 651 Millionen Downloads zählte, laut pypistats.org) auf PyPI: 1.82.7 und 1.82.8 (Datadog Security Labs, Akamai). Kein Tippfehler-Paket, kein Fake, sondern das echte, verbreitete Projekt selbst, veröffentlicht über einen gestohlenen Zugriff auf dessen CI-Pipeline. Akamais Analyse macht dafür einen fehlkonfigurierten pull_request_target-GitHub-Actions-Workflow verantwortlich, über den ein Zugriffs-Token abgegriffen wurde. Version 1.82.7 versteckte den Schadcode noch im Proxy-Modul des Pakets selbst (litellm/proxy/proxy_server.py), ausgeführt erst beim Import; Version 1.82.8 ging einen Schritt weiter und brachte eine unscheinbare litellm_init.pth-Datei mit. .pth-Dateien sind eigentlich ein harmloser, alter Mechanismus: Python liest beim Interpreter-Start (über das site-Modul) alle Dateien mit dieser Endung im site-packages-Verzeichnis ein, und jede Zeile darin wird normalerweise schlicht als zusätzlicher Pfad an den Modul-Suchpfad sys.path angehängt. Die Ausnahme, die das Format zum Angriffswerkzeug macht: Zeilen, die mit import beginnen, werden stattdessen als Python-Code ausgeführt, bei jedem Start jedes Interpreters in dieser Umgebung, noch bevor das eigentliche Programm überhaupt läuft und ganz unabhängig davon, ob das betroffene Paket je importiert wird. Wer das Paket in diesem Zeitfenster installierte, schickte damit ungefragt Umgebungsvariablen, SSH-Schlüssel und Cloud-Zugangsdaten an einen fremden Server.
Kein Einzelfall: Am 19. Mai 2026 traf es Microsofts offizielles durabletask-SDK für Azure Durable Functions (rund 366.000 Downloads pro Monat, laut pypistats.org). Drei bösartige Versionen, veröffentlicht über einen kompromittierten PyPI-API-Token, in einem 35-Minuten-Fenster (Wiz, StepSecurity). Anfang Juni dieselbe Technik noch einmal, diesmal gegen 19 Bioinformatik-Pakete aus dem wissenschaftlichen Python-Ökosystem, wieder über eine .pth-Datei — dieser Angriff läuft in der Berichterstattung unter dem Namen “Shai-Hulud” (BleepingComputer). Alle drei Fälle werden demselben Akteur zugeordnet, dessen Kampagne die beteiligten Sicherheitsfirmen “TeamPCP” nennen, und folgen demselben Muster: Zugriff auf die Veröffentlichungs-Pipeline kapern, eine neue Version veröffentlichen, die aussieht wie jede andere; die Versionsnummer allein verrät nichts.
Wie aktuell das Thema ist, zeigt sich noch an einer zweiten Stelle: Bis vor wenigen Wochen war es auf PyPI technisch möglich, einer Paket-Version, die schon Jahre zuvor veröffentlicht wurde, nachträglich eine komplett neue Datei hinzuzufügen: ein Paket, das 2019 nur als Sdist (source distribution, ein Distributions-Archiv mit dem rohen Quellcode, aus dem beim Installieren erst noch ein Wheel gebaut werden muss) erschien, hätte 2026 plötzlich ein frisches Wheel (das bereits fertig gebaute, direkt installierbare Format, kein Kompilieren mehr nötig) bekommen können, ohne dass sich die Versionsnummer ändert. PyPI selbst hat diese Lücke erst Anfang Juli 2026 geschlossen. Genau dieser Fall, dass ein bereits als sicher geltendes Release nachträglich verändert wird, ist der Grund, warum weiter unten nicht nur Versionsnummern, sondern Hashes gepinnt werden — die Details dazu folgen in einem eigenen Abschnitt.
Die drei Fälle oben drehen sich alle um dieselbe An