Herstellerhaftung beim Jahr-2038-Problem: Wegweisendes Urteil zum Y2K38-Bug

Ein Gericht hat erstmals die Herstellerhaftung im Zusammenhang mit dem Jahr-2038-Problem bestätigt. Das Pariser Verwaltungsgericht ordnete am Donnerstag, den 13. November 2025 an, dass Alstom diesen schwerwiegenden Softwarefehler beheben muss. Dies berichten verschiedene französische Medien, darunter LInfome , LeParisien, LeFigaro und 20minutes.

Dieser Softwarefehler – der sogenannte Y2k38-Bug – kann im Jahr 2038 den Betrieb mehrerer Metro- und RER-Linien in Paris zum Stillstand bringen. Das Gericht wertete den Fehler als „versteckten Mangel“ und verpflichtete den Zugbauer Alstom dazu, eine vollständige technische Lösung zu liefern. Das wegweisende Gerichtsurteil könnte zum Präzedenzfall für die gesamte Branche werden und zeigt, dass das Jahr-2038-Problem längst eine rechtliche Dimension hat. Mit grossen wirtschaftlichen Auswirkungen schon jetzt.

In Paris machten Techniker der RATP im Jahr 2017 eine ähnliche Entdeckung, wie wir sie bei Beoz Association bereits mit einem Fernseher getestet haben. Sie versuchten, an den neuen Zügen der Linie RER A die Systemzeit auf ein Datum nach 2037 zu stellen. Das gelang jedoch nicht. Die Uhr liess sich schlicht nicht weiterstellen. Der Grund war der Y2K38-Bug, ein Zeitfehler, der dazu führt, dass viele ältere oder eingebettete Systeme nur Daten bis Anfang 2038 verarbeiten können. Alles, was darüber liegt, erzeugt falsche Werte oder führt zum vollständigen Ausfall des Systems. Diese technische Beobachtung war der erste Hinweis darauf, dass ein Teil der Pariser Fahrzeugflotte im Jahr 2038 nicht mehr betriebsfähig sein könnte – und damit begann die juristische Auseinandersetzung.

Das bedeutet: Ohne Eingriffe wäre spätestens Mitte Januar 2038 ein erheblicher Teil des Pariser Nahverkehrs nicht mehr funktionsfähig – mit weitreichenden Folgen für Millionen von Fahrgästen.

Die Behebung des Y2K38-Bugs ist technisch anspruchsvoll und offensichtlich so teuer, dass es für Alstom bislang günstiger schien, einen jahrelangen Gerichtsprozess zu führen, statt das Problem sofort zu lösen. Viele der betroffenen Züge wurden vor 10 bis 20 Jahren entwickelt. Ihre Software in ein modernes 64-Bit-Format zu überführen, ist kein einfacher Patch. In vielen Fällen müsste das gesamte Betriebssystem der Zugsteuerung erneuert werden, inklusive grundlegender Bibliotheken. Das bedeutet umfangreiche Neukompilierungen, komplette Testreihen und neue Sicherheitsfreigaben.

Hinzu kommt, dass sicherheitskritische Systeme nicht wie eine normale App aktualisiert werden können. Jede Änderung erfordert Prüfungen, Zertifizierungen und oft einen Probebetrieb unter realen Bedingungen. Auf den Punkt gebracht: Man kann nicht einfach am Freitagnachmittag ein Update im Kontrollzentrum einspielen und am Samstag wieder regulär fahren. Wahrscheinlicher ist, dass Linien zeitweise für Tests stillgelegt werden müssen oder nächtliche Betriebspausen verlängert werden.

Diese Kombination aus technischer Tiefe, regulatorischer Strenge und hohen Kosten erklärt, warum das Problem über Jahre ungelöst blieb – und warum der Druck erst durch das Gerichtsurteil erheblich zunimmt.

Das Gericht kam nach Prüfung der Unterlagen zu dem Schluss, dass Alstom für den Y2K38-Bug haftbar ist. Entscheidend war, dass der Fehler bei der Auslieferung der Fahrzeuge nicht erkennbar war und damit als „versteckter Mangel“ gilt. Der Hersteller hatte ein System geliefert, dessen zentrale Zeitfunktion nur bis Anfang 2038 reicht – eine Begrenzung, die im Betrieb zwangsläufig zu einem Ausfall führen wird.

Alstom wies die Vorwürfe zurück und argumentierte, dass das Jahr-2038-Problem seit den 1990er-Jahren in der Fachwelt bekannt sei. Die RATP hätte daher über die Begrenzungen des 32-Bit-Zeitformats informiert sein müssen. Der Hersteller sah den Fehler nicht als Mangel, sondern als eine allgemeine Eigenschaft der verwendeten Technologie. Zudem verwies Alstom darauf, dass die betroffenen Systeme jahrzehntelang zuverlässig im Einsatz waren und erst viele Jahre nach Inbetriebnahme an die natürliche Grenze des Zeitformats stossen würden.

Für die RATP war das Problem weder vorhersehbar noch im normalen Betrieb erkennbar. Der Y2K38-Bug betraf Kernfunktionen der Fahrzeugsteuerung und stellte eine Einschränkung dar, die den bestimmungsgemässen Einsatz der Züge im Jahr 2038 unmöglich machen würde. Damit lag ein klarer technischer Mangel vor, der bereits bei der Auslieferung existierte.

Das Gericht verpflichtete Alstom deshalb, eine vollständige technische Lösung bereitzustellen und definierte klare Fristen sowie finanzielle Sanktionen, bis zu einer Million Euro pro Monat, bei Verzögerungen. Es setzte damit ein starkes Signal: Hersteller müssen langfristige Software-Risiken aktiv prüfen, offenlegen und beherrschen – selbst wenn sie erst Jahrzehnte später wirksam werden.

Aus Sicht von BEOZ Association ist das Pariser Urteil ein überfälliges und wichtiges Signal. Es macht deutlich, dass das Jahr-2038-Problem kein theoretisches Randthema der Informatik ist, sondern ein reales Risiko für kritische Infrastrukturen. Besonders relevant ist, dass das Gericht die Verantwortung nicht allein beim Betreiber verortet, sondern die Herstellerpflicht zur langfristigen Funktionsfähigkeit klar betont. Genau diese Perspektive fehlt bis heute in vielen IT- und Beschaffungsprozessen.

Gleichzeitig zeigt der Fall Paris, wie teuer es werden kann, solche Risiken aufzuschieben. Technische Schulden verjähren nicht, sie wachsen. Das Urteil unterstreicht, dass Prävention nicht nur technisch sinnvoll, sondern auch wirtschaftlich und rechtlich geboten ist. Für BEOZ ist dies ein starkes Argument, das Jahr-2038-Problem systematisch anzugehen – nicht erst kurz vor dem Stichtag, sondern jetzt, solange noch Handlungsspielraum besteht.

Es wäre naiv anzunehmen, dass Alstom vergleichbare Systeme nur nach Paris geliefert hat – oder dass ausschliesslich Züge vom Jahr-2038-Problem betroffen sind. Alstom ist ein globaler Anbieter von Bahn- und Verkehrstechnik. Fahrzeuge, Leitsysteme und eingebettete Steuerungen desselben oder ähnlichen Typs sind weltweit im Einsatz. Wenn eine grundlegende Architektur in Paris versagt, ist es höchst unwahrscheinlich, dass sie anderswo anders aufgebaut ist.

Noch naiver wäre es, das Problem auf Züge zu begrenzen. Die Unix-Zeit findet sich in nahezu allen Ebenen kritischer Infrastrukturen: in Stellwerken, Signalsystemen, Wartungs- und Diagnosesystemen, Zugangskontrollen, Energieversorgung, Abrechnung und Überwachung. Viele dieser Systeme wurden vor Jahrzehnten entwickelt, für Laufzeiten von 20, 30 oder mehr Jahren. Ob und wo überall noch 32-Bit-Zeitformate im Einsatz sind, ist oft nicht vollständig dokumentiert.

Das tatsächliche Ausmass des Jahr-2038-Problems lässt sich deshalb kaum seriös beziffern. Es ist kein einzelner Fehler, sondern eine strukturelle Schwachstelle, die sich durch ganze Technologiegenerationen zieht. Der Fall Paris ist damit weniger eine Ausnahme als ein sichtbares Symptom. Er zeigt, was passiert, wenn ein lange bekanntes Risiko erstmals auf reale Betriebs- und Rechtsrealität trifft.

Offen bleibt dabei eine zentrale Frage: Wer trägt am Ende die Kosten? Die Betreiber, die Hersteller, die Versicherungen – oder letztlich doch die Steuerzahler? Die Antwort darauf wird nicht nur technische, sondern auch politische und gesellschaftliche Folgen haben. Eine Herstellerhaftung alleine wird nicht genügen.

Sollte Alstom im Verfahren tatsächlich argumentiert haben, dass „die im POSIX-Standard erwähnte Frist für Zeitstempel im Jahr 2038 bereits 1999 bekannt gewesen sei“, ist diese Darstellung technisch irreführend. Der POSIX-Standard begrenzt die Unix-Zeit nicht auf das Jahr 2038. Er definiert lediglich, dass time_t die Sekunden seit dem 1. Januar 1970 zählt. Die bekannte 2038-Grenze ist eine Folge historischer 32-Bit-Implementierungen, nicht des Standards selbst.

Mit POSIX.1-2024 wurde diese Unschärfe sogar explizit behoben: time_t muss nun mindestens 64 Bit breit sein. Der Standard ist damit Teil der Lösung, nicht Teil des Problems. Wer sich heute auf POSIX beruft, um eine feste Grenze im Jahr 2038 zu erklären, verwechselt Standarddefinition mit veralteter Implementierung.