Laravel TokenGuard umgangen: Bist du betroffen, und was heute zu tun ist

Laravel News hat am 2026-10-20 über ein kritisches Advisory berichtet, GHSA-f9x3-7vq9-cph6 mit einem CVSS-Wert von 9.2, in Illuminate\Auth\TokenGuard, der Klasse hinter dem Guard-Treiber token. Auf MySQL und MariaDB konnte ein Angreifer ohne Konto als bestehender Benutzer authentifiziert werden, ohne dessen API-Token zu kennen. Wer Laravel betreibt, sollte nicht fragen, wie schlimm das klingt, sondern ob die eigene App diesen Guard überhaupt nutzt, und das beantwortet eine einzige Datei.

Was schiefging

Laut dem Advisory, wie Laravel News es beschreibt, prüfte der Guard nur, ob das Token aus dem Request nicht leer war, bevor er es an den User Provider weitergab. Ein speziell präparierter Wert, der kein String war, kam durch diese Prüfung, und die anschließende Suche traf einen Benutzerdatensatz, den sie nie hätte treffen dürfen, statt fehlzuschlagen. Gemeldet wurde die Lücke von Hristijan Manasijev. Der Fix ergänzt eine Typprüfung in user() und validate(), sodass alles, was kein String ist, abgewiesen wird, bevor eine Abfrage läuft.

// before (simplified): only emptiness was checked
if (! empty($token)) { ... }

// after (as quoted in the report): the type is checked first
if (is_string($token) && ! empty($token)) { ... }

Warum ein Nicht-String-Wert bei einer Suche gefährlich ist

Dieser Teil erklärt die Fehlerklasse allgemein, nicht den bestätigten Mechanismus dieses Advisorys. Request-Input ist in PHP nicht immer ein String. Ein Query-String oder ein JSON-Body kann ein Array mitbringen, wo dein Code einen einzelnen Wert erwartet, und Query Builder behandeln ein Array oft als "mehrere Werte" oder "mehrere Bedingungen" statt als ein Token zum Vergleichen. Code, der nur fragt "ist es leer?", lässt dieses Array durch, und die Suche beantwortet dann eine andere Frage als die, die du stellen wolltest. Die Abwehr ist langweilig und zuverlässig: Prüfe den Typ jedes Inputs, der wie ein Zugangsdatum aussieht, direkt an der Grenze, bevor er eine Query berührt.

Bist du betroffen? Öffne config/auth.php

Laut Advisory bist du nur betroffen, wenn ein Guard in config/auth.php den Treiber token verwendet, zum Beispiel 'api' => ['driver' => 'token', 'provider' => 'users']. Sanctum und Passport registrieren eigene Guard-Treiber und stehen nicht im Advisory. Die gepatchten Versionen sind Laravel 12.68.0 und 13.29.0, beide im Artikel von Laravel News auf den 2026-08-25 datiert; jede Version darunter gilt als betroffen, und Patches gibt es nur für die Zweige 12.x und 13.x. Wer auf einer älteren Major-Version ist und den Treiber token nutzt, behebt das Problem nur mit dem Major-Upgrade.

Am selben Tag kam ein zweites Advisory mittlerer Schwere, GHSA-5wcm-3v2w-8362 mit CVSS 6.5, in den JSON:API-Ressourcen, die mit 12.45 dazukamen: Ein reiner Lese-Request ließ sich so bauen, dass er eine zerstörerische Datenbankoperation auf einer verknüpften Tabelle auslöste. Laravel News nennt dafür 12.68.0 und 13.27.0 als gepatchte Versionen, dasselbe Upgrade deckt also beide ab.

Was du ausführen solltest

composer update laravel/framework
composer audit

Nimm composer audit auch in die CI auf, damit das nächste Advisory als roter Build auftaucht und nicht als Artikel, den du zufällig liest. Für diese Site habe ich beides geprüft: composer.lock pinnt laravel/framework auf v13.35.0, also jenseits von 13.29.0, und config/auth.php definiert nur einen session-Guard, einen token-Guard gibt es hier also gar nicht. Wenn du eine neue API baust, ist Sanctum der sicherere Standard als der nackte Token-Guard, und egal was du nutzt: Prüf, dass jedes Zugangsdatum ein String ist, bevor es eine Query erreicht.

Quelle: Laravel News, „Laravel token guard auth bypass“.