Next.js hat im August zwei kritische unauthentifizierte RCEs ausgeliefert. Bist du betroffen?

Am 25. August 2026 hat das Next.js-Team 15.5.24 und 16.3.3 ausgeliefert, um zwei Schwachstellen mit kritischem Schweregrad zu beheben. Beide sind Remote Code Execution ohne Authentifizierung. Eine mit 9,0 bewertet, die andere mit 9,5. Kein Login, keine Nutzerinteraktion, kein Klick auf einen Link.

Dann haben die Security-Rundschauen getan, was Security-Rundschauen tun, und das halbe Internet hat beschlossen, dass jede Next.js-Seite der Welt brennt. Such nach der Berichterstattung zum Next.js-CVE vom August 2026, und du findest zwanzig Beiträge, die dir sagen, du sollst sofort patchen, und ungefähr keinen, der dir sagt, ob du überhaupt betroffen bist.

Bist du nicht. Eine der beiden betrifft nur Server, die auf einem Windows-Dateisystem laufen, was praktisch jeden Docker-Container, jeden Linux-VPS und jede Serverless-Umgebung ausschließt, auf die ich je eine Kundenseite deployed habe. Die andere ist breiter, und die ist deinen Nachmittag wert.

Ich betreibe Next.js- und Astro-Seiten für Kunden aus einem Ein-Personen-Laden in Augsburg. Ich deploye über Docker und Coolify, mit Directus-Backends hinter den meisten davon. Das landete also auf meiner eigenen To-do-Liste, nicht als abstrakte Nachricht. Hier ist, was tatsächlich ausgeliefert wurde, wer wirklich exponiert ist und wie du dich in etwa fünf Minuten selbst prüfst.

Was am 25. August tatsächlich ausgeliefert wurde

Das Next.js-CVE vom August 2026 sind zwei Advisories, beide als kritisch markiert, beide gemeinsam gepatcht.

Das erste ist CVE-2026-75604, CVSS 9,0, ein Path Traversal, das auf Windows-gehosteten Servern zu RCE ohne Authentifizierung führt. Betroffene Bereiche sind >= 13.4 < 15.5.24 und >= 16.0 < 16.3.3. Das ist ein breites Versionsfenster, zurück bis Next.js 13.4.

Das zweite hat noch keine CVE-Nummer. Es wird auf Next.js-Seite als GHSA-2xp9-vwfh-vxw4 und upstream als GHSA-g89c-p67h-r497 geführt und mit 9,5 nach CVSS v4.0 bewertet. Es ist ein Heap Overflow in libheif, der C-Bibliothek, die sharp zum Dekodieren von AVIF nutzt, und sharp ist das, was Next.js für Bildoptimierung nutzt. Betroffene Bereiche sind >= 10.0.0 < 15.5.24 und alles unter 16.3.3. Also: fast jede jemals veröffentlichte Next.js-Version.

Die behobenen Versionen sind 16.3.3 (Active LTS) und 15.5.24 (Maintenance LTS). Zwei Befehle:

npm install next@15.5.24  # für die 15.5-Linie
npm install next@16.3.3   # für die 16.3-Linie

Erwähnenswert, was der AVIF-Fix tatsächlich macht. Next.js hat libheif nicht repariert, denn das ist nicht ihr Code. Die gepatchten Releases deaktivieren die AVIF-Optimierung vollständig, bis der Upstream-Fix durchgesickert ist. AVIF-Bilder werden unverändert und unskaliert ausgeliefert. Das ist eine echte Verhaltensänderung, und wenn dein LCP-Bild ein großes AVIF ist, rechne damit, dass es nach dem Patch schwerer wird. Liefer den Patch trotzdem aus.

Ebenfalls erwähnenswert, was nicht passiert ist: Zum Zeitpunkt dieses Textes gibt es keine bestätigte Ausnutzung in freier Wildbahn und keinen öffentlichen Proof of Concept für eines der beiden Probleme. Das ist kein Grund, das Update auszulassen. Es ist ein Grund, es ruhig zu machen statt um 2 Uhr nachts.

Die Windows-Sache ist real, aber sie ist eng

CVE-2026-75604 braucht drei Dinge gleichzeitig. Deine App nutzt den Pages Router oder den App Router ohne Cache Components, und der Next.js-Server läuft auf einem Windows-Dateisystem.

Das Advisory ist deutlich zur Grenze: Linux und macOS sind nicht betroffen. Der Mechanismus erklärt warum. Prozentkodierte Backslash-Sequenzen erreichen die Routing-Schicht ohne Normalisierung, und unter Windows ist ein Backslash ein Verzeichnistrenner. Das Traversal löst sich also nur auf einem Dateisystem, das \ als Pfadgrenze behandelt, zu etwas Gefährlichem auf. Angreifer können aus dem Build-Cache-Verzeichnis herauslaufen und private Build-Daten lesen, inklusive des Verschlüsselungsschlüssels für das Server-Reference-Manifest, und über diesen Schlüssel kommt man zur Codeausführung.

Der CVSS-Vektor ist AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H. Achte auf das AC:H, Angriffskomplexität hoch. Das ist kein einzeiliges curl.

Wenn du über Docker auf einem Linux-Basisimage deployst, bist du nicht betroffen. Wenn du auf einem Linux-VPS läufst, nicht betroffen. Vercels Runtime ist Linux. Netlify Functions und Edge Functions laufen auf Linux. Das deckt den größten Teil der Branche ab.

Wenn du zu den Läden gehörst, die Next.js auf IIS oder einem Windows-Server hinter einem .NET-Stack betreiben, und die gibt es, gehört diese hier dir, und es gibt keinen Workaround. Das Advisory sagt es ausdrücklich. Upgraden, oder die App auf Linux umziehen.

Die AVIF-Sache ist das breitere Problem

Für die habe ich tatsächlich aufgehört, was ich gerade tat. Sie ist nicht betriebssystemspezifisch, der betroffene Bereich reicht zurück bis Next.js 10, und der Auslöser ist ein Bild.

Der Ablauf: Jemand bekommt eine präparierte AVIF-Datei in deine Bildoptimierungs-Pipeline, sharp reicht sie an libheif zum Dekodieren, libheif überläuft einen Heap-Puffer, und der Angreifer bekommt Codeausführung in deinem Next.js-Prozess. Keine Authentifizierung nötig.

Die Frage, die entscheidet, ob dich das interessiert, ist einfach: Kann ein Angreifer wählen, was dein /_next/image-Endpunkt dekodiert?

Zwei Wege, auf denen sie das meistens können. Erstens: Wenn deine next.config freizügige remotePatterns hat, die eine breite Menge Hosts erlauben, kann ein Angreifer die präparierte Datei selbst hosten und /_next/image?url=<seine-url> aufrufen. Zweitens: Wenn deine App Nutzer-Uploads annimmt und sie durch den Optimizer zurückschickt, braucht er nicht mal einen externen Host.

Wenn jedes Bild, das dein Optimizer anfasst, ein lokales Build-Asset in /public oder ein Import aus deinem Repo ist, ist die Angriffsfläche deutlich schmaler, denn der Angreifer muss seine Datei erst in dein Repo bekommen. Schmaler ist nicht null, und ich würde es nicht als Freifahrtschein behandeln. Aber es ist ein spürbar anderes Risikoprofil als eine Seite mit sperrangelweit offenen remotePatterns und einem Avatar-Upload.

Zwei Konfigurationen nehmen dich komplett raus. Wenn du images: { unoptimized: true } hast, läuft kein Optimizer. Wenn du auf output: 'export' bist und einen vollständig statischen Build ausliefertst, gibt es überhaupt keinen serverseitigen Bild-Endpunkt zum Angreifen. Statische Exporte sind hier nicht im Umfang, und Astro-Seiten, die sharp nie zur Laufzeit ausführen, auch nicht.

Der Juli waren neun CVEs, und fast niemand hat es gemerkt

Der August kam nicht aus dem Nichts. Am 21. Juli 2026 hat Next.js sein erstes planmäßiges Security Release veröffentlicht: neun CVEs, vier hoch und fünf mittel, gepatcht in 16.2.11 und 15.5.21.

Zwei davon sind direkt relevant dafür, wie die meisten Kundenseiten gebaut sind.

CVE-2026-64645 (hoch) ist SSRF in rewrites() und redirects(). Wenn eine Regel ihren externen Ziel-Hostnamen aus request-kontrollierter Eingabe baut, kann ein Angreifer sie auf jeden beliebigen Hostnamen richten, egal welches Suffix die Regel deklariert. Bei einem Rewrite proxyt dein Server zu seinem Host und gibt die Antwort über deinen Origin zurück. Bei einem Redirect bekommst du einen Open Redirect. Betroffene Versionen sind 12.0.0 bis 15.5.20 und 16.0.0 bis 16.2.10. Wenn deine next.config ein Rewrite mit dynamischem Zielhost hat, lies das genau.

CVE-2026-64643 (mittel) ist die unauthentifizierte Offenlegung interner Server-Function-Endpunkte. In App-Router-Apps können IDs von Server Actions und use cache-Endpunkten global offengelegt werden. Das Leck selbst sind undurchsichtige interne Kennungen, keine Zugangsdaten und keine personenbezogenen Daten. Es ist Aufklärungsmaterial für eine längere Kette, kein Einbruch für sich. Mittel ist die richtige Einstufung, und wer es dir als kritisch verkauft, verkauft etwas.

Der Rest dieses Releases lohnt ein Überfliegen: ein DoS in App-Router-Apps mit irgendeiner Server Action (CVE-2026-64641), eine Middleware-Umgehung bei Turbopack-Builds mit genau einem i18n.locales-Eintrag (CVE-2026-64642, und eine Middleware-Umgehung heißt, dass deine Auth-Prüfungen übersprungen werden), und zwei separate Fehler mit Fetch-Cache-Verwechslung.

Achte auf das Muster in den Voraussetzungen. Turbopack plus genau eine Locale. Ein Rewrite mit dynamischem Host. Windows-Dateisystem. Das sind bedingte Fehler, und zu wissen, welche Bedingung auf dich zutrifft, ist die ganze Aufgabe.

Dein Hoster hat einen Teil davon vielleicht schon erledigt

Das ist der Teil, den die Berichterstattung übersprungen hat, und er verändert die Dringlichkeit stark.

Vercel hat erklärt, dass dort gehostete Anwendungen geschützt sind, ohne Upgrades, Konfigurationsänderungen oder Redeploys. Sie haben AVIF-Optimierung über ihren gemanagten Image-Optimization-Dienst hinweg deaktiviert, und ihre Next.js-Runtime ist Linux, das Windows-Path-Traversal greift also nie.

Netlify hat für beides dasselbe gesagt. Die Windows-RCE trifft nicht zu, weil Functions und Edge Functions auf Linux laufen. Das Bildproblem trifft nicht zu, weil Bildanfragen an Netlifys eigenes CDN geroutet werden statt an die Next.js-Optimierungs-API. Sie empfehlen trotzdem, zu upgraden und neu zu deployen, und das ist der richtige Rat.

Cloudflare hat am 26. August ein Notfall-WAF-Release ausgeliefert, das eine bestehende Next.js-RCE-Regel aktualisiert hat, um CVE-2026-75604 zu fangen, und eine neue Regel für den Pfad des AVIF-Bildoptimizers ergänzt hat. Eine WAF-Regel ist Abmilderung, keine Behebung. Sie kauft dir Zeit; sie patcht deine Abhängigkeit nicht.

Selbst gehostet ist die exponierte Kategorie. Wenn du deinen eigenen Container baust und ihn auf deiner eigenen Kiste betreibst, hat niemand etwas für dich deaktiviert, und kein CDN fängt deine /_next/image-Anfragen ab. Da lebe ich, und da habe ich zuerst geprüft. Wenn du deine eigene Infrastruktur betreibst, ist das dieselbe Problemklasse, über die ich in The 6 Things That Actually Break on Websites Nobody Maintains geschrieben habe: Der Fehler ist nie das Framework, es ist das Jahr, in dem es niemand angefasst hat.

Der Fünf-Minuten-Check

Konkrete Schritte, der Reihe nach.

1. Finde deine echte Version. Nicht was package.json mit einem Caret davor sagt. Was installiert ist:

npm ls next

Oder lies die Lockfile direkt. Ein "next": "^15.5.4" in package.json sagt dir nichts darüber, was in deinem letzten Build gelandet ist.

2. Prüf dein Host-Betriebssystem. Wenn dein Dockerfile mit FROM node:22-alpine oder einer anderen Linux-Basis anfängt, ist CVE-2026-75604 von deiner Liste. Wenn du diese Frage zu einem Kundenprojekt nicht beantworten kannst, ist das ein eigener Befund.

3. Prüf deine Bildkonfiguration. Öffne next.config.js oder next.config.ts und schau dir images an. Ist unoptimized: true gesetzt? Ist output: 'export' gesetzt? Gibt es remotePatterns, und wie freizügig sind sie? Ein hostname: '**' darin lohnt sich unabhängig von jedem CVE zu beheben.

4. Prüf deine Rewrites. Jede rewrites()- oder redirects()-Regel, deren Zielhost aus einem Request-Parameter kommt, hat die Form von CVE-2026-64645. Statische Ziele sind in Ordnung.

5. Aktualisiere. Beide August-Fixes sind Patch-Releases auf einer Minor, npm install next@16.3.3 oder npm install next@15.5.24 sollte also unspektakulär sein. Lass deinen Build laufen, lass deine Tests laufen, deploy zuerst auf Staging, wenn du eins hast. Prüf dann, ob deine Bilder noch rendern, denn AVIF-Optimierung ist jetzt aus und dieser Pfad hat sich geändert.

6. Richte etwas ein, das dir das nächste Mal Bescheid sagt. Dependabot, Renovate oder npm audit in der CI. Irgendetwas davon. Der Grund, warum ich von diesem Release am Tag des Erscheinens erfahren habe, ist, dass ich den Next.js-Blog abonniert habe, nicht dass ich gewissenhaft bin. Automatisier es, denn gewissenhaft bleibst du nicht.

Wenn du die breitere Version der Schritte 3 bis 6 willst, habe ich sie in The Website Security Hardening Checklist (No Plugins, No BS) aufgeschrieben.

Was du mit einer Kundenseite machst, die auf Next 13 festgenagelt ist

Das ist die unangenehme Frage, und es ist die Situation, die die meisten erben statt erzeugen.

Patches landen nur in der Active-LTS- und der Maintenance-LTS-Linie. Aktuell sind das 16.x und 15.5.x. Wenn eine Seite auf Next.js 13.4 sitzt, kommt dafür kein Patch-Release. Der betroffene Bereich für CVE-2026-75604 beginnt bei 13.4, und der AVIF-Bereich beginnt bei 10.0.0, ein alter Pin liegt also für beide voll im Umfang.

Du hast drei ehrliche Optionen.

Über Major-Versionen upgraden. Das ist echte Arbeit: 13 auf 14 auf 15 auf 16, App-Router-Änderungen, next/image-API-Änderungen, asynchrone Request-APIs in 15. Rechne mit Tagen, nicht Stunden. Es ist trotzdem meistens die richtige Entscheidung.

Stattdessen die Fläche verkleinern. Wenn die Seite eine Broschürenseite ist, nimmt output: 'export' plus images: { unoptimized: true } den Bildoptimizer komplett aus der Gleichung. Es repariert das Framework nicht, es entfernt den Endpunkt.

Für verlängerten Support zahlen. HeroDevs und ähnliche Anbieter portieren Fixes auf EOL-Versionen zurück. Das ist ein echter Budgetposten, und für einen Kunden mit funktionierender Seite und ohne Lust auf einen Neubau ist es manchmal die günstigste Option auf dem Tisch.

Was du nicht tust, ist dem Kunden zu sagen, es sei schon in Ordnung. Schreib auf, welche Version, welches Host-Betriebssystem, welche CVEs zutreffen und was jede Option kostet. Lass sie mit echten Zahlen entscheiden. Meine Framework-Wahl für ein Kundenprojekt hängt meistens daran, wer es warten wird, und darauf wollte ich in WordPress, Next.js, or Astro? Here's How I Actually Decide for Client Projects im Wesentlichen hinaus.

Ist Next.js also unsicher?

Berechtigte Frage. Neun CVEs im Juli, zwei kritische im August, ein RSC-Fehler mit CVSS 10.0 im Dezember 2025 und die Middleware-Auth-Umgehung im März 2025, mit der man deine Auth durch Setzen eines Headers überspringen konnte. So aufgeschrieben sieht das schlecht aus.

Hier ist die ehrliche Antwort, und ich halte sie nicht für bequem.

Ein Framework, das dein Routing, dein Rendering, dein Caching, deine Bildverarbeitung und dein serverseitiges Datenholen übernimmt, hat schon per Definition eine enorme Angriffsfläche. Next.js dekodiert außerdem an einem halben Dutzend Grenzen nicht vertrauenswürdige Eingaben. Das ist viel Code, der viele feindselige Bytes anfasst.

Dazu kommt, dass die Entdeckungsrate wirklich gestiegen ist. Vercel sagt das direkt: Sie sind auf ein monatliches, vorab angekündigtes Release-Modell gewechselt, weil das Volumen der Schwachstellenforschung steigt, getrieben von LLM-gestützter Entdeckung. Sie fahren diese Werkzeugklasse selbst gegen Next.js, über ihr eigenes deepsec-Projekt und ein erweitertes Bug-Bounty. Mozilla hat aus derselben Art Werkzeug 271 Probleme in einem einzigen Firefox-Release offengelegt. Das ist kein Next.js-Phänomen.

Eine steigende CVE-Zahl ist also teilweise ein Messartefakt. Ein aktiv geprüftes Framework mit 45 Millionen wöchentlichen npm-Downloads produziert mehr CVEs als ein verwaistes. Das verwaiste hat die Fehler auch. Nur schaut niemand hin.

Das ist keine vollständige Verteidigung. Manches davon waren vermeidbare Designentscheidungen, und die Middleware-Umgehung vom März 2025 war insbesondere eine schlechte Vertrauensannahme, eingebacken in einen Header. Ein vorab angekündigter monatlicher Release-Takt heißt auch, dass es ein veröffentlichtes Fenster gibt, in dem Angreifer wissen, dass ein Patch kommt, und auf die Jagd gehen können. Das ist ein echter Zielkonflikt, und die Branche hat entschieden, dass der Planungsvorteil gewinnt.

Aber das Risiko, das Leuten tatsächlich wehtut, ist nicht die CVE-Zahl des Frameworks. Es ist die Seite, die 2023 gebaut wurde, live ging und seitdem nie ein npm install gesehen hat. Jedes dieser Advisories ist überlebbar, wenn du aktualisierst. Keines davon ist überlebbar, wenn du es nie tust. Dasselbe gilt für das npm-Supply-Chain-Problem und für das, was KI-Coding-Assistenten ungeprüft hereinziehen. Das Framework ist nicht die Variable. Wartung ist es.

Wo dich das hinstellt

Die Kurzfassung zur Next.js-CVE-Lage vom August 2026. Wenn du auf Vercel oder Netlify bist, warst du abgedeckt, bevor du das hier gelesen hast, und du solltest trotzdem bei Gelegenheit upgraden und neu deployen.

Wenn du auf Linux selbst hostest, gehört dir die Windows-RCE nicht. Das AVIF-Problem schon, und wie sehr es zählt, hängt davon ab, ob angreiferkontrollierte Bilder deinen Optimizer erreichen können. Upgrade diese Woche auf 16.3.3 oder 15.5.24 und rechne damit, dass deine AVIF-Bilder größer werden.

Wenn du auf Windows selbst hostest, hör auf zu lesen und upgrade. Für die gibt es keinen Workaround.

Und wenn du eine Kundenseite auf einer alten Major hast, die seit zwei Jahren niemand angefasst hat, sind die August-CVEs nicht das Problem. Sie sind die Benachrichtigung.

Wenn du eine Next.js-Seite geerbt hast und nicht sagen kannst, welche Version sie läuft, auf welchem Betriebssystem und wann sie zuletzt aktualisiert wurde, ist das ein Zwei-Stunden-Audit, kein Neubau. Ich mache die für Kunden auf wunderlandmedia.com, und meistens ist die Antwort weniger alarmierend, als die Schlagzeile nahegelegt hat.