Next.js next/og RCE: CVE-2026-94545 patchen (16.3.6)

Vercel hat am 22. September ein außerplanmäßiges Next.js-Release veröffentlicht – wenn Sie Open Graph-Bilder in Ihrer App generieren, lesen Sie dies noch heute zuerst. Das Update in den Versionen 16.3.6 und 15.5.26 schließt eine kritische Remote Code Execution-Schwachstelle in next/og, verfolgt als CVE-2026-94545 (Advisory GHSA-vcvr-r3jv-pc5j). Der CVSS-Score liegt bei 9,5. Das ist so ziemlich das Schlimmste, was ein Framework-Bug sein kann.

Die Schwachstelle steckt in der Node.js-Version von ImageResponse, dem Hilfsmittel, das die meisten Teams für den Aufbau dynamischer Share-Cards verwenden: die kleinen Titel-und-Vorschaubild-Previews, die auftauchen, wenn jemand Ihren Link in Slack, LinkedIn oder einem Gruppenchat teilt. Unter der Haube übergibt ImageResponse Ihr JSX an Satori, das es in SVG umwandelt und dann dieses SVG in ein PNG rendert. Die eigentliche Ursache liegt eine Ebene tiefer in Satori, das seinen eigenen Advisory hat (GHSA-wx4j-mvgx-mqwp): Es hat bestimmte Werte nicht escaped, bevor sie in das SVG geschrieben wurden. Ein Wert, den Sie für einfachen Text hielten, konnte also ausbrechen und als live SVG-Markup interpretiert werden. Wenn der Renderer dieses Markup dann verarbeitet, kann vom Angreifer kontrollierter Input auf Ihrem Server ausgeführt werden.

Sind Sie wirklich betroffen?

Die Bedingung, die Sie angreifbar macht, ist spezifisch, und es lohnt sich, ehrlich darüber zu sein. Sie sind betroffen, wenn Sie den Node.js-ImageResponse (der App Router-Standard, wenn eine Route sich nicht für Edge entscheidet) verwenden und einen Wert, den ein Besucher kontrolliert, in das Bild einspeisen. Ein Wort aus der URL. Ein Profilname. Ein Query-String-Parameter. Das ist kein exotisches Muster. Es ist genau das Rezept, das jeder verwendet, um pro Artikel eine Share-Card zu erstellen. Wenn Ihre OG-Route immer nur fest codierte Titel oder Werte aus einer vertrauenswürdigen Datenbank rendert, befinden Sie sich nicht im Gefahrenbereich. Auch die Edge-Implementierung von ImageResponse ist nicht betroffen.

Betroffene Versionen sind Next.js 16.2.0 bis 16.3.5. Der Fix ist 16.3.6. Vercel hat ebenfalls am selben Tag 15.5.26 veröffentlicht, aber dieses Release dient nur der Härtung; die 15.x-Linie war nicht anfällig für die RCE.

Was viele übersehen

Hier verbringen wir einen Großteil unserer Zeit bei Pentesting-Engagements: Das Patchen des Frameworks ist notwendig, aber nicht immer ausreichend. npm install next@16.3.6 aktualisiert das von Next.js mitgelieferte Satori. Es tut nichts für ein satori oder @vercel/og, das Sie in Ihre eigene package.json aufgenommen haben. Das sehen wir ständig. Ein Team erhöht die Hauptabhängigkeit, der Scanner schlägt weiterhin an, und niemand kann herausfinden, warum. Wenn Sie Satori direkt irgendwo verwenden, aktualisieren Sie es separat auf 0.33.5 oder höher, und überprüfen Sie, was Ihre Lockfile tatsächlich auflöst, anstatt der Top-Level-Version zu vertrauen.

Was Sie diese Woche tun sollten

Beginnen Sie damit, Ihre Codebase nach next/og, opengraph-image und twitter-image zu durchsuchen. Wenn nichts zurückkommt, können Sie aufatmen und das Upgrade in Ihrem normalen Rhythmus einplanen. Wenn etwas zurückkommt, behandeln Sie jede dieser Routen als erreichbar, bis Sie sie untersucht haben. Stellen Sie sich pro Route eine Frage: Kann ein Besucher einen Wert beeinflussen, der das Bild erreicht? Aktualisieren Sie dann auf 16.3.6 (oder 15.5.26 auf der 15er-Linie), installieren Sie neu, damit die Lockfile aktualisiert wird, bauen Sie neu und stellen Sie erneut bereit. Bestätigen Sie die aufgelöste Satori-Version in der gebauten Ausgabe, nicht nur in package.json.

Wenn Sie heute wirklich nicht liefern können, ist Vercels angegebener Workaround zwar simpel, aber er hält: Hören Sie auf, nicht vertrauenswürdigen Input in das Bild einzuspeisen. Ersetzen Sie den dynamischen Wert durch einen sicheren Platzhalter, oder verschieben Sie die Route zur Edge-Runtime, wenn sie dort ohne Änderungen läuft. Keine dieser Optionen ist eine langfristige Lösung. Beide verschaffen Ihnen einen Tag Zeit.

Die größere Lektion

Es gibt ein Muster hier, und es ist dasselbe, das uns Log4Shell und der kürzliche axios Prototype-Pollution-Bug gelehrt haben. Die gefährlichen Schwachstellen liegen selten in Ihrem eigenen Code. Sie liegen eine oder zwei Ebenen tiefer, in einer weithin vertrauenswürdigen Bibliothek, die ein Framework für Sie einbindet. Wenn wir Cloud-native Apps für Unternehmenskunden entwickeln, ist das der Grund, warum wir auf eine echte Software Bill of Materials und automatisches Dependency-Scanning in der CI bestehen – nicht auf ein vierteljährliches Audit. Sie möchten, dass das Tooling Ihnen sagt: „Sie liefern Satori 0.31, es ist jetzt anfällig“ – und zwar am Morgen, an dem das Advisory veröffentlicht wird, nicht drei Wochen später, wenn ein Kunde Ihnen einen Scan weiterleitet.

Die Injection-to-RCE-Form ist auch eine nützliche Erinnerung daran, wie man über jeden Renderer nachdenkt – ob im Backend oder in einer mobilen App. Alles, was strukturierten Input entgegennimmt und ein Dokument produziert (SVG, HTML, ein PDF, ein WebView-Payload), ist ein Ort, wo „nur Text“ still zu „ausführbar“ werden kann. In unseren nativen iOS- und Android-Projekten wenden wir dieselbe Regel auf alles an, was servergesteuerten Inhalt rendert: An der Grenze escapen und nie annehmen, dass die Ebene darunter es für Sie getan hat. Satoris Fix war genau das: Text- und Attributwerte zu escapen, bevor sie das SVG erreichen. Das Framework hatte der Bibliothek vertraut, etwas zu tun, was die Bibliothek nicht tat.

Wenn Sie ein zweites Augenpaar wünschen, um herauszufinden, welche Ihrer next/og-Routen ein Besucher tatsächlich erreichen kann, ist das für uns Routinearbeit. Erfahren Sie, wie wir die Sicherheit von Webanwendungen angehen. Und wenn ein kritisches Advisory, das an einem Freitagabend erscheint und bei dem niemand genau weiß, welche Routen betroffen sind, vertraut klingt, sprechen wir gerne mit Ihnen.