PyPI, das zentrale Paketregister für Python, nimmt seit dem 8. Juli 2026 keine neuen Dateien mehr an, sobald ein Release älter als 14 Tage ist. Ausgelöst hat den Schritt die Kaperung der weit verbreiteten Pakete LiteLLM und Telnyx im Frühjahr. Für jedes Team, das Python-Abhängigkeiten aus der Lieferkette zieht, verschiebt sich damit ein Stück Risiko.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Das Wichtigste in Kürze
- 14-Tage-Frist: Zwei Wochen nach Veröffentlichung ist die Datei-Liste eines Releases geschlossen, weitere Uploads weist PyPI ab.
- Schutzziel: Ein gestohlenes Publishing-Token kann alte, breit installierte Versionen nicht mehr heimlich um Schadcode ergänzen.
- Kaum Reibung: Nur 56 von 15.000 Top-Paketen hatten je eine Datei später als 14 Tage nach dem Release nachgereicht.
- Branchenanschluss: crates.io und npm behandeln veröffentlichte Versionen längst als unveränderlich.
Was ändert PyPI genau?
Die Regel ist schmal und wirkt doch tief. Ein Release, also eine feste Versionsnummer eines Pakets, akzeptiert neue Uploads nur noch in den ersten 14 Tagen. Danach bleibt die Datei-Liste unverändert.
Der Patch der PyPI-Sicherheitsingenieure Seth Larson und Mike Fiedler wurde am 8. Juli zusammengeführt.[1] Ein Paket für eine neue Python-Version rüstet man künftig über die nächste Versionsnummer nach, nicht über ein Jahre altes Release.
Kaum spürbar ist die Grenze im Alltag. Eine Auswertung der 15.000 wichtigsten Pakete hat nur 56 Fälle gefunden, in denen ein passendes Wheel später als zwei Wochen nach dem Release nachgereicht wurde.
Warum ist das ein Riegel gegen gekaperte Tokens?
Der eigentliche Gewinn zeigt sich im Schadensbild eines Einbruchs. Bislang konnte ein gestohlenes Token eine stabile, millionenfach installierte Altversion still um eine bösartige Datei ergänzen. Wie leicht solche Zugangsdaten nach außen geraten, hat zuletzt eine Überwachungskamera von Hanwha vorgeführt, die einen Admin-Token offen in der Firmware trug.
pip lädt beim Installieren automatisch das zur Plattform passende Wheel. Eine nachgeschobene Schaddatei in einem vertrauten Release erreicht so genau die Nutzer, die aus Vorsicht auf eine feste Version gepinnt haben. Dass Angreifer gezielt Repositories und Registries ins Visier nehmen, hat kürzlich auch ein KI-Agent von OpenAI vorgeführt.
Mit der Frist bleibt einem gekaperten Konto nur der laute Weg über eine neue Version, die in Update-Feeds und Monitoring sofort auffällt. Zugleich endet der unklare Zwischenzustand, in dem ein Release teils vergiftet, teils sauber ist.
Neu ist der Gedanke nicht. crates.io behandelt jede veröffentlichte Version als unveränderlich und kennt nur das Zurückziehen per Yank, npm sperrt das Überschreiben ebenso. PyPI schließt damit zu einem Standard auf, den andere Ökosysteme nach eigenen Vorfällen wie der jüngsten Kernel-Lücke RefluXFS längst gezogen haben.
Unveränderliche Releases sind kein Python-Detail, sondern Grundhygiene jeder Lieferkette. Nach einem Einbruch nachgerüstet, kostet dieselbe Regel den doppelten Aufräumaufwand.
— Michael Dobler, Herausgeber Dr. Web
Was heißt das für den DACH-Raum?
Für deutsche Teams trifft die Änderung einen wunden Punkt zur richtigen Zeit. Der EU Cyber Resilience Act verpflichtet Hersteller ab dem 11. Dezember 2027 zu einer maschinenlesbaren Stückliste und zu geregeltem Schwachstellen-Management, die Meldepflichten greifen schon ab dem 11. September 2026.
Haftung inklusive: Verstöße kann die Marktaufsicht mit bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes ahnden. Ein unveränderliches Upstream-Register nimmt genau die Unsicherheit aus der Lieferkette, für die Unternehmen künftig geradestehen.
Drei Schritte lohnen jetzt:
- Abhängigkeiten samt Prüfsumme pinnen, etwa über den Hash-Checking-Modus von pip.
- Für jedes eigene Release eine SBOM erzeugen und pflegen.
- Neue Paketversionen aktiv überwachen, statt alten Ständen blind zu vertrauen.
Quelle
[1] Python Package Index Blog: „Releases now reject new files after 14 days“
Mehr Newshunger?
- Hanwha-Überwachungskamera verrät einen GitHub-Admin-Token in der Firmware
- 16,4 Millionen Linux-Systeme: RefluXFS verschafft jedem lokalen Nutzer Root-Rechte
- OpenAIs KI-Agent durchbricht die Testumgebung und hackt Hugging Face
- Cyberangriff als Insiderinformation: Warum die BaFin TeamViewer 240.000 Euro Bußgeld auferlegt
- Von Stunden auf Minuten: Amazons KI-Agent übernimmt die erste Bedrohungsanalyse
