Next.js-Sicherheitsupdate: was für ProcessCube®-Apps zu tun ist

Vercel hat im August-2026-Release zwei kritische Lücken in Next.js geschlossen. Eine davon ist für ProcessCube®-Apps relevant — allerdings nur, wenn die Anwendung unter Windows läuft. Dieser Beitrag ordnet ein: was die Lücke technisch ist, warum sie plattformabhängig wirkt, was wir im App-SDK geändert haben und wie ein Update konkret aussieht.

Was passiert ist

CVE-2026-75604 ist eine Path-Traversal-Schwachstelle mit CVSS-Score 9.0. Prozent-kodierte Backslash-Sequenzen erreichen den Routing-Layer von Next.js, ohne vorher normalisiert zu werden. Auf einem Windows-Dateisystem löst der Backslash als Verzeichnistrenner auf — damit lassen sich Dateien außerhalb des On-Disk-Cache-Verzeichnisses schreiben, und von dort aus ist der Weg zur Codeausführung kurz.

Der Angriff braucht keine Authentifizierung und keine Benutzerinteraktion. Ein öffentlicher Proof-of-Concept war rund 24 Stunden nach der Veröffentlichung verfügbar. Selbst gehostete, von außen erreichbare Windows-Deployments sind damit das dringlichste Szenario.

Warum nur Windows

Der Unterschied liegt allein im Dateisystem. Unter Linux und macOS ist \ ein gewöhnliches Zeichen in einem Dateinamen — der prozent-kodierte Backslash bleibt Teil des Pfadsegments und verlässt das Cache-Verzeichnis nicht. Unter Windows ist \ ein Verzeichnistrenner, und genau diese Doppelbedeutung macht aus einer harmlos aussehenden Anfrage einen Schreibzugriff an beliebiger Stelle.

Die zweite Lücke betrifft uns nicht

Das August-Release schließt noch eine zweite kritische Schwachstelle: einen Heap-Overflow in der AVIF-Verarbeitung von libheif (CVSS 9.8). Sie greift nur, wenn eine Anwendung die AVIF-Bildoptimierung von next/image nutzt. Das ProcessCube® App-SDK verwendet diese Optimierung nicht — wer keine eigene AVIF-Optimierung aktiviert hat, ist hier außen vor.

Was das für das App-SDK bedeutet

next ist im App-SDK eine peerDependency. Das heißt: welche Next.js-Version tatsächlich läuft, entscheidet das Anwendungsprojekt, nicht das SDK. Ein SDK-Update allein schließt die Lücke also nicht.

Was ein SDK aber tun kann, ist verhindern, dass eine verwundbare Version überhaupt akzeptiert wird. Seit App-SDK 8.7.0 ist der zulässige Bereich entsprechend eingeschnürt:

"peerDependencies": {
  "next": ">=15.5.24 <16.0.0 || >=16.3.3"
}

Nachprüfen lässt sich das direkt an der Registry:

npm view @5minds/processcube_app_sdk@8.7.0 peerDependencies.next
# >=15.5.24 <16.0.0 || >=16.3.3

Ein npm install gegen ein verwundbares next schlägt damit sichtbar fehl, statt still durchzulaufen. Das ist der eigentliche Gewinn: Der Fehler tritt beim Bauen auf, nicht im Betrieb.

Prüfen, ob Sie betroffen sind

Entscheidend ist die Version, die Ihr Projekt tatsächlich auflöst — nicht die, gegen die das App-SDK gebaut wurde:

npm ls next

Alles unterhalb von 15.5.24 (15.5-Linie) beziehungsweise 16.3.3 (16.3-Linie) ist verwundbar.

Das Update

npm install next@15.5.24   # 15.5-Linie
# oder
npm install next@16.3.3    # 16.3-Linie

Anschließend neu bauen und deployen. Danach noch einmal npm ls next, um sicherzugehen, dass keine transitive Abhängigkeit eine ältere Version zurückholt.

Was wir getan haben

• App-SDK 8.7.0 schließt verwundbare Next.js-Versionen über die peerDependency aus; die mitgelieferten Referenz- und Lockfiles zeigen auf die gepatchten Versionen.
• docs.processcube.io — diese Seite hier — lief selbst auf 15.5.18 und läuft jetzt auf 15.5.24. Ausnutzbar war das nie, weil die Seite in einem Linux-Container läuft. Uns war trotzdem wichtig, nicht zum Update aufzurufen und dabei selbst darunter zu liegen.

Textbausteine zum Weitergeben

Wer eigene Kunden oder Betreiber informieren muss: unten zwei fertige Fassungen — einmal technisch, einmal für Empfänger ohne Framework-Kenntnisse.

npm install next@15.5.24   # 15.5-Linie
# oder
npm install next@16.3.3    # 16.3-Linie