Technik & Sicherheit · · 7 Min. Lesezeit
Zwei kritische Next.js-Lücken: Was müssen Sie jetzt tun?
Für Next.js sind zwei kritische Sicherheitslücken bestätigt. Ob Ihre Firmenwebsite, Ihr Shop oder Kundenportal betroffen ist, hängt von Funktionen und Versionen ab. Lassen Sie das produktive Deployment prüfen: den tatsächlich bereitgestellten Stand Ihrer Anwendung. Recherchestand dieses Artikels ist der 22. Oktober 2026.
Was ist bei Next.js passiert?
Next.js ist Software für Webanwendungen, die auch auf einem Server laufen. Der Hersteller veröffentlichte am 14. Oktober 2026 zwei Sicherheitshinweise. Beide beschreiben mögliche Codeausführung aus der Ferne, kurz RCE: Unter bestimmten Voraussetzungen könnten Angreifer fremden Programmcode auf dem Server ausführen.
Die Bildlücke heißt GHSA-2464-fhr4-w9xw / CVE-2026-96889. Sie betrifft Image Optimization, die serverseitige Bildoptimierung. Vom Angreifer kontrollierter SVG-Grafikinhalt muss über eine akzeptierte Bildquelle die verwundbare Verarbeitung erreichen. Beschrieben ist dieser Weg auf Linux mit der Systembibliothek glibc.
Der Hersteller nennt für die Bildlücke Next.js 10.0.0 bis einschließlich 15.5.27 sowie Versionen größer als 16.0.0 bis einschließlich 16.4.0. Exakt 16.0.0 bleibt ungeklärt: NHS England nennt diese Version ebenfalls als betroffen; eine Herstellerklärung fehlt in der Recherche. Daraus folgt keine Entwarnung für 16.0.0. Für Vorabversionen nennt die Recherche keine ausdrücklichen Grenzen.
Die Cache-Lücke GHSA-673q-mjm6-r5xr betrifft 16.0.0 bis einschließlich 16.4.0. Im Herstellerhinweis steht keine bekannte CVE-Kennung. Zusammenkommen müssen App Router für die Seitenverwaltung, Cache Components zur Zwischenspeicherung und eine mit „use cache“ markierte Funktion, die mehrere Typed Arrays zurückgibt – Datenfelder mit festgelegtem Datentyp. Bildoptimierung und sharp sind hierfür keine genannten Voraussetzungen; eine Beschränkung auf glibc oder selbst betriebene Server nennt dieser Hinweis nicht.
Wie gefährlich sind die beiden Lücken wirklich?
Beide erhalten jeweils 9,5 Punkte nach CVSS 4.0, einem Bewertungssystem für die technische Schwere von Schwachstellen. Laut Bewertung sind Netzwerkangriffe ohne vorherige Berechtigungen oder Mitwirkung eines Benutzers möglich. Die technischen Voraussetzungen müssen dennoch erfüllt sein.
Nur zur Bildlücke ist in der Recherche öffentlicher Demonstrationscode belegt, ein Proof of Concept oder PoC. Ein Autor beschreibt Codeausführung über die Bildoptimierung; die Funktionsfähigkeit wurde nicht unabhängig bestätigt. Zur Cache-Lücke wurde kein belastbarer öffentlicher Angriffscode gefunden.
Aktive Ausnutzung und erfolgreiche Einbrüche über die untersuchten Wege sind in den geprüften Quellen nicht belegt. Im CISA-KEV-Katalog für bekannte ausgenutzte Schwachstellen, Datenstand 21. Oktober 2026, fehlten die Bild-CVE und ein Treffer zur Cache-Kennung. Weder ein PoC noch ein Angriffsversuch beweist einen erfolgreichen Einbruch. Ein fehlender KEV-Eintrag garantiert keine Angriffsfreiheit.
Welche Versionen korrigieren die beiden Lücken?
Die folgenden Mindeststände beziehen sich ausschließlich auf diese Schwachstellen. Für ältere Next.js-Zweige nennt die Recherche keine separaten korrigierten Ausgaben. Lassen Sie einen erforderlichen Versionswechsel einplanen.
Bei Next.js 15.5.28 reicht die Versionsnummer allein nicht: Seine Paketbeschreibung, das Manifest, erlaubt sharp optional als ^0.34.3 || ^0.35.5. Damit bleibt die ältere Linie zulässig. Ein Lockfile hält konkret ausgewählte Paketversionen fest und kann weiterhin eine alte sharp-Version enthalten. Entscheidend ist die tatsächlich von Next.js verwendete Version. 16.4.1 und 16.4.2 deklarieren bereits ^0.35.5.
- Next.js 15: 15.5.28 ist der erste offizielle Fix der Bildlücke. Die tatsächlich verwendete Bildbibliothek sharp muss zusätzlich mindestens 0.35.5 erreichen.
- Next.js 16: 16.4.1 ist der erste Fix beider Lücken. 16.4.2 ist der geprüfte Nachfolger, der die Korrekturen fortführt, keine neu erklärte Mindestversion.
- sharp: mindestens 0.35.5. Die korrigierten vorgefertigten Pakete enthalten librsvg 2.63.2 zur SVG-Verarbeitung. Bei separat aus dem System eingebundenem librsvg verlangt der Maintainer dessen Aktualisierung auf 2.63.2.
Wie prüfe ich, ob meine Website betroffen ist?
Die Prüfung benötigt Projektzugriff beziehungsweise Zugang zur Hosting-Verwaltung, keine Root-Rechte, also keinen administrativen Vollzugriff auf den Server. Ohne diese Zugänge übernimmt Ihr Betreiber die Prüfung.
Quellcode, Lockfile, Installation und produktives Deployment sind zu unterscheiden: Der Programmtext beschreibt Funktionen, das Lockfile ausgewählte Abhängigkeiten. Eine lokale Installation und ein aktualisiertes Projekt belegen noch keinen aktualisierten laufenden Dienst.
- Zuständigkeit klären: Für Website, Shop und Kundenportal getrennt erfragen, ob Next.js beteiligt ist und wer die Anwendung betreibt.
- Paketdateien prüfen: In package.json nach next und sharp suchen. Dort können Versionsbereiche stehen; package-lock.json, pnpm-lock.yaml oder yarn.lock halten konkrete Versionen fest.
- Installation auslesen: Bei vorhandener npm-kompatibler Installation im Projektverzeichnis npm ls next sharp --all ausführen. npm ist eine Paketverwaltung. Alle sharp-Kopien beachten, besonders die von Next.js verwendete. Bei fehlenden Paketen den aufgelösten Abhängigkeitsbaum von der Agentur anfordern.
- Voraussetzungen prüfen lassen: Bildquellen, SVG-Verarbeitung und glibc-Linux getrennt von App Router, Cache Components und „use cache“-Rückgaben prüfen. Ein fehlender Suchtreffer im eigenen Code genügt nicht zur Entwarnung.
- Produktiven Stand belegen: Das aktive Deployment in der Hosting-Verwaltung auswählen. Zugehörigen Quellcode- und Lockfile-Stand mit dem Build-Log, dem Protokoll der Anwendungserstellung, abgleichen. Tatsächlich ausgelieferte Versionen bestätigen lassen.
Was muss ich meiner Agentur oder meinem Hoster schreiben?
Kopieren Sie diese Anfrage und ergänzen Sie Ihre Domain:
„Guten Tag, bitte prüfen Sie unsere Website unter [Domain] auf GHSA-2464-fhr4-w9xw / CVE-2026-96889 und GHSA-673q-mjm6-r5xr. Bitte nennen Sie die produktiven Next.js- und sharp-Versionen einschließlich mehrerer sharp-Instanzen und der von Next.js verwendeten Instanz. Belegen Sie diese durch den zugehörigen Lockfile-Stand und das aktive Deployment mit Build-Log. Prüfen Sie getrennt Image Optimization, akzeptierte Bildquellen, SVG-Verarbeitung, den bildverarbeitenden Dienst und glibc-Linux sowie App Router, Cache Components und use cache mit mehreren zurückgegebenen Typed Arrays. Falls ein Update nötig ist, bestätigen Sie anschließend die produktiven Versionen sowie Datum, Uhrzeit, Zeitzone und Kennung des korrigierten Deployments. Falls keine Betroffenheit vorliegt, nennen Sie bitte die konkrete technische Begründung. Vielen Dank.“
Was tun, wenn das Update nicht sofort geht?
Für die Cache-Lücke gibt es laut Hersteller keinen bekannten Workaround, also keine bekannte Ersatzmaßnahme. Er empfiehlt das sofortige Update auch dann, wenn Ihnen keine passende Funktion im Projekt bekannt ist.
Für den Bildpfad dokumentiert der sharp-Maintainer das Sperren der SVG-Verarbeitung mit sharp.block({ operation: ["VipsForeignLoadSvg"] }). Entwickler müssen sicherstellen, dass dies im tatsächlich verwendeten Prozess greift. Das hilft nicht gegen die Cache-Lücke. SVG-Erkennung allein und dangerouslyAllowSVG: false liefern keinen belegten Schutz.
Eine spezifische Schutzregel von Cloudflare oder einer WAF, einem Filter für Webanfragen, ist in der Recherche nicht belegt. Allgemeine Schutzfunktionen ersetzen keinen Patchnachweis.
Lassen Sie Pakete und Lockfile aktualisieren, die Anwendung neu bauen und das korrigierte Deployment bereitstellen. npm ci übernimmt das vorhandene Lockfile unverändert. Ein Neustart ohne aktualisierte Pakete schließt die Lücke nicht.
Häufige Fragen zu den Next.js-Sicherheitslücken
WordPress und Plugins aktuell – reicht das?
Eine reine PHP-/WordPress-Website ist nicht allein wegen dieser Next.js-Hinweise betroffen. Ein zusätzlich betriebenes Next.js-Frontend muss separat geprüft werden. WordPress-, PHP- und Browser-Versionen belegen dessen Stand nicht.
Schützt Cloudflare?
Eine spezifische Schutzregel für diese Kennungen ist im geprüften Stand nicht belegt. Allgemeine Schutzfunktionen bestätigen keine Abdeckung. Fordern Sie den Nachweis der korrigierten produktiven Versionen an.
Statische Website – betrifft mich?
Ohne die beschriebenen serverseitigen Funktionen fehlen die Voraussetzungen dieser Angriffswege. Lassen Sie bestätigen, ob ausschließlich fertige Dateien ausgeliefert werden oder zusätzlich eine Next.js-Anwendung beziehungsweise Bildverarbeitung läuft.
Next.js 15.5.28 – bin ich sicher?
Das Manifest erlaubt weiterhin die ältere sharp-Linie ^0.34.3. Lassen Sie im Lockfile und produktiven Deployment prüfen, dass Next.js tatsächlich sharp ab 0.35.5 verwendet. Die Aussage gilt nur für die untersuchte Bildlücke.
Vercel/Managed Hosting – muss ich etwas tun?
Lassen Sie Ihren konkreten Deploymentstand bestätigen. Automatischer vollständiger Schutz sämtlicher Vercel-Deployments ist in der Recherche nicht belegt. Bei Managed Hosting, also betreutem Hosting, hängen Zuständigkeiten und Schutzmaßnahmen vom Anbieter und eingesetzten Dienst ab.
Woran erkenne ich einen Angriff?
Eine blockierte Webanfrage belegt keinen erfolgreichen Einbruch. Lassen Sie einen konkreten Verdacht vom Betreiber untersuchen. Bestätigte Einbrüche über diese Wege sind im geprüften Stand nicht belegt.