Die zwei Next.js-Fixes, die September versprach, sind da

Am 14. Oktober hat Next.js das Security-Update ausgeliefert, das es im September verschoben hatte: 16.4.1 und 15.5.28 schließen die kritische Remote Code Execution in use cache und die Server-Actions-Denial-of-Service, die auf Upstream-Koordination warteten, und ergänzen einen Fix für eine zweite kritische Lücke im Bildoptimierungspfad. Beide Linien sind betroffen, beide haben Patches.

Welche der drei Lücken erreicht deine App?#

Die verschobene kritische Lücke, GHSA-673q-mjm6-r5xr: nicht authentifizierte RCE in Anwendungen mit App Router und Cache Components, ausgelöst, wenn eine use cache-Funktion mehrere typisierte Arrays zurückgibt. Das Upstream-Advisory liegt bei React als GHSA-xqc2-xf4c-x3h3, und The Hacker News setzt die betroffenen react-server-dom-Pakete zwischen 19.0.0 und 19.3.0 an. Next.js nennt keinen Workaround und bittet um ein sofortiges Upgrade, auch wenn eine Anwendung solche Funktionen gar nicht definiert.

Die neue kritische Lücke, CVE-2026-96889 / GHSA-2464-fhr4-w9xw: eine speicherbezogene Schwachstelle in einer Upstream-Library hinter der Image Optimization API wird ausnutzbar, wenn Next.js auf glibc-basiertem Linux läuft und SVG-Dateien in die Pipeline geraten. Der genannte Workaround ist sharp ab 0.35.5, und ein Next.js-Upgrade zieht eine gefixte sharp-Version automatisch nach. The Hacker News ergänzt den Kontext: gemeldet von Rafael B. Dias über Vercels Open Source Bug Bounty, upstream in librsvg 2.63.2 gefixt, und zweifach bewertet, Red Hat mit 7,8, während Next.js ihn als critical listet.

Die verschobene DoS, GHSA-p3m5-59mp-jv5r: konstruierte Requests gegen App-Router-Anwendungen mit mindestens einer Server Action können einen Prozess auf volle CPU lasten, bis er nicht mehr antwortet. Anwendungen auf Pages Router oder ohne Server Actions sind nicht verwundbar.

Die Advisories gegen diese Seite geprüft#

Diese Seite ist der statisch prerenderte Next.js-16-Build aus dem Lighthouse-Bericht, exakt gepinnt, selbst gehostet auf einem glibc-VPS. Sie lief seit dem geplanten September-Release auf 16.3.8, das der September-Bericht abdeckt, und 16.3.8 fällt in das betroffene Versionsfenster des Image-Advisory: größer als 16.0.0, höchstens 16.4.0.

Die Konfiguration beantwortet die anderen beiden. Keine Cache Components, kein use cache, also hat die RCE keine Angriffsfläche. Keine Server Actions, also verfehlt die DoS die Anwendung nach ihrer eigenen Bedingungszeile. Die OG-Bilder rendern über ImageResponse aus next/og, und kein Codepfad legt eine SVG in den Optimizer, aber sharp reist über Next selbst im Baum mit, und das Lockfile dieses Repositorys trug 0.35.4: genau einen Release unter der Fix-Version, auf exakt der Plattformklasse, die das Advisory nennt.

Das Upgrade war heute ein Befehl: npm install --save-exact next@16.4.1. sharp ist selbstständig auf 0.35.5 gewandert, genau wie das Advisory es verspricht. 32 Tests in 4 Dateien kamen grün zurück, und der Produktionsbuild lief beim ersten Durchlauf sauber. Vom Patch-Release bis zu dieser Seite: vier Tage. Dasselbe Fenster im September: vierzehn.

Die Audit-Lücke und die Bild-Pipeline#

Zwei Details reichen über dieses Release hinaus. Die use cache-Lücke existiert nur als GHSA-Identifier, ohne CVE zum Zeitpunkt der Veröffentlichung, und The Hacker News hat nachgeprüft: npm audit blieb bis zum 15. Oktober stumm. Ein Dependency-Scanner war nicht der Entdeckungskanal für die schwerste Lücke des Batch, also bleibt der Advisory-Feed auf der Beobachtungsliste.

Und das ist die dritte RCE in der Bildverarbeitung seit August, nach libheif im AVIF-Pfad und der Satori-Schwachstelle in next/og, die das September-Out-of-Band-Release gefixt hat. Das Muster für alle, die selbst hosten: Die Bild-Pipeline ist ein wiederkehrender Eingangspunkt, sharp reist als Fremd-Dependency mit, und seine Version verdient dieselbe Aufmerksamkeit wie die von Next selbst.

Zwei Tage später machte der andere Runtime-Notfall der Woche diesen hier ruhig aussehen: PHP patchte zwei RCE-Lücken im Kern, mit demonstriertem Exploit gegen Standardeinstellungen und einer leckgestörten Veröffentlichung.