Next.js außer der Reihe: die SVG-Bild-RCE und drei Checks

Wenn du eine Next.js-App deployst, prüf heute ihre Version. Das GitHub-Advisory GHSA-2464-fhr4-w9xw, als kritisch eingestuft mit einem CVSS-v4-Score von 9.5, beschreibt Remote Code Execution ohne Authentifizierung in der Image Optimization API, wenn SVG-Dateien verwendet werden und Next.js auf glibc-basiertem Linux läuft. Es braucht weder ein Konto noch eine Nutzeraktion. Die gefixten Releases sind 15.5.28 und 16.4.1. Viele PHP- und Node-Freelancer pflegen neben ihrem Backend ein Next.js-Frontend, deshalb lohnen sich hier zehn Minuten, auch wenn Next nicht dein Hauptstack ist.

Was im Advisory steht

Laut Advisory kann ein speicherbezogener Fehler in einer Upstream-Bibliothek, die Next.js zur Bildoptimierung nutzt, zu Remote Code Execution führen. Betroffen sind beim Paket next die Versionen 10.0.0 bis 15.5.27 und 16.0.0 bis 16.4.0. Der Workaround, falls du nicht sofort upgraden kannst: Stell sicher, dass die von Next.js genutzte sharp-Version 0.35.5 oder neuer ist. Eine frische Installation bekommt ein gefixtes sharp, und ein Upgrade von Next.js auf ein gepatchtes Release lässt den Paketmanager eines nachziehen. Das Advisory verweist auf CVE-2026-96889 und nennt randomguy6407 und rafabd1 als Finder.

Der Tracker pwn.watch liefert Kontext, den ich selbst nicht mit den anderen Advisories abgleichen konnte. Demnach hat Vercel 16.4.1 und 15.5.28 am 14. Oktober 2026 außer der Reihe veröffentlicht, der SVG-Fehler ist ein Use-after-free in librsvg, der über sharp erreicht wird, und dasselbe Release behebt eine zweite kritische RCE (GHSA-673q-mjm6-r5xr, App-Router-Apps mit Cache Components) sowie einen Denial of Service mit hohem Schweregrad in Server Actions (GHSA-p3m5-59mp-jv5r). Außer der Reihe heißt: Der Hersteller wollte nicht auf den regulären Release-Zyklus warten. Nimm das als Signal für die Dringlichkeit.

Warum ein Bildparser Code ausführen kann

Das ist allgemeines Wissen, kein Detail aus dem Advisory. Bildverarbeitung in Node ist meist nativer Code: sharp ist eine JavaScript-Schicht über C-Bibliotheken wie libvips und librsvg, und die laufen in deinem Node-Prozess. Ein Speicherfehler dort wird nicht von der Sicherheit von JavaScript eingefangen; es ist ein Fehler in deiner Anwendung, mit deinen Umgebungsvariablen und deinem Dateisystem. SVG vergrößert die Angriffsfläche, weil es ein Dokumentformat mit einem vollständigen Parser dahinter ist und kein Pixelraster.

Das Advisory nennt glibc-basiertes Linux. Es sagt nicht, dass andere Plattformen sicher sind. Wenn dein Image also Alpine oder etwas anderes ist, upgrade trotzdem, statt dir die Sache schönzurechnen.

Drei Checks

npm ls next sharp
grep -n '"version"' node_modules/sharp/package.json
docker exec my-next-app id -u

Die ersten beiden führst du im Projekt aus, den dritten gegen den laufenden Container, denn der Lockfile auf deinem Laptop und das Image in Produktion können sich widersprechen. Dann behebst du, was die Checks zutage fördern:

npm install next@16.4.1   # or next@15.5.28 on the 15 line
npm ls sharp              # expect 0.35.5 or later
docker build --pull -t my-next-app .

Zwei Gewohnheiten, als allgemeine Praxis und nicht als Vorgabe des Advisorys: Beschränke mit images.remotePatterns in deiner Next-Config, was der Optimizer abrufen darf, damit er nur Bilder von Hosts verarbeitet, die du nennst, und lass die App im Container als Nicht-root-User laufen. Keins von beiden ersetzt das Upgrade. Nächster Schritt: Führ die drei Checks bei jeder Next.js-App aus, die du deployst, auch bei dem Kundenprojekt, das du seit dem Frühjahr nicht angefasst hast.

Quelle: GitHub Advisory Database, GHSA-2464-fhr4-w9xw.