Laravel-Schwachstellen: BSI warnt, PoC für Bypass kursiert

Das BSI führt in seinem Advisory mehrere Laravel-Schwachstellen mit CVSS Base 9.8 und stuft sie damit als kritisch ein, der Temporal-Score liegt bei 8.8. Betroffen sind Stände vor 13.29.0 und vor 12.68.0, als Plattformen nennt das BSI Linux, UNIX und Windows, einen Remoteangriff bejaht es ausdrücklich. Das Advisory trägt das Datum 20.10.2026 und den Stand 23.10.2026, eigene CVE-IDs nennt es nicht. Parallel meldet das italienische CSIRT einen Authentication Bypass in Laravels TokenGuard, für den ein Proof of Concept öffentlich verfügbar ist.

Wer die Dringlichkeit einschätzt, muss beide Meldungen getrennt lesen: Das BSI-Advisory bündelt eine Gruppe von Lücken unter einem Score, das CSIRT-ITA-Alert beschreibt genau eine CVE.

Laravel-Schwachstellen: CVSS 9.8, aber keine CVE-IDs im Advisory

Inhaltlich bleibt das BSI knapp. Ein Angreifer könne „mehrere Schwachstellen in Laravel ausnutzen, um Sicherheitsvorkehrungen zu umgehen, und um Daten zu manipulieren“ – so formuliert es das Advisory selbst. Welche Einzellücken unter dem Base-Score von 9.8 zusammengefasst sind, geht daraus nicht hervor. Der Score allein taugt deshalb nur bedingt als Priorisierungshilfe; entscheidend sind der bejahte Remoteangriff, die betroffenen Standardkomponenten und die Frage, ob eine Anmeldung Voraussetzung ist. Für die Einordnung im eigenen Betrieb hilft der Abgleich des Versionsstands mehr als die Zahl.

Das Advisory setzt außerdem „Mitigation: ja“, ohne dass aus dem zitierten Stand hervorgeht, welche Maßnahme damit gemeint ist. Wer sich darauf verlässt, sollte den Punkt offen behandeln und den Patch als primären Weg betrachten.

CVE-2026-114509: Authentication Bypass im TokenGuard mit öffentlichem PoC

Das CSIRT-ITA des italienischen ACN meldet einen verfügbaren Proof of Concept für CVE-2026-114509 im Alert AL02/261022/CSIRT-ITA vom 22.10.2026. Die Lücke ist als Authentication Bypass und zusätzlich als Spoofing eingeordnet, bewertet mit CVSSv4 9.2. Ursache ist eine fehlende Typvalidierung: Der TokenGuard, Laravels standardmäßiger tokenbasierter API-Guard, weist ein Credential, das kein String ist, nicht zurück. Ein nicht authentifizierter Angreifer kann demnach präparierte HTTP-Requests an API-Routen senden und die Authentifizierung umgehen. Als betroffene Stände gelten Versionen vor 12.68.0 und vor 13.29.0.

Wie weit der Bypass reicht, hängt von der Umgebung ab: Die Beschreibung der CVE macht die Auswirkung von der Konfiguration von MySQL beziehungsweise MariaDB abhängig. Für die Bewertung ist das relevant, weil derselbe Fehler in unterschiedlichen Setups unterschiedlich viel preisgeben kann.

Ein Proof of Concept belegt, dass die Lücke ausnutzbar ist – nicht, dass sie bereits ausgenutzt wird. Das Alert meldet einen PoC, keine laufenden Angriffe gegen TokenGuard-APIs.

CVE-2026-102279: XSS in der Debug-Page bei aktivem APP_DEBUG

Die zweite separat geführte Laravel-CVE betrifft die Exception-Debug-Pages. Laut Eintrag im NIST NVD sind Stände vor 12.69.0 und vor 13.30.0 betroffen; die Analyse ist dort noch als „Awaiting Enrichment“ geführt, also ohne vollständige Anreicherung. Voraussetzung ist eine Konfiguration mit APP_DEBUG=true: Die Debug-Page übergibt dann angreiferkontrollierten Input an ein Tippy.js-Tooltip, woraus sich ein XSS ergibt.

Daneben verzeichnet die GitLab Advisory Database drei weitere Laravel-Advisories aus dem Jahr 2026: Neben dem XSS in der Debug-Page sind dort eine Temporary Signed URL Path Confusion und eine CRLF-Injection in der Default-Email-Rule gelistet. Das französische CERT-FR nennt in CERTFR-2026-AVI-1343 zusätzlich Denial-of-Service-Angriffe über das Netz, Auswirkungen auf die Datenintegrität und die Umgehung von Sicherheitsrichtlinien und verweist auf zwei Laravel-GHSA-Advisories vom 19.10.2026.

Warum die Fix-Stände auseinanderliegen

Vergleicht man die Angaben, ergeben sich zwei verschiedene Patch-Schwellen. Das BSI nennt Stände vor 13.29.0 und vor 12.68.0. Das NVD führt für CVE-2026-102279 dagegen 12.69.0 und 13.30.0 als Fix-Versionen. Wer nur auf die im BSI-Advisory genannten Stände hebt, schließt die XSS-Lücke in der Debug-Page also nicht zwingend. Sinnvoll ist deshalb der Sprung auf 13.30.0 beziehungsweise 12.69.0, der beide Meldungen abdeckt.

Ein Teil der Unschärfe dürfte strukturell bedingt sein: Das BSI-Advisory nennt keine CVE-IDs und fasst mehrere Lücken unter einem Score zusammen, während NVD und die Advisory-Datenbanken jede CVE einzeln mit eigener Versionsmatrix führen. Die GHSA-Advisories vom 19.10.2026 deuten darauf hin, dass Laravel selbst zeitnah reagiert hat; die vom BSI genannten Stände liegen dazu leicht verschoben.

Was Betreiber jetzt tun sollten

Versionsstand erheben: Prüfen, welche Version von laravel/framework in der composer.lock steht – die Schwellen 12.68.0/12.69.0 und 13.29.0/13.30.0 sind der Maßstab.
Aktualisieren: Ziel sollte 13.30.0 beziehungsweise 12.69.0 sein. Wer zuerst nur auf 13.29.0 oder 12.68.0 hebt, deckt die BSI-Lücken ab, lässt aber die Debug-Page-XSS offen.
APP_DEBUG in Produktion deaktivieren: Ohne diesen Schalter greift CVE-2026-102279 nicht, und auch andere Laravel-Angriffsflächen entschärfen sich.
API-Routen prüfen: Tokenbasierte Routen, die über den TokenGuard laufen, sollten auf Anfragen kontrolliert werden, deren Credential kein String ist. Für CVE-2026-114509 existiert ein PoC, die Hürde für Nachahmer ist entsprechend niedrig.
Mitigation-Status klären: Das BSI führt „Mitigation: ja“, ohne die Maßnahme im zitierten Stand zu benennen. Bis zur Klärung bleibt der Patch der belastbare Weg.

Fazit

Die Laravel-Lage ist unübersichtlich, nicht neu: Ein hoher Base-Score, ein öffentlicher PoC und mehrere, leicht gegeneinander verschobene Fix-Versionen. Entscheidend ist der eigene Versionsstand – wer auf 13.30.0 oder 12.69.0 aktualisiert und APP_DEBUG in Produktion aus lässt, hat beide hier dokumentierten Lücken adressiert. Ob es bereits Ausnutzung gibt, ist nicht bekannt; gemeldet ist bislang nur der PoC.

Quellen