Das Next.js Security Release vom November 2026 liefert Patches in next@16.4.5 (Active LTS) und next@15.5.29 (Maintenance LTS). Laut dem offiziellen Next.js-Blogpost betreffen die Findings vor allem Cache-Komponenten, Response-Framing und Image Optimization – inklusive einer High-Severity-Cache-Disclosure. Exploit-Schritte und PoCs gehören nicht in diesen Artikel; Fokus sind Impact und Patch-Hinweise.
Betreiber sollen Abhängigkeiten zeitnah aktualisieren. Die Terminal-Empfehlung aus dem Blog: npm install next@15.5.29 für die 15.5-Linie und npm install next@16.4.5 für 16.x (Kommentar im Blog erwähnt 16.5-Linie; die veröffentlichte Patch-Version ist 16.4.5). Vor dem Update: eigene Regressionstests auf Caching, Prefetch und Edge-Routen.
Next.js Security Release: High – Cross-Tenant-Cache
GHSA-mfr8-8qww-v76h (High): Wenn Cache Components aktiv sind und dieselbe öffentliche use cache-Funktion sowohl direkt als auch aus unstable_cache heraus aufgerufen wird, kann gecachter Inhalt über Root-Parameter hinweg offengelegt werden – sofern die Funktion einen Root-Parameter liest (z. B. Tenant-ID).
Bei kaltem Cache-Fill kann ein paralleler Aufruf über unstable_cache das Ergebnis eines anderen Requests erhalten, ohne dessen Root-Parameter zu prüfen. Dieses Ergebnis kann gespeichert und späteren Callern mit denselben Argumenten ausgeliefert werden, bis Revalidation oder Eviction. Trennen Root-Parameter Tenants, kann fremde Tenant-Daten im Resultat landen. Das ist kein generischer „Cache aus“-Befehl – sondern ein konkretes Kombinationsmuster aus unstable_cache + use cache unter Cache Components.
Medium: Nested use cache und binäre Argumente
GHSA-vc7v-qv4w-wrv8 (Medium): Nested öffentliche use cache-Funktionen können Inhalt für einen Root-Parameter-Wert an Requests für einen anderen ausliefern. Betroffen sind Apps, in denen eine innere Cache-Funktion einen Root-Parameter liest und früh einen Wert zurückgibt, während ein langsamerer asynchroner Wert noch läuft und die äußere Funktion ohne Warten darauf endet. Der äußere Cache-Eintrag kann gespeichert werden, bevor Root-Parameter-Abhängigkeiten der inneren Funktion erfasst sind. Der Angreifer injiziert keinen beliebigen Response-Inhalt; die App erzeugt den Inhalt, der falsch wiederverwendet wird.
GHSA-rhh4-g77r-r9qj (Medium): Unterschiedliche binäre Argumente an eine use cache-Funktion können dieselbe Cache-Identität erzeugen. Wenn die App diese Argumente nutzt, um Nutzer oder Accounts zu trennen, und die übrigen Identity-Inputs gleich sind, kann ein Caller das gecachte Resultat eines anderen Nutzers erhalten – oder das eigene Resultat an einen anderen ausliefern lassen. Beliebiger Zugriff auf unrelated Cache-Entries ist damit nicht gemeint.
Medium: Shared Shell, Framing, Cookies, SVG
Shared Shell Cache Poisoning (Medium): Self-hosted Apps mit next start, aktivierten Cache Components und deaktiviertem bzw. unset Partial Prefetching können eine gemeinsame Page-Shell durch einen unauthentifizierten Request vergiften. Eine crafted URL kann request-spezifische Werte in einer Shell speichern, die andere URLs mitnutzen – falsch gerenderter Inhalt oder persistente 404s. Betroffen laut Report: bestimmte Route-Formen mit prerenderbarem Dynamic-Parameter (Wert nicht zur Build-Zeit generiert), mindestens zwei tieferen Parametern ohne Prerender und blocking Fallback-Shell; ein Layout liest den flacheren der tieferen Parameter in einer Suspense-Boundary. Build-generierte Werte und Konfigurationen mit Partial Prefetching waren in den genannten Tests nicht betroffen.
GHSA-pc58-hwjq-p385 (Medium): Self-hosted Apps, die eine angreifer-kontrollierte gefetchte Response unverändert zurückgeben, können dekomprimierte Body-Bytes mit den Framing-Headern der ursprünglich komprimierten Response weiterreichen. Hinter einem HTTP/1.1-Reverse-Proxy, der pipelined Requests auf einer shared Backend-Connection queued, können Responses den falschen Clients zugeordnet werden. Das gilt nicht für jede Proxy-Konfiguration.
GHSA-f3mh-rxg3-f5g2 (Medium): Edge Route Handlers (App Router) und Pages-Router Edge-API-Routen, die Cookies via NextResponse.cookies.set() setzen, können den serialisierten Cookie im internen Header x-middleware-set-cookie exponieren. Anders als Set-Cookie kann dieser Header von same-origin JavaScript gelesen werden – auch bei HttpOnly. Voraussetzung: sensitiver Cookie auf betroffener Response plus angreifer-kontrolliertes JS auf derselben Origin. Kein eigenständiger JS-Execution-Vektor. Node.js Route Handlers und cookies().set() waren im reproduzierten Leak nicht betroffen.
GHSA-7qx7-33qx-rqx2 (Medium): Ein angreifer-kontrolliertes Bild aus einer erlaubten Quelle kann als AVIF fehlklassifiziert werden und images.dangerouslyAllowSVG: false umgehen. Das Image-Optimization-Backend kann die Original-Bytes als SVG erkennen und dekodieren – gegen die konfigurierte Ausschluss-Absicht. Die Image-Source-Allowlist gilt weiter; nötig ist ein natives Image-Backend mit SVG-Decode. Erhöht Exposition gegenüber SVG-Parser-Ressourcenerschöpfung oder Decoder-Bugs; XSS/RCE ist damit nicht demonstriert.
Einordnung und interne Bezüge
Das Next.js Security Release ist ein gebündeltes Advisory mit einem High- und mehreren Medium-Findings – kein einzelner CVE-Nummer-Block im Blogtitel. Für Teams mit Multi-Tenant-Routing und Cache Components ist GHSA-mfr8 prioritär. Self-hosted Setups ohne Partial Prefetching sowie Edge-Cookie-Flows und Image-Optimization-Pipelines brauchen eigene Checklisten.
Verwandte Next.js-Security-Coverage bei code404zero: das September-2026-Sicherheitsupdate, der Next.js-16.4-Release zu Cache Components und die Image-Optimization-SSRF CVE-2026-94483. Wer Cache Components erst kürzlich freigeschaltet hat, sollte Patch und Config-Review zusammen planen.
Was Betreiber jetzt tun sollten
1) Patch auf 16.4.5 bzw. 15.5.29 in Staging, dann Produktion. 2) Audit auf Kombinationen unstable_cache + use cache mit Root-Params. 3) Nested use cache und binäre Cache-Args gegen Tenant-/User-Trennung prüfen. 4) Self-hosted: Partial Prefetching und Shell-Verhalten gegen das Advisory halten. 5) Edge-Routen: Cookie-Set via NextResponse.cookies.set() reviewen. 6) Image Optimization: SVG-Policy und erlaubte Sources gegen GHSA-7qx7 halten.
Security-Programme: Vercel verweist auf das Open Source Bug Bounty; Fragen an security@vercel.com. Für diesen Artikel gilt: Impact und Patch aus dem Blog – keine Exploit-Anleitungen, keine reproduzierbaren Payloads.
Kurz: Das Next.js Security Release November 2026 patched next@16.4.5 und next@15.5.29. High ist die Cross-Tenant-Cache-Disclosure GHSA-mfr8; dazu mehrere Medium-Findings zu nested Cache, binären Args, Shell-Poisoning, Framing, Cookie-Leak und SVG-Bypass. Primärquelle: Next.js-Blog. Patchen, Config prüfen, keine Exploit-Schritte nachbauen.
