Laravel schließt kritische Authentifizierungslücke in TokenGuard

Die Maintainer des Frameworks veröffentlichten am 19. Oktober den Hinweis GHSA-f9x3-7vq9-cph6, der eine kritische Schwachstelle (CVSS 9.2) in TokenGuard beschreibt, Laravels eingebautem tokenbasiertem Authentifizierungs-Guard. Auf MySQL oder MariaDB konnte ein nicht authentifizierter Angreifer jeden existierenden Benutzer imitieren, ohne dessen API-Token zu kennen. Der Patch selbst war bereits zwei Monate zuvor still und leise in den Versionen 12.68.0 und 13.29.0 ausgeliefert worden.

#Ein Patch, veröffentlicht vor seiner eigenen Offenlegung

Die Versionen 12.68.0 und 13.29.0 erschienen am 25. August 2026. Die Release-Notes ließen damals nicht erkennen, wie schwerwiegend das gerade behobene Problem war. Erst am 19. Oktober, fast zwei Monate später, legte der Hinweis GHSA-f9x3-7vq9-cph6 das tatsächliche Risiko offen — ein Rhythmus, der bei Framework-Maintainern mittlerweile üblich ist: still patchen, Teams Zeit zum Aktualisieren geben, das Risiko erst danach öffentlich dokumentieren. Das letzte große Release des Frameworks, Version 13.36, hatte bereits die Zuverlässigkeit der Queue-Worker verbessert; 13.29, das TokenGuard behebt, liegt im selben Zweig einige Versionen davor.

#Der Mechanismus der Schwachstelle

TokenGuard ist der einfachste Authentifizierungs-Guard, den Laravel zum Schutz einer API mitliefert: Er vergleicht das vom Client gesendete Token mit dem für den Benutzer gespeicherten. Vor dem Patch prüfte die Klasse lediglich, ob das Token nicht leer war, bevor sie es an den User Provider weiterreichte. Ein Angreifer konnte einen speziell konstruierten, nicht-textuellen Credential-Wert übermitteln, den die Datenbankabfrage auf MySQL und MariaDB unerwartet interpretierte — bis hin zur Übereinstimmung mit einem nicht beabsichtigten Benutzerdatensatz.

// config/auth.php — betroffene Konfiguration
'api' => [
    'driver'   => 'token',
    'provider' => 'users',
],

// Vor dem Patch: nur eine Prüfung auf Leere
if (empty($token)) {
    return null;
}
$user = $provider->retrieveByCredentials(['api_token' => $token]);

// Seit 12.68.0 / 13.29.0: nicht-textuelle Werte werden abgelehnt
if (empty($token) || ! is_string($token)) {
    return null;
}

#Wer betroffen ist

Betroffen sind ausschließlich Anwendungen, die in config/auth.php einen Guard mit dem Treiber token deklarieren, und das nur auf MySQL oder MariaDB. Laravel Sanctum und Laravel Passport registrieren eigene Guard-Treiber und fallen nicht unter diesen Hinweis.

Zwei Monate liegen zwischen dem stillen Patch und seiner öffentlichen Offenlegung — eine ungewöhnlich lange Zeitspanne für eine Schwachstelle, mit der sich ein nicht authentifizierter Angreifer als jeder beliebige Benutzer ausgeben konnte.

#Wie man reagiert

Die Korrektur besteht in einem Versions-Update: composer update laravel/framework auf 12.68.0, 13.29.0 oder neuer. Teams sollten anschließend config/auth.php durchsehen, um jeden mit dem Treiber token konfigurierten Guard zu identifizieren, mit Priorität auf Anwendungen, die auf MySQL oder MariaDB laufen. Ein regelmäßiger Durchlauf mit composer audit, zusammen mit den übrigen Kommandozeilen-Werkzeugen, die eine solide Entwicklungsroutine ausmachen, hätte den Hinweis bereits bei seiner Veröffentlichung sichtbar gemacht. Allgemeiner erinnert diese Schwachstelle daran, dass ein API-Token selbst eine Form von Anwendungsgeheimnis ist, das denselben Umgang verdient wie Umgebungsvariablen und Zugangsdaten eines Projekts.

#Was man sich merken sollte

• TokenGuard, Laravels tokenbasierter Authentifizierungs-Guard, war vor den Versionen 12.68.0 und 13.29.0 anfällig für Account-Übernahmen auf MySQL und MariaDB.
• Der Patch erschien am 25. August 2026, der öffentliche Hinweis aber erst am 19. Oktober.
• Sanctum und Passport sind nicht betroffen; betroffen sind nur Guards, die explizit den Treiber token verwenden.
• Ein einziges Update von laravel/framework behebt zugleich den verwandten JSON:API-Hinweis.

#Zum Weiterlesen

Vollständiger Sicherheitshinweis: GHSA-f9x3-7vq9-cph6 auf GitHub.