Was ist passiert?

Vercel veröffentlichte am 14. Oktober 2026 eine Sicherheitsmeldung zu einer Speicherlücke in einer vorgelagerten Bibliothek, die Next.js für die Bildoptimierung verwendet. Wenn Next.js auf Linux mit glibc läuft und SVG Dateien verarbeitet werden, kann die Schwachstelle laut Meldung zu einer möglichen Ausführung von Code führen. Vercel führt die Lücke deshalb als kritisch.

Betroffen sind das npm Paket next in den Versionsbereichen >=10.0.0 <=15.5.27 sowie >16.0.0 <=16.4.0. Behoben ist das Problem in Next.js 15.5.28 und 16.4.1. Die offiziellen Veröffentlichungen vom selben Tag nennen den Sicherheitshinweis ausdrücklich. Technische Exploit Details enthält die Meldung nicht, und sie trifft keine Aussage darüber, ob die Lücke bereits aktiv ausgenutzt wurde.

Verbindliche Angaben zu Umfang und Abhilfe stehen im Sicherheitshinweis von Vercel.

Für Anwendungen mit eigenem Produktkern unterstützt unsere Software-MVP-Entwicklung auch bei einem strukturierten technischen Betrieb.

Wer ist betroffen?

Prüfbedarf besteht bei Next.js Anwendungen, wenn drei Merkmale zusammenkommen: Die installierte Next.js Version liegt in einem der genannten Bereiche, der Betrieb erfolgt auf einem glibc basierten Linux System und die Image Optimization verarbeitet SVG Dateien. Ob eine Website diese Kombination nutzt, sollte nicht aus der sichtbaren Oberfläche abgeleitet werden. Maßgeblich sind die tatsächlich installierten Pakete, die Laufzeitumgebung und die Bildpfade der Anwendung.

Der betroffene Pfad führt von einer Bildanfrage über die Next.js Bildoptimierung zur verwendeten Bibliothek und weiter in die Linux Laufzeit. Das Diagramm ordnet diese Abhängigkeit ein, ohne einen Angriff nachzustellen. Wer andere Template oder Rendering Risiken bewertet, findet in unserem Beitrag zur Handlebars Schwachstelle ein weiteres Beispiel dafür, warum transitive Bibliotheken in der Bestandsaufnahme sichtbar sein müssen.

Ein verwandtes Beispiel beschreibt der Artikel Handlebars AST Injection.

Ablauf einer Bildanfrage durch Next.js, sharp und die Linux Laufzeit mit hervorgehobenem Update
Der relevante Verarbeitungspfad reicht von Next.js über sharp bis zur Linux Laufzeit. Das Update schließt die bekannte Lücke.

Zwei Minuten Check

Beginnen Sie im Verzeichnis der bereitgestellten Anwendung mit zwei lesenden Abfragen. npm ls next --depth=0 zeigt die direkt installierte Next.js Version. npm ls sharp --all macht sichtbar, welche sharp Versionen im gesamten Abhängigkeitsbaum vorhanden sind. Dokumentieren Sie die Ausgabe zusammen mit Commit, Umgebung und Zeitpunkt, damit der spätere Vergleich eindeutig bleibt.

Ein Eintrag in package.json allein genügt nicht, weil Versionsbereiche und Lockfile über die tatsächlich installierte Version entscheiden. Prüfen Sie zusätzlich, ob die produktive Laufzeit Linux mit glibc verwendet und ob SVG Dateien durch die Next.js Bildoptimierung laufen. Für den Funktionstest sollten ausschließlich kontrollierte interne Testdateien verwendet werden. Laden Sie keine unbekannten SVG Dateien aus externen Quellen in eine produktive Prüfung.

Installierte Versionen prüfen
npm ls next --depth=0
npm ls sharp --all
Terminal mit den Befehlen npm ls next und npm ls sharp
Die beiden Abfragen zeigen die installierte Next.js Version und alle sharp Vorkommen im Abhängigkeitsbaum.

Was jetzt zu tun ist

Legen Sie zuerst einen belastbaren Wiederherstellungspunkt fest, etwa ein geprüftes Deployment Artefakt, einen Snapshot oder einen klaren Rollback auf die vorherige Revision. Aktualisieren Sie anschließend passend zum verwendeten Hauptzweig: Anwendungen auf Next.js 15 auf mindestens 15.5.28, Anwendungen auf Next.js 16 auf mindestens 16.4.1. Die Release Seiten für 15.5.28 und 16.4.1 bestätigen den kritischen Sicherheitshinweis.

Installieren Sie danach deterministisch anhand des vorhandenen Lockfiles neu. Bei npm ist npm ci der übliche Weg für eine reproduzierbare Installation. Löschen Sie das Lockfile nicht pauschal, denn dadurch können sich viele weitere Abhängigkeiten unkontrolliert verändern. Führen Sie den Build und die vorhandenen automatisierten Tests aus. Testen Sie relevante Bildpfade einschließlich SVG mit kontrollierten internen Assets, veröffentlichen Sie über den normalen Deployment Prozess und beobachten Sie anschließend Anwendungs-, Plattform- und Fehlerprotokolle.

Die korrigierten Versionen sind in den offiziellen Releases Next.js 15.5.28 und 16.4.1 dokumentiert.

Das Release für den neuen Hauptzweig steht unter Next.js 16.4.1.

Für eine systematische Prüfung von API und Auslieferung bietet unser Leitfaden WordPress REST API aktivieren und Fehler beheben übertragbare Hinweise zur kontrollierten Fehlersuche.

Übergangsmaßnahmen

Falls das Next.js Update nicht sofort möglich ist, nennt Vercel sharp ab Version 0.35.5 als Workaround. Frische Installationen erhalten die korrigierte sharp Version automatisch. Ein Upgrade von Next.js auf 15.5.28 oder 16.4.1 stellt laut Hinweis ebenfalls sicher, dass Paketmanager die korrigierte sharp Version bereitstellen. Die vollständige Next.js Aktualisierung bleibt die bevorzugte Maßnahme, weil sie den vom Hersteller vorgesehenen, getesteten Stand herstellt.

Auch bei einem kurzfristigen sharp Update gelten dieselben Kontrollen: Lockfile bewusst aktualisieren, den resultierenden Abhängigkeitsbaum prüfen, Build und Bildpfade testen und regulär ausrollen. Halten Sie fest, warum die Übergangslösung gewählt wurde und bis wann das Next.js Update folgt. Weitere technische Einordnungen und Betriebschecks sammeln wir im Magazin.

Weitere Beiträge finden Sie im devvibe Magazin.

Grenzen und Einordnung

Der Sicherheitshinweis beschreibt eine mögliche Remote Code Execution unter den genannten Bedingungen. Er liefert jedoch keine Exploit Details, keine Aussage zu bekannter Ausnutzung und keine weitergehende Liste konkreter Angriffsvoraussetzungen. Daraus folgt eine klare Priorität für das Update, aber kein belastbarer Anlass für Spekulationen über bereits erfolgte Angriffe. Betreiber sollten Fakten aus Paketbestand, Plattform und Protokollen sichern und diese getrennt von Annahmen dokumentieren.

Nach dem Update sollte die neue Version erneut mit npm ls geprüft und das Ergebnis dem Ausgangsstand gegenübergestellt werden. Bei Auffälligkeiten in Logs oder Deployment sollte zuerst der definierte Wiederherstellungsweg greifen. Wer Unterstützung bei Bestandsaufnahme, Test und kontrollierter Aktualisierung einer individuellen Anwendung benötigt, kann uns mit den vorhandenen Versionsdaten und der Betriebsumgebung ansprechen.

Für eine konkrete technische Einschätzung erreichen Sie uns über Kontakt.