Der Next.js-Juli-Patch trifft dein Projekt nur unter sechs Voraussetzungen

Wenn im npm-Audit auf einmal neun offene CVEs für ein einziges Paket stehen, ist die erste Reaktion meistens Hektik. Beim Next.js-Release vom 20. Juli 2026 ist das nicht anders. Vier High, fünf Medium, Nummern von CVE-2026-64641 bis CVE-2026-64649, alle in einem Rutsch veröffentlicht. Wer mehrere Kundenprojekte betreut, hat dann die gleiche Frage in mehrfacher Ausfertigung auf dem Tisch, nämlich ob dieses konkrete Projekt jetzt ein Problem hat oder nicht.

Die Antwort hängt an sechs Voraussetzungen. Nicht an neun einzelnen Recherchen. Wenn du die sechs einmal durchgehst, weißt du für jedes Projekt, was Sache ist.

Was am 20. Juli erschienen ist

Der Blogbeitrag auf nextjs.org ist auf den 20. Juli 2026 datiert, Autoren sind Andrew Imm, Josh Story und Sebastian Silbermann. Das eigentliche Release lief einen Tag später über die Bühne, Netlifys Changelog trägt den 21.07., die OSV-Einträge sind mit dem 22.07. veröffentlicht. Für die Praxis reicht es, sich Ende Juli 2026 zu merken.

Foto: sigmund / Unsplash

Gepatcht ist in zwei Versionen, 16.2.11 für den Active-LTS-Zweig und 15.5.21 für Maintenance LTS. Die Fixes stecken zusätzlich in 16.3.0-canary.92 und 16.3.0-preview.7 und kommen mit dem stabilen 16.3.0 regulär mit.

# Patch einspielen, genau so im Next.js-Blog angegeben
npm install next@15.5.21  # for 15.5
npm install next@16.2.11  # for 16.2

Neu ist auch der Rahmen drumherum. Vercel hat am 13.07.2026 ein vorangekündigtes Security-Release-Modell eingeführt, also etwa monatlich ein Vorabhinweis im Blog mit erwartetem Termin und höchster erwarteter Schwere. Bei diesem Release hat das funktioniert, die Vorankündigung nannte bereits die Verteilung von vier High und fünf Medium sowie die Zweige 16.2 und 15.5, bevor irgendein Detail draußen war. Als Begründung für den Rhythmus nennt Vercel den stark steigenden Fundstrom durch LLM-gestützte Sicherheitsforschung und verweist auf Mozilla, das in einem einzigen Firefox-Release 271 Issues offengelegt hat, gefunden mit Anthropics Mythos Preview. Vercel setzt dafür eigene Werkzeuge ein, unter anderem deepsec.

Erst die Version, dann alles andere

Bevor du eine einzige Lücke prüfst, klärst du, ob dein Projekt überhaupt einen Fix bekommen kann.

npm ls next
npm why next

Steht dort 16.x oder 15.5.x, ist der Rest dieses Artikels für dich relevant. Steht dort 14.x oder 13.x, hast du ein anderes Problem. Laut Support-Policy ist 16.x Active LTS (Release 21.10.2025) und 15.x Maintenance LTS (Release 21.10.2024), und Maintenance LTS läuft zwei Jahre nach dem Release aus, für 15.x also am 21.10.2026. Alles davor ist raus. Mehrere der neun Advisories nennen als unteren Rand des betroffenen Bereichs 12.0.0 oder 13.0.0, gepatcht wurde aber nur in 15.5.21 und 16.2.11. Auf 14.x bekommst du also die Bestätigung, dass du betroffen bist, und keinen Fix dazu. Dann ist die Migration auf einen LTS-Zweig die Aufgabe, nicht der Patch.

Der Normalfall trifft dich schon zweimal

Die Voraussetzung “App Router mit mindestens einer Server Action” ist keine Nische, das ist der Normalfall moderner Next.js-Projekte. Und genau daran hängen zwei Punkte. CVE-2026-64641 ist ein Denial of Service über Server Actions, High, CVSS 4.0 mit 8.2, CWE-834 für exzessive Iteration. Betroffen sind >=13.0.0 <15.5.21 und >=16.0.0 <16.2.11. Es gibt keinen Workaround außer dem Upgrade. Dazu kommt CVE-2026-64643, Medium mit 6.3, wo interne Server-Function-Endpunkte unauthentifiziert offengelegt werden, weil die Endpoint-IDs in öffentlich abrufbaren Client-Artefakten stecken. Das betrifft Server Actions und 'use cache' gleichermaßen.

Wer den Pages Router fährt oder keine einzige Server Action hat, ist bei beiden Punkten außen vor. Alle anderen haben mindestens zwei Treffer, davon einen High. Die Standardinstallation kommt also nicht ungeschoren davon, sie kommt nur nicht neunfach betroffen davon.

Foto: kellysikkema / Unsplash

Die sechs Voraussetzungen

Die neun CVEs verteilen sich auf sechs Bedingungsklassen. Das ist die Liste, an der ich Projekte durchgehe.

1. App Router mit mindestens einer Server Action. Trägt CVE-2026-64641 (High, 8.2) und CVE-2026-64643 (Medium, 6.3). Läuft die Action in der Edge-Runtime, kommt CVE-2026-64646 dazu, ein unbegrenzter Request-Payload, Medium mit 6.3 und CWE-770. Als Workaround nennt das Advisory ein Body-Limit von rund 5 MiB beim Hoster. Zur Einordnung, das Default-Limit für Server-Action-Bodies liegt laut Doku bei 1 MB und ist über serverActions.bodySizeLimit konfigurierbar.

2. App Router plus Turbopack-Build plus genau ein Eintrag in config.i18n.locales. Das ist CVE-2026-64642, ein Middleware- und Proxy-Bypass, High mit 8.3, CWE-285, und ausschließlich im 16er-Zweig. Diese Mischkonstellation entsteht leicht, weil der i18n-Schlüssel in der next.config eigentlich die Pages-Router-Internationalisierung ist und in Projekten hängen bleibt, die längst auf App Router umgestellt haben. Das Advisory formuliert nur “built with Turbopack”, ob ausschließlich der Production-Build gemeint ist, steht dort nicht.

3. Selbst gehostete Bildoptimierung mit erlaubten Remote-Hosts. CVE-2026-64644, ein DoS in der Image-Optimization-API über SVGs, Medium mit 6.3. Betroffen sind 15.5.0 bis 15.5.20 und 16.0.0 bis 16.2.10, aber nur bei Self-Hosting mit dem Default-Loader und gesetzten config.images.remotePatterns. Wer images.unoptimized: true oder loader: 'custom' fährt, ist raus, Vercel-Hosting ebenfalls.

4. rewrites oder redirects mit dynamisch gebautem Ziel-Hostnamen. CVE-2026-64645, High mit 8.3, reicht zurück bis 12.0.0. Sobald der externe Ziel-Hostname aus Request-Input entsteht, also aus dynamischen Segmenten im Pfad oder aus has-Capture-Groups, wird aus einem rewrite ein SSRF und aus einem redirect ein Open Redirect.

5. Server Actions auf einem Custom Server ohne Host-Pinning. CVE-2026-64649, High mit 8.3, betroffen ab 14.1.1. Voraussetzung ist, dass der Client die host-bezogenen Header kontrollieren kann. Managed Hosting sowie next start und standalone-Deployments ab 14.2 sind laut Advisory standardmäßig geschützt.

6. Zwei Sonderfälle beim fetch-Cache. CVE-2026-64647 ist eine Cache-Confusion bei Bodies mit ungültigen UTF-8-Sequenzen, Medium mit 6.3 und hoher Angriffskomplexität. Zwei unterschiedliche UTF-16-Bytefolgen landen dabei im selben Cache-Eintrag. CVE-2026-64648 ist eine zweite Cache-Confusion, die nur bei einer bestimmten Aufrufform greift. Beide setzen den App Router voraus.

Fünf-Minuten-Triage

Sechs Prüfungen, mehr braucht es nicht.

# 1) Gibt es überhaupt eine Server Action? (CVE-2026-64641, -64643, -64646)
grep -rn "use server" app/ src/ --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx"

# 2) Turbopack und i18n in derselben Konfiguration? (CVE-2026-64642, nur 16.x)
grep -n "i18n" next.config.*
grep -n "turbopack\|--turbopack" next.config.* package.json

Bei Treffer in Schritt 2 zählst du die Locales. Nur diese Konstellation ist verwundbar.

// next.config.js
module.exports = {
  i18n: {
    locales: ['de'],      // genau EIN Eintrag = betroffen
    defaultLocale: 'de',
  },
}

Schritt 3 ist ein Blick auf den Bild-Block. Sobald remotePatterns gesetzt ist und du selbst hostest, bist du drin.

module.exports = {
  images: {
    remotePatterns: [{ protocol: 'https', hostname: '**.example.com' }],
  },
}
// nicht betroffen: images.unoptimized === true oder images.loader === 'custom'

Muss das Upgrade aus irgendeinem Grund warten, nennt das Advisory für diesen Punkt einen Konfigurationsschalter.

module.exports = {
  experimental: {
    imgOptSkipMetadata: true,
  },
}

Schritt 4 ist Handarbeit an den rewrites. Gefährlich ist jedes Muster, bei dem ein Teil des Hostnamens aus der URL kommt.

// verwundbar: Ziel-Hostname wird aus Request-Input gebaut
async rewrites() {
  return [{ source: '/api/:region/:path*', destination: 'https://:region.api.example.com/:path*' }]
}
// Advisory-Empfehlung: Werte auf hostname-sichere Zeichen einschränken
// value: '(?<region>[a-z0-9-]+)'

Schritt 5 betrifft nur Custom Server und Deployments ohne Upstream-Host-Pinning.

# Ab 14.2.0 laut Advisory als Mitigation:
export __NEXT_PRIVATE_ORIGIN="https://deine-echte-domain.de"
# zusätzlich Host und X-Forwarded-Host am Proxy pinnen

Schritt 6 ist eine Suche nach der einen fetch-Form, die kippt.

fetch(new Request(init), aDifferentInit)   // betroffen
fetch(new Request(init), init)             // unauffällig
fetch(url, init)                           // unauffällig, der Normalfall

Zwei der Advisories laufen inhaltlich auf dieselbe Empfehlung hinaus, nämlich die Autorisierung an die Server-Grenze zu ziehen statt sie allein in der Middleware oder auf Seitenebene zu erledigen.

'use server'

export async function deleteProject(id: string) {
  const session = await getSession()          // Prüfung IN der Action
  if (!session) throw new Error('Unauthorized')
  // ...
}

Was das Hosting abnimmt und was nicht

Netlify hat nach eigener Angabe drei der neun Punkte auf Plattformebene abgefangen. Bei CVE-2026-64649 überschreibt die Edge ein eingehendes X-Forwarded-Host mit dem echten Host, bei CVE-2026-64644 übernimmt das Image CDN den Pfad /_next/image, und bei CVE-2026-64646 greifen gedeckelte Request-Bodies und isolierte Invocations. Die übrigen sechs erfordern trotzdem das Upgrade. Für Vercel nennt das Advisory zu CVE-2026-64644 ausdrücklich Nichtbetroffenheit. Zu anderen Plattformen liegt mir nichts vor, und für eigene Server ist die Annahme ohnehin einfach, dort ist nichts abgefangen.

Foto: thisisengineering / Unsplash

Interessant ist, wie stark reine Build- und Deployment-Entscheidungen die Betroffenheit verschieben. Laut Advisory GHSA-89xv-2m56-2m9x sind standalone- und next start-Deployments ab 14.2 gegen die Server-Action-SSRF standardmäßig geschützt, weil sie den Host upstream festnageln. Wer output: "standalone" gesetzt hat, hat diesen High-Punkt also womöglich schon vom Tisch, und zwar wegen einer Entscheidung, die meistens aus ganz anderem Anlass fällt, etwa um das Docker-Image zu verkleinern. Verlassen sollte sich darauf trotzdem niemand, ohne in der eigenen Konfiguration nachzusehen. Wer sich generell fragt, was Self-Hosting an Verantwortung mitbringt, findet in meinem Vergleich von Hetzner mit AWS und Azure die andere Hälfte dieser Rechnung.

Was der Monatsrhythmus für die Wartung ändert

Der angekündigte Monatstakt ist für die Planung die eigentliche Neuigkeit. Bisher kamen Next.js-Security-Fixes ohne Vorwarnung, jetzt gibt es in der Regel einen Vorlauf mit Termin und Schweregrad. Vercel nennt als Zweck ausdrücklich auch, in dieser Zeit mit Hosting-Partnern Mitigationen wie Firewall-Regeln für noch ungepatchte Apps abzustimmen. Für dich heißt das, dass ein Wartungsfenster im Monatsrhythmus zur planbaren Größe wird statt zur Feuerwehrübung. Ob für August 2026 schon ein Termin steht, ist offen, im Blog war zum Rechercheschluss am 27.07. nichts gelistet.

Wichtig bleibt, dass das Upgrade selbst überschaubar ist. Ein Sprung innerhalb eines LTS-Zweigs, etwa von 16.2.10 auf 16.2.11, ist ein Patch-Release und kein Umbau. Wer seine Abhängigkeiten ohnehin automatisiert aktualisiert, sollte allerdings prüfen, ob die eigenen Regeln solche Fixes nicht ausbremsen, denn eine Karenzzeit für neue Paketversionen wirkt bei einem Security-Patch in die falsche Richtung. Wie ich das für mich gelöst habe, steht in meinem Beitrag zur Dependabot-Cooldown-Regel.

Foto: jakewalker / Unsplash

Am Ende bleibt für die meisten Projekte eine kurze Liste. Version prüfen, sechs Bedingungen durchgehen, next auf 16.2.11 oder 15.5.21 heben, deployen. Der Aufwand steckt nicht im Patch, sondern in den Projekten auf 13.x und 14.x, für die es keinen gibt.

Wenn du nicht sicher bist, welche der sechs Konstellationen bei dir zutreffen, oder wenn ein Projekt auf einer Version steht, die keine Fixes mehr bekommt, schreib mir kurz. Ich schaue mir next.config, Router-Setup und Deployment-Pfad an und sage dir, was davon wirklich anzufassen ist.