Next.js Security-Update am 14. Oktober und Next.js 15 am Ende: Was Headless-Shopware jetzt tun muss

1. Was am 14. Oktober kommt — und was noch niemand weiß

Die Ankündigung vom 8. Oktober ist knapp: ein Out-of-band-Update für drei Schwachstellen in Upstream-Abhängigkeiten, zwei davon kritisch, eine hoch. Zwei der Fixes waren bereits für das September-Release geplant und wurden wegen der Abstimmung mit den Upstream-Projekten verschoben. Betroffene Versionen, Auswirkungen und Upgrade-Anweisungen veröffentlicht das Team erst zusammen mit dem Update.

Das heißt ehrlich: Stand heute weiß niemand außerhalb des Teams, welche Funktionen betroffen sind. Alles, was du in den nächsten Tagen über „die Lücke“ liest, bevor die Advisories draußen sind, ist Spekulation. Planbar ist trotzdem viel — nämlich alles, was nicht vom Inhalt der Lücken abhängt: welche Version du fährst, wie schnell du ausrollen kannst und ob du nach dem Ausrollen merkst, dass etwas kaputt ist. Dieser Beitrag beschreibt den Stand vom 12. Oktober und wird ergänzt, sobald die Advisories vorliegen.

2. Die letzten drei Wochen waren schon kein Ruhezustand

Wer seit dem 22. September nichts eingespielt hat, hat bereits offene Punkte. Das Update vom 22. September (16.3.6 und 15.5.26) schloss eine kritische Lücke: Remote Code Execution über die Node.js-Variante von ImageResponse in next/og, betroffen waren die Versionen ab 16.2.0 bis vor 16.3.6. Die Edge-Variante war nicht betroffen, Next.js 15 auch nicht für die Codeausführung.

Eine Woche später folgte das Release vom 30. September (16.3.8 und 15.5.27) mit sieben Advisories, darunter eine SSRF-Lücke in der Image Optimization (hoch) und mehrere Cache-Probleme (mittel). Wer also „irgendwann im September“ aktualisiert hat, sollte nachsehen, ob dieses „irgendwann“ vor oder nach dem 30. lag. Die Frage, auf die es ankommt, ist nicht „aktuell oder nicht“, sondern „welche konkrete Patch-Nummer steht in der yarn.lock“.

3. Vier Stellen, an denen Shopware-Frontends typisch betroffen sind

Die Advisories vom September beschreiben Bedingungen. Und diese Bedingungen sind in Headless-Shopware-Projekten auffällig oft erfüllt — nicht, weil wir etwas falsch machen, sondern weil die Architektur sie nahelegt:

• Catch-all-Route plus ISR. Shopware liefert SEO-URLs, die ein Frontend auflösen muss. Der übliche Weg ist eine Root-Catch-all-Route, die den Pfad an die Store-API gibt und je nach Ergebnis Produkt, Kategorie oder CMS-Seite rendert, meist statisch oder per ISR. Genau diese Kombination nennt CVE-2026-94484: Ein einzelner unauthentifizierter, präparierter Request kann den geteilten Response-Cache vergiften.
• Image Optimization mit Shopware-Medien. Produktbilder liegen auf der Shopware-Domain oder einem CDN; damit next/image sie ausliefert, steht images.remotePatterns in der Konfiguration. Die SSRF-Lücke (CVE-2026-94483) betrifft ausdrücklich Anwendungen mit gesetzten remotePatterns; ohne sie besteht kein Risiko. Bei Headless-Shopware ist das praktisch immer gesetzt.
• Dynamische OG-Bilder. Produktbilder mit Preis-Badge für Social Shares sind ein beliebtes Extra und laufen über next/og. Wer sie auf dem Node-Runtime rendert und zwischen 16.2.0 und 16.3.5 steht, war von der September-RCE betroffen.
• Cache Components und Preview. Wer use cache nutzt — wie in Cache Components in Next.js 16 beschrieben — und Entwurfsinhalte aus Shopware per Draft Mode vorschaut, ist beim Advisory CVE-2026-94544 relevant: Ein überlappender Request kann unveröffentlichte Inhalte ausgeliefert bekommen und sie in eine prerenderte Seite schreiben.

Ob und wie diese Punkte zu den Lücken vom 14. Oktober gehören, ist offen. Sie zeigen aber, wo du nach dem Patch hinsehen solltest — denn alle drei Cache-Probleme haben eine gemeinsame Eigenschaft: Eine vergiftete Seite bleibt, bis sie revalidiert wird. Nach dem Einspielen eines Fixes lohnt sich deshalb ein einmaliges, gezieltes Leeren des Cache, statt zu hoffen, dass nichts Falsches drin steht.

4. 21. Oktober: Next.js 15 verliert den Support

Die Support Policy kennt für die Vorgänger-Major-Version eine Maintenance-LTS-Phase: nur kritische Bugfixes und wichtige Sicherheitsupdates, und zwar zwei Jahre ab der Erstveröffentlichung. Next.js 15 erschien am 21. Oktober 2024. endoflife.date führt entsprechend den 21. Oktober 2026 als Ende. Wichtig zur Einordnung: Die Policy selbst nennt kein Enddatum und verwendet den Begriff „EOL“ nicht, das Datum ergibt sich aus der Zwei-Jahres-Regel. Für die Planung ändert das nichts. Nicht unterstützte Versionen erhalten keine regulären Updates mehr, im Ausnahmefall je nach Schwere.

Die Konsequenz für den 14. Oktober: Ob 15.x den Patch bekommt, steht in der Ankündigung nicht. Das September-Release hat 15.5.26 und 15.5.27 noch ausgeliefert, aber danach beginnt die Woche, in der du dich nicht mehr auf Backports verlassen solltest. Wer jetzt auf 15.5.x sitzt, plant besser nicht den Patch, sondern den Umstieg.

5. Der Sprung 15 → 16: wo es bei Shopware-Frontends knallt

Der offizielle Upgrade-Guide ist lang; für ein typisches Headless-Shopware-Projekt sind es sechs Punkte, die ich zuerst prüfe:

• Async Request APIs: cookies(), headers(), params und searchParams gibt es nur noch asynchron. Das trifft jeden Code, der den Shopware-Kontext-Token aus Cookies liest. Die Version 15 hatte dafür noch eine Übergangsschicht, die in 16 entfällt.
• Images: Neue Defaults, darunter minimumCacheTTL von vier Stunden, qualities nur noch [75] und höchstens drei Redirects. Wer Thumbnails mit abweichender Qualität anfragt, bekommt sie auf den nächsten erlaubten Wert gesetzt, direkte Requests mit nicht erlaubtem q liefern 400.
• Middleware: Die Datei heißt nun proxy und läuft im Node-Runtime. Wer Middleware im Edge-Runtime für Sprach- oder Verkaufskanal-Routing nutzt, benennt sie nicht blind um.
• Caching: revalidateTag braucht ein zweites Argument. Das betrifft jeden Webhook, der nach Produktänderungen in Shopware Tags invalidiert.
• Turbopack als Standard: Ein benutzerdefinierter webpack-Block in der Konfiguration lässt next build scheitern, bis du dich entschieden hast.
• Entfernt: next lint und die Runtime-Konfiguration (serverRuntimeConfig, publicRuntimeConfig). Mindestens Node.js 20.9.

Die mechanischen Teile übernimmt ein Codemod: yarn dlx @next/codemod@canary upgrade latest, danach separat npx @next/codemod@canary next-async-request-api ., falls noch synchroner Zugriff übrig ist. Wichtig ist der Satz am Ende der offiziellen Checkliste: Ein grüner Build schließt Laufzeitfehler nicht aus. Bei einem Shop heißt das, die kritischen Flows wirklich durchzuklicken (siehe unten).

Und die Frage nach Next.js 16.4, das am 6. Oktober erschienen ist? Cache Components werden dort erstmals für jede App empfohlen und sollen in Next.js 17 Standard werden. Meine Empfehlung bleibt trotzdem: erst die Version wechseln, dann in einem getrennten Schritt Cache Components aktivieren. Die offizielle Checkliste sagt dasselbe — React Compiler und Cache Components gehören nicht zur Migration, nur weil du ohnehin dabei bist. Wie der Cache bei Headless-Shopware grundsätzlich aufgebaut wird, steht in Next.js-Caching für Shopware Headless.

6. Was ich bis Mittwoch vorbereiten würde

Erstens die Inventur. Für jedes Frontend die tatsächlich installierte Version aus der Lockdatei ablesen, nicht aus der package.json: yarn why next zeigt sie, auch wenn Abhängigkeiten eine zweite Kopie mitbringen. Dazu notieren, wo gehostet wird. Bei den Cache-Advisories vom September war eine Lücke ausdrücklich auf selbst betriebene Installationen beschränkt, Vercel-Deployments nicht betroffen — der Hosting-Weg verändert also die Dringlichkeit, nicht die Notwendigkeit.

Zweitens eine Pipeline, die in einer Stunde ausrollen kann. Wenn der Patch erscheint, soll die Frage nicht „wie deployen wir das“ lauten. Ein Preview-Deployment mit der gepatchten Version, ein Smoke-Test gegen die echte Store-API und ein Rollback-Weg sind der ganze Plan.

Drittens die Smoke-Tests definieren, bevor du sie brauchst. Bei einem Shopware-Frontend sind das ein Produktlisting mit Filter, eine Produktdetailseite über die SEO-URL, Suche, Login mit Kontext-Token, Warenkorb, Checkout bis zur Bestellbestätigung und ein Bild über next/image. Das sind zehn Minuten, die den Unterschied zwischen „Update ist drin“ und „Update ist drin und der Checkout geht noch“ ausmachen. Einen Einblick in diesen Teil des Stacks gibt Login mit der Store-API und Next.js.

Viertens eine Entscheidung zu Version 15: Wer es bis zum 21. Oktober nicht schafft, kann den 14. Oktober noch auf 15.5.x mitnehmen, falls der Patch dafür kommt, sollte aber einen Termin für die Migration nennen können. „Läuft ja“ ist bei einer nicht mehr unterstützten Version mit bekanntem Patch-Rhythmus keine Strategie.

7. Einordnung

Zwei Sicherheitsupdates in neun Tagen und ein dritter Termin eine Woche später sind kein Grund zur Panik, aber ein Grund, Wartung als laufende Aufgabe zu behandeln und nicht als Projektabschluss. Das gilt für das Shopware-Backend, bei dem die Update-Frequenz seit Monaten ähnlich ist, genauso wie für das entkoppelte Frontend, das ein eigenes Patch-Fenster mitbringt. Wer beides betreibt, hat zwei Update-Kalender. Wie sich das in Wartungsverträgen sauber abbilden lässt, steht in Shopware-Wartung und SLA zwischen Agentur und Freelancer.

Dieser Beitrag beschreibt den öffentlichen Stand vom 12. Oktober 2026. Die Details der Lücken vom 14. Oktober, die betroffenen Versionen und die Patch-Nummern stehen erst in den Advisories — dort entscheidet sich, ob dein Frontend betroffen ist, nicht hier.