BSI warnt: Next.js-Schwachstellen erlauben RCE und DoS

Der Warn- und Informationsdienst (WID) des BSI hat am 15. Oktober 2026 eine Meldung zu Next.js veröffentlicht und stuft sie als "hoch" ein. Unter der Kennung WID-SEC-2026-3973 warnt der Dienst vor mehreren Next.js-Schwachstellen, über die ein Angreifer beliebigen Programmcode ausführen und einen Denial-of-Service-Angriff fahren kann. Die Angaben, die die Schwere sonst einordnen, fehlen in der abrufbaren Fassung: CVE-Nummern, CVSS-Werte und betroffene Versionsbereiche lassen sich daraus nicht belegen. Genau diese Lücke prägt jede Empfehlung, die sich derzeit ableiten lässt.

Was die BSI-Meldung zu Next.js-Schwachstellen belegt und was nicht

Belegbar sind aus der WID-Meldung zwei Dinge: das betroffene Produkt Vercel Next.js und die Wirkungsklasse der Lücken, also Codeausführung und Dienstausfall. Alles Weitere fehlt. Die Seite lieferte beim Abruf nur ihren Seitentitel, keine Advisory-Liste, keine Versionsbereiche, keine Patch-Angaben. Schweregrad, betroffene Releases und ein möglicher Fix sind damit aus der auslösenden Quelle nicht zu belegen.

Naheliegend ist, dass sich die Warnung auf Einträge bezieht, die am 14. Oktober 2026 im Advisory-Board des Maintainers veröffentlicht wurden. Diese Zuordnung ist jedoch eine thematische Näherung, keine bestätigte Identität. Wer die Meldung als Beleg für einen bestimmten Angriff liest, überinterpretiert sie. Ein öffentlich verfügbarer Exploit oder eine laufende Ausnutzungswelle ist aus der BSI-Quelle nicht belegt und wird hier nicht behauptet.

RCE in der Image Optimization API, DoS im App Router

Die im Next.js-Advisory-Board für den 14. Oktober 2026 gelisteten Einträge passen inhaltlich zum WID-Muster: eine unauthentifizierte Codeausführung in der Image Optimization API, wenn SVGs verarbeitet werden; eine unauthentifizierte Codeausführung in use cache-Funktionen mit typisierten Arrays; und ein Denial of Service im App Router über Server Actions.

Technisch sind das drei unterschiedliche Angriffsflächen. Die Image-Optimization-Route muss für Besucher erreichbar sein, weil sie Bilder ausliefert. Eine unauthentifizierte Lücke an dieser Stelle trifft jede Instanz, die den Endpunkt offen betreibt. use cache ist ein neueres Cache-Primitiv, das Eingaben aus der Anwendung verarbeitet; Server Actions sind ein regulär exponierter Eingang des App Routers. Gemeinsam ist allen dreien, dass sie ohne vorherige Anmeldung erreichbar sind. Das ist der entscheidende Unterschied zu einer Lücke, die erst nach erfolgreicher Authentifizierung greift: Hier genügt ein einzelner HTTP-Request aus dem Netz.

Self-Hosting trifft es härter als Vercel-Hosting

Nach Darstellung von Vercel sind Anwendungen, die auf der eigenen Plattform laufen, von den Next.js-Sicherheitslücken nicht betroffen. Das ist eine Herstelleraussage, keine unabhängige Messung. Der August-Release dokumentiert diesen Schutz für gehostete Anwendungen und nennt für Self-Hosting die Patch-Versionen 15.5.24 und 16.3.3. Wer Next.js selbst betreibt, fällt nicht unter diese Zusage und trägt die Patch-Pflicht selbst.

Zu den August-Lücken gehören GHSA-2xp9-vwfh-vxw4, eine Schwachstelle bei der Verarbeitung von AVIF-Bildern über die Bibliothek libheif, und CVE-2026-75604 für Windows. Beide ermöglichen nach Angaben des Maintainers unauthentifizierte Codeausführung. Eine detaillierte Analyse beschreibt als Ursache der AVIF-Lücke einen Heap-Overflow in libheif und ordnet die Lücken mit CVSS-Werten, Versionsbereichen und Crediting ein. Der Mai-Release folgte demselben Muster: 13 Advisories in einem Paket, darunter die Upstream-Schwachstelle CVE-2026-23870 aus dem React-Server-Components-Umfeld sowie Klassen wie Middleware- und Proxy-Bypass, DoS, SSRF, XSS und Cache Poisoning.

Bemerkenswert ist weniger die einzelne Lücke als der Rhythmus. Next.js bekommt seine Sicherheitskorrekturen in monatlichen Bündeln. Wer nur zu großen Feature-Releases aktualisiert, betreibt in diesem Modell regelmäßig eine Version mit bereits bekannten, aber noch nicht eingespielten Fehlern.

Patch-Management: Was Betreiber jetzt tun sollten

Aus der BSI-Meldung lässt sich kein bestätigter Workaround ableiten. Bis der Inhalt der Warnung faktengeprüft ist, gilt die konservative Linie:

Versionsstand prüfen. Bei Self-Hosting den eingesetzten Stand gegen die zuletzt veröffentlichten Patch-Versionen abgleichen. Für den August-Release sind das 15.5.24 und 16.3.3; für die thematisch nächstliegenden Oktober-Advisories liegen hier keine Versionsangaben vor.
Auf den aktuellsten Patch-Stand heben. Solange die WID-Meldung keine Zielversion nennt, ist die neueste verfügbare Version die sicherste Annahme. Wer erst nach Bestätigung der Details patcht, gewinnt nichts, verliert aber Zeit.
Advisory-Board beobachten. Die Einträge des Maintainers sind die belastbarste Quelle für Versionsbereiche und Fixes, nicht die aggregierte Warnmeldung.
Netzwerkfilter nicht als Ersatz behandeln. Ein WAF kann Anfragemuster abfangen, doch bei serverseitigen Deserialisierungs- und Cache-Fehlern bleibt die Trefferquote begrenzt. Die Lücke verschwindet damit nicht, sie wird nur schwerer erreichbar.

Fazit

Die WID-Meldung belegt ein Produkt und eine Wirkungsklasse, nicht die Details. Für Betreiber selbst gehosteter Next.js-Instanzen ist das trotzdem Grund genug, zeitnah zu handeln: unauthentifizierte Codeausführung ist die schwerste Kategorie, die eine Webanwendung treffen kann. Wer auf Vercel hostet, kann sich auf die dokumentierte Schutzaussage stützen, sollte sie aber als das behandeln, was sie ist, nämlich eine Zusage des Anbieters. Self-Hoster müssen ihre Update-Kadenz an den monatlichen Security-Zyklus des Frameworks anpassen. Sobald das BSI Einzelheiten, CVE-Nummern und Fix-Versionen nachliefert, ist eine Nachbewertung fällig.

Quellen