Wie fand Tailscale den 16 Jahre alten SQLite-Fehler?

16 Jahre alter SQLite-Fehler: Tailscale findet die Ursache seiner Datenverluste

Michael Dobler

Autor Dr. Web

12. August 2026

2 Min. Lesezeit

Tailscale hat sechs Monate lang beschädigte Datenbanken repariert, ohne die Ursache zu finden. Am Ende steckte ein Wettlauf zwischen zwei Threads im Kern von SQLite, unentdeckt seit rund 16 Jahren. Betreiber, die SQLite abseits der Standardkonfiguration einsetzen, tragen dasselbe Risiko.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Ein einziger SQLite-Fehler hat bei Tailscale binnen sechs Monaten 19 Datenbanken beschädigt.^[1] Jedes Mal stoppte das Team den betroffenen Koordinationsserver. Die Kunden dort verloren so lange Admin-Konsole und API.

Das Wichtigste in Kürze

19 Datenbanken wurden in sechs Monaten beschädigt, anfangs mit über einer Stunde Ausfall je Reparatur.
Als Ursache steht ein Data Race zwischen Checkpoint und Schreibtransaktion fest, laut den SQLite-Entwicklern seit mindestens 16 Jahren im Code.
SQLite 3.51.3 vom 13. März 2026 behebt den Fehler, nachdem Version 3.52.0 zurückgezogen wurde.
Gefunden hat den Fehler kein Testlauf, sondern Diagnosecode im laufenden Betrieb.

Wie verschluckt ein Checkpoint fertig geschriebene Daten?

Zwei braune Pappkartons, einer mit Karteikarten gefüllt, ein anderer „kopiert“ beschriftet — Data Race bei Checkpoint zerstört WAL-Seiten, ohne sie zu kopieren. Indizes verweisen danach auf nicht existierende Datenbankseiten

Ein Data Race zwischen Checkpoint und Schreibtransaktion bringt die Checkpoint-Routine dazu, Seiten des Write-Ahead-Logs als kopiert zu verbuchen, obwohl der Kopiervorgang nie stattfand. Der Inhalt dieser Seiten ist damit endgültig verloren. Beschädigt wird die Datei erst danach: Indizes verweisen weiter auf Seiten, die nie in der Datenbank landeten.

Tailscales Messwerte zeigten Checkpoints, die mehr Seiten kopierten, als das Log überhaupt enthielt. Erst ein eigens gebautes Transaktionslog machte den zweiten Befund sichtbar: Daten, die eine Transaktion geschrieben und bestätigt hatte, blieben für spätere Transaktionen unsichtbar. Ein stiller Schreibverlust fällt in keinem Monitoring auf, anders als ein versehentlich gelöschter Produktivbestand.

Warum bleibt so ein Fehler 16 Jahre lang unentdeckt?

Seltenheit schützt vor Entdeckung. Auf 155.800 Zeilen C-Code kommen bei SQLite rund 92 Millionen Zeilen Testcode, das 590-Fache, bei 100 Prozent Branch-Abdeckung in der ausgelieferten Konfiguration.^[2] Organisch reproduziert haben die Entwickler den WAL-Reset-Fehler trotzdem nie. Greifbar wurde er erst durch eigens eingebauten Code, der die Kollision im Testlauf erzwingt.

Der Fehler traf Tailscale, weil das Unternehmen die Checkpoints selbst und sehr aggressiv steuert. Darin liegt die übertragbare Lehre: Eine dokumentierte und unterstützte Konfiguration abseits des Standardpfads bleibt ein Betriebsrisiko, weil dort vor Ihnen kaum jemand war. Denselben Mechanismus zeigen der Cloudflare-Ausfall und der Zugfunk-Ausfall der Bahn, bei dem die Redundanz selbst versagte.

Die Punktversionen 3.53.1 bis 3.53.4 zwischen Mai und Juli 2026 beheben laut Änderungsprotokoll Probleme, die überwiegend von KI-Systemen gemeldet wurden.^[3] Die Maschinen liefern also den Nachschub an kleinen Befunden, während der teure Kernfehler nur durch Forensik im Echtbetrieb auffiel. Den Gegenfall hat Dr. Web im August beschrieben, einen frei erfundenen CVE-Eintrag zu einer SQLite-Lücke.

Sechs Monate Produktionsforensik bei Tailscale sind der Preis dafür, eine Standardkomponente außerhalb ihres getesteten Standardpfads zu betreiben. Genau dort sitzt das Restrisiko, das kein Testaufwand des Herstellers abdeckt.
— Markus Seyfferth, Chefredakteur Dr. Web

beschädigte Datenbanken bei Tailscale innerhalb von sechs Monaten

16 Jahre

so lange steckte das Data Race unentdeckt im SQLite-Code

590-fach

mehr Testcode als Quellcode, ohne den Fehler je organisch auszulösen

Fehlalarme direkt nach dem Update, ausgelöst von veralteten Ausdrucksindizes

Vom ersten Schaden bis zum Beweis

August 2025

Die Integritätsprüfung meldet die erste beschädigte Datenbank in einem Backup.

6. März 2026

SQLite 3.52.0 erscheint mit dem Fix und wird kurz darauf zurückgezogen.

13. März 2026

SQLite 3.51.3 behebt allein den WAL-Reset-Fehler, ohne weitere Neuerungen.

Zwei Monate später

Ein eigener Warnhinweis belegt das Data Race im Echtbetrieb, ohne Schaden.

Was folgt daraus für Betreiber im DACH-Raum?

Datenverlust ohne Angreifer bleibt ein meldepflichtiger Vorfall. Artikel 4 Nummer 12 DSGVO zählt die unbeabsichtigte Vernichtung und Veränderung personenbezogener Daten ausdrücklich zur Verletzung ihres Schutzes, die 72-Stunden-Frist nach Artikel 33 läuft also auch bei einem Softwarefehler. Artikel 32 verlangt zusätzlich, Verfügbarkeit und Zugang rasch wiederherzustellen sowie die Wirksamkeit dieser Maßnahmen regelmäßig zu überprüfen. Für Einrichtungen unter dem neuen BSIG zählt das Backup-Management nach § 30 ohnehin zu den Pflichtmaßnahmen.

Drei Schritte lohnen sich sofort, unabhängig von der eingesetzten Datenbank:

SQLite auf 3.51.3 oder neuer heben, bei Einsatz von 3.53.0 zusätzlich auf 3.53.4.
Die Integritätsprüfung automatisiert über die Sicherungen laufen lassen, nicht nur über die Live-Datenbank. Genau dieser Prüflauf machte den Schaden bei Tailscale sichtbar.
Die Wiederherstellung mindestens quartalsweise echt proben, wie in unserem Überblick zu Backup-Strategien 2026 beschrieben.