Next.js Version prüfen: Inventar und Risiko-Check für alle Projekte

Irgendwo in Ihrem Unternehmen läuft ein Next.js-Projekt, das niemand mehr auf dem Schirm hat. Vielleicht ein Kundenportal, das eine frühere Agentur aufgesetzt hat. Eine Landingpage aus dem letzten Rebranding. Ein internes Buchungstool, das die IT-Abteilung damals schnell aufgestellt hat. Die Hauptwebsite ist aktuell gepatcht — doch daneben existieren Projekte, für die niemand verlässlich sagen kann, in welcher Version Next.js gerade produktiv läuft.

Dieses Szenario ist kein Einzelfall. Es ist das normale Ergebnis gewachsener IT-Landschaften im Mittelstand: Projekte entstehen, Dienstleister wechseln, Verantwortlichkeiten verschwimmen. Und weil Next.js als Framework in den letzten Jahren erheblich an Verbreitung gewonnen hat, betrifft das Problem heute mehr Unternehmen als je zuvor.

Das Risiko ist dabei konkret: Die Maintenance-Phase von Next.js 15 endet nach der offiziellen Support-Policy zwei Jahre nach dem Release — also am 21. Oktober 2026. Danach sind laut Policy keine Sicherheitsupdates mehr zugesagt. Wer auf einer alten 15.x-Version läuft, die nicht mindestens auf 15.5.28 gehoben wurde, ist bereits heute gegenüber mehreren kritischen Lücken exponiert — darunter eine Remote Code Execution in der Image Optimization API (GHSA-2464-fhr4-w9xw) und ein Denial-of-Service im App Router mit Server Actions (GHSA-p3m5-59mp-jv5r), beide gepatcht in 15.5.28.

Der erste Schritt ist daher nicht das Upgrade auf Next.js 16. Der erste Schritt ist herauszufinden, was überhaupt läuft.

Welche Projekte können auf Next.js laufen?

Bevor Sie mit dem Inventar beginnen, lohnt ein gedanklicher Durchlauf durch alle Arten von Web-Projekten, die in einem mittelständischen Unternehmen üblicherweise existieren:

• Öffentliche Unternehmenswebsites und Landingpages, oft durch Agenturen aufgesetzt
• Online-Shops mit Next.js als Frontend-Schicht (z. B. über Headless-Commerce-Ansätze)
• Kundenportale mit Login und Kundendaten — häufig individuell entwickelt
• Interne Web-Apps: Dashboards, Auswertungstools, Mitarbeiterverwaltung
• Microsites für Kampagnen, Veranstaltungen oder einzelne Produktlinien
• Buchungssysteme als eigenständige Next.js-Applikation

Gerade die letzten drei Kategorien werden bei einem Versions-Check oft vergessen, weil sie nicht im normalen Website-Monitoring auftauchen. Dabei sind interne Tools mitunter gefährlicher: Sie laufen unter einer internen URL, werden seltener geprüft — und wenn sie Login oder Kundendaten enthalten, ist das Schadenspotenzial bei einer Sicherheitslücke hoch.

So prüfen Sie die Next.js-Version: Vier Methoden

1. package.json und Lockfile auslesen

Der direkteste Weg führt in das Projektverzeichnis. Die package.json enthält unter dependencies die angegebene Next.js-Version:

"dependencies": {
  "next": "^15.4.0",
  ...
}

Das Caret-Symbol (^) erlaubt dabei Minor-Updates, zeigt aber nur die Mindestversion — nicht die tatsächlich installierte. Die exakt installierte Version steht in der package-lock.json (npm), yarn.lock oder pnpm-lock.yaml unter dem Eintrag für next. Wer Zugriff auf das Repository hat, findet dort die verlässlichste Auskunft.

2. Installierte Version im laufenden Projekt auslesen

Wenn das Projekt lokal ausgecheckt ist:

npx next --version

Oder direkt aus dem Node-Modul:

node -e "console.log(require('next/package.json').version)"

Beide Befehle geben die tatsächlich installierte Version aus — nicht die in package.json hinterlegte Anforderung.

3. Öffentlich erreichbare Projekte über HTTP-Header prüfen

Next.js sendet in den meisten Konfigurationen den HTTP-Header x-powered-by: Next.js. Die Version ist darin allerdings nicht enthalten. Mit Tools wie curl -I https://ihre-domain.de oder einem Browser-Entwicklerwerkzeug können Sie prüfen, ob ein Projekt überhaupt auf Next.js basiert. Die Versionsinformation ergibt sich dann aus dem Repository-Zugriff oder der Agentur.

Manche Deployments deaktivieren diesen Header bewusst (empfehlenswert aus Sicherheitsgründen) — das Fehlen des Headers schließt Next.js also nicht aus.

4. Hosting-Plattform und CI/CD-Logs befragen

Auf Vercel zeigt das Deployment-Dashboard die verwendete Next.js-Version je Deployment an. Auch auf anderen Plattformen wie Railway oder Hetzner können Build-Logs die installierte Version enthalten — sofern Sie Zugriff auf die CI/CD-Pipeline haben. Wenn Projekte durch externe Agenturen betrieben werden, müssen Sie die Versionsinformation aktiv anfragen.

Das Inventar aufbauen: Was pro Projekt erfasst werden muss

Ein brauchbares Inventar geht über eine reine Versionsliste hinaus. Für jede Instanz sollten folgende Felder gepflegt werden:

Gerade die letzten beiden Felder werden bei Bestandsaufnahmen oft unterschätzt. Wenn weder intern eine Person für ein Projekt verantwortlich ist noch klar ist, wer Zugriff auf das Repository hat, ist das allein schon ein Risikosignal — unabhängig von der eingesetzten Version.

Warum Image Optimization API und Middleware besonders relevant sind

Die Sicherheits-Advisories von 2026 konzentrieren sich auf genau zwei Subsysteme von Next.js:

Image Optimization API: Next.js bringt unter /api/og bzw. /_next/image eine serverseitige Bildoptimierung mit. Diese Komponente akzeptiert externe URLs und verarbeitet Bilddaten auf dem Server. Fehler in der Eingabevalidierung — wie bei SVG-Dateien (GHSA-2464-fhr4-w9xw, kritisch) oder AVIF-Dateien (GHSA-2xp9-vwfh-vxw4, ebenfalls kritisch) — können zu Remote Code Execution führen. Die Lücke betrifft jedes Projekt, das die Image Optimization API verwendet und öffentlich erreichbar ist. Der Workaround aus dem Advisory (Einsatz von sharp ≥ 0.35.5) ist kein vollständiger Ersatz für das Patch-Update.

Middleware / Server Actions: Die Next.js-Middleware läuft auf jeder Anfrage vor dem eigentlichen Route-Handler und wird häufig für Authentifizierungs-Checks und Weiterleitungen eingesetzt. Fehler dort können Auth-Bypässe ermöglichen — ein Angriffsmuster, das bereits im März 2025 mit CVE-2025-29927 dokumentiert wurde. Server Actions, die ab Next.js 13 im App Router eingeführt wurden, verarbeiten serverseitige Datenmutationen direkt aus dem Browser. Ein DoS-Angriff über diese Schnittstelle (GHSA-p3m5-59mp-jv5r) kann einen Dienst unerreichbar machen, ohne dass ein Angreifer sich authentifizieren muss.

Projekte, die weder Middleware noch Image Optimization API einsetzen — zum Beispiel rein statisch exportierte Marketing-Sites — haben ein niedrigeres Risikoprofil. Das sollte im Inventar entsprechend vermerkt werden.

Praxisbeispiel: Wie eine Bestandsaufnahme in der Praxis aussieht

Nehmen wir ein hypothetisches mittelständisches Unternehmen mit fünf Next.js-Projekten — eine Situation, die in dieser Form typisch für Unternehmen mit gewachsener Web-Infrastruktur ist:

Das Kundenportal auf 15.3.1 ist öffentlich erreichbar, verarbeitet Kundendaten, nutzt Middleware für die Authentifizierung — und ist damit von mehreren Advisories aus 2025 und 2026 betroffen, die erst in späteren 15.5.x-Versionen gepatcht wurden. Die Kampagnen-Landingpage nutzt die Image API und ist ebenfalls exponiert. Das Shop-Frontend auf 14.2.35 ist bereits nach der offiziellen Policy „Unsupported" — hier sind nicht nur Sicherheitsupdates ausgeblieben, es gibt auch keine zugesagten Backports mehr.

Das interne Dashboard auf 15.5.28 hat dagegen keinen unmittelbaren Handlungsbedarf: Es ist nicht öffentlich erreichbar und läuft auf der aktuellen Patch-Version des Wartungs-Branches.

Risiken priorisieren: Die drei entscheidenden Kriterien

Nicht jedes Projekt muss gleich dringend aktualisiert werden. Die Priorisierung ergibt sich aus drei Faktoren:

1. Öffentliche Erreichbarkeit: Ein System, das über das Internet angesprochen werden kann, hat eine fundamentell andere Angriffsfläche als ein internes Tool hinter VPN. Öffentlich erreichbare Systeme sind immer höchste Priorität.

2. Verarbeitete Daten: Projekte mit Login, Kundendaten, Zahlungsprozessen oder personenbezogenen Informationen haben bei einem Sicherheitsvorfall eine deutlich größere Schadensdimension — rechtlich (DSGVO) und wirtschaftlich. Ein Portal mit Zugangsdaten von Kunden ist kritischer als eine statische Produktseite.

3. Version unter 15.5.28: Jede 15.x-Installation unterhalb dieser Version ist durch die Advisories von 2026 verwundbar, die erst am 14. Oktober 2026 (15.5.28) gepatcht wurden. Für Projekte auf 14.x gilt dasselbe — mit dem Unterschied, dass 14.x nach Policy bereits vollständig ohne Support ist.

Wer diese drei Kriterien für jedes Projekt im Inventar erfasst, kann eine einfache Risikoampel ableiten:

• Rot (sofortiger Handlungsbedarf): Öffentlich erreichbar + Kundendaten + Version < 15.5.28
• Orange (zeitnah): Öffentlich erreichbar + keine Kundendaten + Version < 15.5.28, oder nicht öffentlich + Kundendaten + Version < 15.5.28
• Gelb (planbar): Nicht öffentlich + keine Kundendaten + Version < 15.5.28
• Grün: Version 15.5.28 oder höher

Altprojekte von externen Agenturen: Besonderheiten beim Zugriff

Viele mittelständische Unternehmen haben Next.js-Projekte bei externen Dienstleistern in Auftrag gegeben und danach keinen direkten Repository-Zugriff behalten. Das schafft eine spezifische Herausforderung: Ohne Zugriff auf das Repository oder die Hosting-Plattform lässt sich die installierte Version nicht direkt ablesen.

Mögliche Wege:

• Direkte Anfrage an den Dienstleister: Verlangen Sie schriftlich Auskunft über die eingesetzte Next.js- und Node.js-Version, den Deployment-Stand und die letzte Sicherheitsaktualisierung. Ein seriöser Dienstleister sollte diese Information innerhalb von 24 Stunden liefern können.
• Repository-Zugriff einfordern: Ihr Code gehört Ihnen. Wenn ein Dienstleister keinen Repository-Zugriff gewährt, ist das ein organisatorisches Problem, das unabhängig von der aktuellen Sicherheitslage gelöst werden sollte.
• Deployment-Plattform prüfen: Falls das Projekt auf Vercel, Netlify oder einer ähnlichen Plattform liegt, und Sie Zugang zum Team-Account haben, zeigen Build-Logs die verwendete Version.
• HTTP-Fingerprinting als erster Schritt: Wenn öffentlich erreichbar, können Response-Header und Build-Artefakte (/_next/static/chunks/) erste Hinweise liefern, auch wenn die exakte Version daraus nicht sicher bestimmbar ist.

Node.js-Version mitprüfen: Ein oft übersehener Aspekt

Wer perspektivisch auf Next.js 16 upgraden möchte, muss zusätzlich zur Next.js-Version auch die Node.js-Umgebung prüfen. Next.js 16 setzt Node.js ≥ 20.9.0 voraus — Node.js 18 wird nicht mehr unterstützt. Das engines-Feld in next@16.4.2 auf npm bestätigt diese Anforderung.

Für das Inventar bedeutet das: Neben der Next.js-Version sollte auch die laufende Node.js-Version erfasst werden. Systeme auf Node.js 18 oder älter können nicht direkt auf Next.js 16 migriert werden, ohne zuerst den Node-Upgrade durchzuführen.

node --version

Dieser Befehl im Projektverzeichnis oder auf dem Server gibt die aktuell verwendete Node.js-Version aus. Bei Hosting-Diensten ist die Node-Version häufig in der Konfigurationsdatei (.nvmrc, .node-version oder in der Hosting-Konfiguration) hinterlegt.

Der Artikel Next.js für Unternehmen: Wann lohnt sich das Framework wirklich? gibt einen guten Überblick über strategische Entscheidungen rund um den Framework-Einsatz, bevor Sie in die technische Migration gehen.

Sofortmaßnahme: Alles auf 15.5.28 heben

Wer Projekte auf 15.x betreibt und noch nicht auf 15.5.28 ist, hat eine klare Sofortmaßnahme: das Patch-Update auf die letzte verfügbare 15.x-Version. Dieser Schritt ist explizit kein Upgrade auf Next.js 16 — er hält bewusst auf dem 15.x-Branch und schließt dabei die bisher bekannten kritischen Lücken.

Das Update selbst ist in den meisten Fällen unkritisch:

npm install next@15.5.28

Anschließend sollte ein vollständiger Build-Test durchgeführt werden, um sicherzustellen, dass keine projektspezifischen Kompatibilitätsprobleme entstanden sind. Da Vercel Minor-Updates im Maintenance-Modus auch als semver-minor veröffentlicht (auch wenn sie Breaking Changes enthalten können), empfiehlt sich ein kurzer Smoke-Test auf einer Staging-Umgebung.

Für Projekte auf 14.x oder älter reicht dieser Schritt nicht aus: 14.x ist nach der offiziellen Policy bereits vollständig ohne Support. Hier ist eine Migration auf 15.5.28 oder direkt auf 16.x der einzig sinnvolle Pfad — was strukturelle Änderungen erfordern kann und in einem separaten Schritt geplant werden sollte.

Wenn Sie wissen möchten, was ein Upgrade von Next.js 15 auf 16 konkret bedeutet, schauen Sie sich den Überblick der Breaking Changes und des Upgrade-Prozesses an: Handlungsplan zum Ende der Maintenance-Phase von Next.js 15.

Was das für die interne Zuständigkeit bedeutet

Technisch ist das Versions-Update eine überschaubare Maßnahme. Organisatorisch setzt es voraus, dass jemand Verantwortung übernimmt. In vielen KMU gibt es für jeden einzelnen Next.js-Dienst keine klar benannte Person, die für Sicherheitsupdates zuständig ist.

Ein Inventar löst dieses Problem nur dann, wenn neben der technischen Information auch die Verantwortlichkeit dokumentiert wird: Wer entscheidet über Updates? Wer hat Zugriff auf das Deployment? Wer erhält Sicherheits-Advisories von Vercel oder aus dem GitHub-Advisory-Feed?

Für Unternehmen, die mehrere Next.js-Projekte betreiben und keinen eigenen Entwickler für die laufende Softwarewartung haben, lohnt ein Blick auf geregelte Wartungsstrukturen — sei es über einen internen Verantwortlichen oder einen externen Partner mit dokumentierten Update-Prozessen. Der Artikel Softwarewartung Individualsoftware: Was KMU wirklich brauchen – und was es kostet gibt dazu eine realistische Einschätzung.

Wie SW Business Solutions dabei helfen kann

Das Erstellen eines vollständigen Next.js-Inventars klingt nach einer Nachmittagsaufgabe — ist es aber selten. Die Herausforderung liegt im Auffinden von Projekten, die niemand mehr aktiv pflegt, im Zugriff auf Repositories externer Agenturen und in der korrekten Risikobewertung je Projekt.

SW Business Solutions führt im Rahmen eines Next.js-Upgrade-Checks genau diese Bestandsaufnahme durch:

1. Alle bekannten und potenziell übersehenen Next.js-Projekte identifizieren
2. Next.js- und Node.js-Version je Projekt ermitteln — inklusive Koordination mit externen Dienstleistern
3. Inventar mit vollständiger Risikobewertung (Router-Typ, Middleware, Server Actions, Image API, Hosting, Kundendaten) erstellen
4. Kritische Projekte sofort auf 15.5.28 heben — mit Build-Test und Staging-Abnahme
5. Empfehlung für den weiteren Upgrade-Pfad auf Next.js 16 für die Projekte, bei denen das sinnvoll ist

Unsere eigenen Projekte — darunter Buchungs- und Verwaltungsplattformen für Kunden wie MobiKart Funracing GmbH — laufen selbst auf Next.js und werden durch uns laufend gewartet. Das gibt uns ein direktes Verständnis für die Praxis, nicht nur für die Theorie.

Wenn Sie den Check beauftragen möchten, sprechen Sie uns an. Das geht schnell und ohne umständliche Vorgespräche.

Zusammenfassung: Was jetzt zu tun ist

Drei Schritte, in dieser Reihenfolge:

1. Inventar erstellen: Alle Next.js-Projekte — Websites, Portale, Shops, interne Apps — mit Version, Hosting, Verantwortlichen und Datenverarbeitung erfassen.
2. Risiken priorisieren: Öffentlich erreichbare Projekte mit Kundendaten und Version unter 15.5.28 sofort als kritisch markieren.
3. Sofort-Update durchführen: Alle 15.x-Instanzen auf 15.5.28 heben. Für 14.x-Projekte Migrationspfad planen.

Der Schritt danach — das Upgrade auf Next.js 16 — ist ein eigenes Kapitel mit eigenen Breaking Changes und Anforderungen. Er sollte geplant, nicht reaktiv angegangen werden. Doch bevor darüber nachgedacht werden kann, muss klar sein, was überhaupt läuft. Daran führt kein Weg vorbei.