Ein einziger Softwarefehler in einer Netzwerkkomponente hat am 23. Juni den kompletten deutschen Zugverkehr für rund zwei Stunden gestoppt. Die Deutsche Bahn hat die Ursache inzwischen offengelegt, doch die eigentliche Lehre trifft jedes Unternehmen mit einem vermeintlich sicheren Zweitsystem.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügenDer Zugfunk-Ausfall der Deutschen Bahn vom 23. Juni 2026 hat ein System getroffen, das eigentlich doppelt abgesichert war. Das Zwillingssystem stand bereit, ist aber nicht angesprungen, weil der Fehler völlig lautlos aufgetreten ist. Damit reiht sich der Vorfall in ein Muster ein, das digitale Infrastruktur weit über die Schiene hinaus bedroht.
Das Wichtigste in Kürze
- Am 23. Juni 2026 ist gegen 22:30 Uhr der digitale Zugfunk GSM-R bundesweit ausgefallen, rund zwei Stunden lang stand auch der S-Bahn-Verkehr in Berlin, München und Stuttgart still.
- Auslöser war ein Switch-Tausch bei planmäßiger Wartung, bei dem ein Softwarefehler auftrat, der keine Fehlermeldung erzeugt hat.
- Ohne diese Meldung hat die redundante Rückfallebene nicht automatisch umgeschaltet, das Personal musste manuell eingreifen und zuvor einen Cyberangriff ausschließen.
- DB InfraGO hat die Ursache inzwischen analysiert und beschränkt Wartungen künftig auf das inaktive Zweitsystem und die Zeit zwischen 0 und 4 Uhr.
Warum kippte ein lautloser Fehler die gesamte Redundanz?
Weil die automatische Umschaltung an eine Fehlermeldung gekoppelt ist. Der Softwarefehler beim Switch-Tausch hat keine erzeugt, also hat das System die Störung nicht erkannt und das bereitstehende Zwillingssystem nicht aktiviert. Der Schutz war vorhanden, nur sein Auslöser fehlte.
Der GSM-R-Funk ist die Voraussetzung dafür, dass Züge überhaupt fahren dürfen. Fällt er aus, bleiben die Fahrzeuge aus Sicherheitsgründen am nächsten Bahnhof stehen. Die Bahn hat das System bewusst doppelt ausgelegt, damit ein Defekt automatisch auf das Parallelsystem übergeht.
Der Haken steckt im Auslöser dieser Umschaltung, denn sie setzt eine Fehlermeldung voraus. Der singuläre Softwarefehler bei einer Netzwerkverteilkomponente ist aber stumm geblieben. In der Überwachung wirkte alles unauffällig, während der Funk längst stand. „Wir wissen jetzt, wie dieses historisch einmalige Fehlerbild entstand und wie wir es in Zukunft verhindern können“, erklärt Philipp Nagl, Vorstandsvorsitzender der DB InfraGO[1].
Ist das ein Einzelfall oder ein bekanntes Muster?
Der Vorfall folgt einem bekannten Muster. Eine Redundanz, die erst auf ein Fehlersignal reagiert, schützt nicht gegen den stillen Ausfall, bei dem genau dieses Signal fehlt. Cloud-Monokulturen und die großen IT-Ausfälle der vergangenen Jahre zeigen dieselbe Schwachstelle.
Ein vergleichbares Bild hat zuletzt der Cloudflare-Ausfall geliefert, bei dem eine einzelne Abhängigkeit Tausende Dienste gleichzeitig lahmgelegt hat. Das Prinzip dahinter bleibt gleich: Ein Backup, das seine Aktivierung an die Erkennung des Fehlers knüpft, hat eine blinde Stelle.
Fällt die Erkennung selbst aus, bleibt das teuerste Zweitsystem wirkungslos. In jener Nacht mussten die Techniker zuerst einen Cyberangriff ausschließen, bevor sie von Hand umschalten konnten. Wertvolle Minuten ohne einen einzigen fahrenden Zug.
Ein Backup, das nur auf Alarm reagiert, ist kein Backup, sondern eine Wette darauf, dass der Fehler sich meldet.
— Markus Seyfferth, Chefredakteur Dr. Web
Die Gegenmaßnahmen der DB InfraGO
Wartungsarbeiten laufen künftig nur noch zwischen 0 und 4 Uhr.
Eingriffe erfolgen ausschließlich am inaktiven Zweitsystem.
Das GSM-R-Netz wird modernisiert, dazu kommt eine Rückfallebene über den öffentlichen Mobilfunk.
Was heißt das für die eigene IT im Mittelstand?
Failover regelmäßig testen und aktiv überwachen, statt sich auf Fehlermeldungen zu verlassen. Ein Heartbeat-Signal erkennt das Schweigen eines Systems, bevor der Betrieb steht. Für Betreiber kritischer Infrastruktur gelten mit NIS2 zusätzliche Nachweispflichten.
Die Bahn zählt zur kritischen Infrastruktur und fällt unter NIS2 und das KRITIS-Dachgesetz, die Betreiber zu belastbaren Notfallkonzepten verpflichten. Wie hoch der Aufwand im Mittelstand ausfällt, hat das BSI zuletzt hinterfragt, und für kleinere Betriebe hat Brüssel die NIS2-Hauptlast inzwischen entschärft.
Für Unternehmen ohne KRITIS-Status bleibt die Lehre praktisch. Ein Zweitsystem ist nur so gut wie sein Auslöser. Ohne regelmäßige Failover-Tests unter Realbedingungen und ohne gepflegte Grundlagen der IT-Sicherheit bleibt offen, ob die Umschaltung im Ernstfall überhaupt greift.
Prüfen Sie deshalb diese Woche, ob Ihr eigenes Notfallsystem auf ein aktives Signal wartet oder bloß auf das Ausbleiben eines Fehlers, den niemand meldet. Genau diese blinde Stelle hat bei der Bahn zwei Stunden gekostet.
Quelle
[1] Deutsche Bahn (DB InfraGO): „Zugfunk-Störung vom 23. Juni 2026: Ursache analysiert, Gegenmaßnahmen eingeleitet“ ↩
Mehr Newshunger?
- 16 Jahre unentdeckt: Sicherheitslücke „Januscape“ im Linux-Kernel
- BSI und BfV: Russische Hacker spähen Solaranlagen aus
- BSI warnt vor Cyber-Lücken in öffentlicher Ladeinfrastruktur
- Schwere Sicherheitslücken häufen sich rund um KI-Modell-Release
- Post-Mythos-Cybersecurity: Ruhe bewahren statt vor KI-Angriffen zu zittern
- Cybersecurity-Glossar 2026: 99 Begriffe von BSI bis Zero Trust
