Kritische Next.js-Lücke in ImageResponse: CVE-2026-94545 erlaubt Codeausführung
Eine kritische Schwachstelle in der Next.js-Funktion ImageResponse kann zu Codeausführung auf dem Server führen. Vercel hat sie am 22. September 2026 in Version 16.3.6 behoben. Heikel für Admins: npm audit schlug bei Prüfungen nicht an und die GitHub Advisory Database kannte den Fall zunächst nicht. Wer nur auf automatische Scanner hört, übersieht die Lücke.
Wer eine Firmen-Website, einen Shop oder ein Kundenportal auf Next.js 16.2.0 bis 16.3.5 betreibt und dort Open-Graph-Bilder über die Funktion ImageResponse erzeugt, sollte heute die installierte Version prüfen. Die Schwachstelle CVE-2026-94545 kann laut Vercel dazu führen, dass Angreifer Code auf dem Server ausführen. Vercel bewertet sie mit einem CVSS-Wert von 9.5 als kritisch und hat sie am 22. September 2026 in Next.js 16.3.6 behoben.
Entwarnung gibt es für einen großen Teil der Leser: Next.js 15 ist nicht betroffen, ebenso wenig die Edge-Variante von ImageResponse. Und auch innerhalb der Version 16 ist die Bedingung eng. Betroffen sind nur Anwendungen, die vom Angreifer kontrollierte Werte während der Bilderzeugung weiterreichen, etwa Text aus der Anfrage-URL. Wer ImageResponse gar nicht einsetzt, ist nicht betroffen. Der unangenehme Teil betrifft die Erkennung: Bei Prüfungen von The Hacker News am 23. September 2026 meldete npm audit die betroffene Version 16.3.5 nicht, und das Advisory war zu diesem Zeitpunkt noch nicht in der GitHub Advisory Database gelistet. Wer sich allein auf die üblichen Automatismen verlässt, sieht hier nichts.
Was ist passiert?
Vercel, das Unternehmen hinter Next.js, hat eine Sicherheitslücke in der Funktion ImageResponse veröffentlicht und am 22. September 2026 mit Version 16.3.6 geschlossen. ImageResponse ist die Funktion, die Open-Graph-Bilder und andere Social-Preview-Bilder erzeugt, also jene Vorschaubilder, die beim Teilen eines Links in sozialen Netzwerken und Messengern angezeigt werden.
Technisch nutzt ImageResponse die Vercel-Bibliothek Satori, um das Bildlayout in SVG-Code umzuwandeln, bevor daraus das finale PNG entsteht. Laut Advisory sind jene Anwendungen betroffen, die vom Angreifer kontrollierte Werte während der Bilderzeugung in SVG-Inhalte, Attribute oder Stile geben. Das im Advisory gezeigte Beispiel nimmt einen Wert aus der Anfrage-URL und setzt ihn in ein SVG-title-Element ein.
Hier bleibt eine wichtige Frage offen, und das sollte man beim Bewerten der eigenen Anwendung wissen: Ob auch Text in gewöhnlichen Elementen zählt, etwa eine Überschrift in einem div, sagt das Advisory nicht. Diese Unsicherheit ist nicht aufgelöst. In der Praxis heißt das, man sollte im Zweifel von Betroffenheit ausgehen, wenn überhaupt Anfragewerte im Bild landen.
Wer ist betroffen?
Die Betroffenheit lässt sich klar eingrenzen. Es müssen mehrere Bedingungen zusammenkommen:
- Next.js in den Versionen 16.2.0 bis 16.3.5. Ältere und neuere Stände der 16er-Linie außerhalb dieses Bereichs fallen nicht darunter.
ImageResponseläuft auf der Node.js-Laufzeit. Das ist der Standard, Next.js nutzt diese Laufzeit ohne weitere Konfiguration.- Die Anwendung setzt vom Angreifer kontrollierte Werte in das Bild ein, etwa Text, der aus der Anfrage-URL stammt.
Ausdrücklich nicht betroffen sind laut Advisory die Edge-Variante von ImageResponse sowie Next.js 15 insgesamt. Wer auf der 15er-Linie arbeitet, muss wegen dieser Lücke nichts unternehmen. Für die 15.5-Linie bringt Next.js 15.5.26 zusätzliche Sicherheitshärtung für next/og, das ist aber kein Fix für CVE-2026-94545, sondern eine allgemeine Härtung.
Wo im Projekt man suchen muss: nach ImageResponse, importiert aus next/og. Typische Fundstellen sind Route Handlers und opengraph-image-Dateien. Route Handlers erzeugen das Bild, wenn eine Anfrage eintrifft. Eine opengraph-image-Datei kann es entweder zur Build-Zeit oder bei einer Anfrage erzeugen. Beide Varianten gehören auf die Prüfliste.
Wie kritisch ist das?
Vercel stuft die Lücke im eigenen Advisory als kritisch ein, mit einem CVSS-Wert von 9.5. Der mögliche Effekt ist Codeausführung auf dem Server, also der schwerwiegendste Fall für eine Webanwendung. Gleichzeitig ist die Voraussetzung eng gefasst, was die reale Angriffsfläche deutlich kleiner macht als die Zahl 9.5 zunächst vermuten lässt.
Zur Lage: Stand 23. September 2026 fand The Hacker News keine öffentlichen Berichte über Angriffe und keinen öffentlichen Exploit-Code. Eine aktive Ausnutzung ist damit nicht belegt. Das rechtfertigt ein geplantes Wartungsfenster statt einer Nachtaktion, sofern die Prüfung zeigt, dass Anfragewerte überhaupt ins Bild fließen. Die Prüfung selbst sollte aber heute stattfinden, nicht erst im nächsten Sprint.
Ein zweiter Punkt verdient Aufmerksamkeit, weil er den Umgang mit der Meldung erschwert: Die Satori-Bibliothek hat am selben Tag ein eigenes Advisory zu derselben CVE veröffentlicht und bewertet sie deutlich niedriger. Die Bewertung hängt dort davon ab, wie die SVG-Ausgabe weiterverwendet wird. Im Kontext von Next.js kommt Vercel zur kritischen Einstufung. Für Admins zählt die Next.js-Bewertung, weil sie den tatsächlichen Einsatzkontext beschreibt.
Unsicher bleibt außerdem, ob auf Vercel gehostete Anwendungen geschützt sind. Weder das Advisory noch die Ankündigung sagen das. Bei zwei kritischen Next.js-Lücken, die im August behoben wurden, hatte das Unternehmen erklärt, gehostete Anwendungen seien geschützt und bräuchten kein Update. Diesmal fehlt diese Aussage. Wer bei Vercel hostet, sollte sie also nicht voraussetzen.
Was sollten Admins jetzt tun?
- Die tatsächlich installierte Next.js-Version im Projekt prüfen, nicht nur den Eintrag in der
package.json. Der Eintrag dort kann eine Versionsspanne sein, entscheidend ist der installierte Stand. Parallel im Code nach Importen vonImageResponseausnext/ogund nachopengraph-image-Dateien suchen. - Nicht auf
npm auditverlassen. Bei den Prüfungen am 23. September 2026 meldete das Werkzeug die betroffene Version 16.3.5 nicht. Ein sauberes Audit-Ergebnis ist in diesem Fall kein Nachweis für Unbetroffenheit. - Nicht nach Satori in der Lockfile suchen. Satori ist im Next.js-Paket gebündelt und taucht in der Lockfile nicht als Abhängigkeit von Next.js auf. Maßgeblich ist die Next.js-Version selbst.
- Auf Next.js 16.3.6 aktualisieren, per
npm install next@16.3.6. Das ist die einzige gepatchte Version. - Anwendungen auf der 16.2-Linie einplanen. Stand 23. September 2026 listete die npm-Registry keine gefixte Version für die 16.2-Linie. Ein Minor-Wechsel auf 16.3.6 ist damit unvermeidbar und sollte als solcher getestet werden.
- Wenn das Update warten muss, den Workaround aus dem Advisory umsetzen: vom Angreifer kontrollierte Werte aus den SVG-Inhalten, Attributen und Stilen heraushalten, die das Node.js-
ImageResponserendert. - Nicht einfach auf die Edge-Laufzeit ausweichen. Das Advisory schlägt diesen Weg nicht vor, und die Next.js-Dokumentation markiert die Edge-Laufzeit als veraltet. Ein Wechsel dorthin tauscht ein Problem gegen ein anderes.
- Externe Dienstleister ansprechen. Viele Firmen-Websites werden von einer Agentur betreut. Fragen Sie konkret nach der installierten Next.js-Version und danach, ob
ImageResponseim Projekt verwendet wird. - Erwartungen an die Forensik korrigieren. Advisory und Ankündigung bieten keine Möglichkeit, zu prüfen, ob eine betroffene Route vor dem Patch missbraucht wurde. Wer Nachweise braucht, muss sich auf eigene Zugriffsprotokolle des Webservers und des Reverse Proxy stützen.
- Ergebnis dokumentieren. Auch ein Ergebnis wie "Version 15.4, nicht betroffen" gehört in die Dokumentation, damit die Frage beim nächsten Advisory nicht erneut von vorn beginnt.
Einordnung für Unternehmen
Für kleine und mittlere Unternehmen ist dieser Fall vor allem aus einem Grund lehrreich: Die etablierten Automatismen haben hier zunächst nicht gegriffen. npm audit schlug nicht an, die GitHub Advisory Database kannte den Eintrag noch nicht, und ein CVE-Eintrag für CVE-2026-94545 war noch nicht veröffentlicht. Wer seinen Patchprozess ausschließlich auf automatische Abhängigkeitsprüfungen stützt, hätte diese Lücke übersehen. Diese Werkzeuge bleiben sinnvoll, sie sind aber eine untere Schranke, keine Garantie.
Daraus folgt eine sehr praktische Konsequenz für den Betrieb: Der Herstellerkanal gehört in die Routine. Wer Next.js produktiv einsetzt, sollte die Security-Advisories des Projekts direkt beobachten, statt auf die Weiterleitung über Datenbanken und Scanner zu warten. Zwischen Herstelleradvisory und Datenbankeintrag können Tage liegen.
Der zweite Punkt betrifft die Zuständigkeit. Firmen-Websites und Kundenportale auf Next.js werden häufig von einer Agentur oder einem externen Entwicklerteam betreut. Der interne IT-Verantwortliche weiß dann oft nicht, welche Framework-Version läuft und ob ImageResponse überhaupt im Einsatz ist. Ein kurzer, dokumentierter Austausch über genau diese zwei Punkte kostet wenig und beantwortet die Frage dauerhaft. Sinnvoll ist auch, gleich zu klären, wer im Ernstfall patcht und in welchem Zeitfenster.
Ein dritter Punkt: Die Lücke sitzt in einer Funktion, die viele Entwickler als reine Kosmetik einordnen. Open-Graph-Bilder sind Vorschaubilder für soziale Netzwerke, kein Kernstück der Anwendung. Genau deshalb steht der Code dafür selten auf der Sicherheitsagenda. Dass hier ein Pfad zur Codeausführung entstehen konnte, ist ein guter Anlass, auch die scheinbar unkritischen Nebenfunktionen einer Webanwendung in die Betrachtung aufzunehmen.
Passende Anleitungen auf S-EDV
- Docker-Images mit Trivy auf Schwachstellen scannen und SBOM erzeugen: zeigt, wie sich Abhängigkeiten systematisch erfassen lassen, statt sich auf ein einzelnes Audit-Werkzeug zu verlassen.
- 14 vergiftete npm-Pakete liefern KI-gesteuerte RedC2-Backdoor: weiterer Fall aus dem npm-Ökosystem, der zeigt, warum die Lieferkette von JavaScript-Projekten eigene Aufmerksamkeit braucht.
- Nginx als Reverse Proxy mit TLS einrichten: die Zugriffsprotokolle des Reverse Proxy sind oft die einzige verwertbare Spur, wenn der Hersteller keine Prüfmöglichkeit anbietet.
