Skip to content
RiverCore
Next.js SSRF-Lücke ermöglicht Diebstahl von Cloud-Zugangsdaten
Next.js SSRF vulnerabilityCVE-2026-44578cloud credentialsNext.js WebSocket SSRF attack vectorself-hosted Next.js security patch

Next.js SSRF-Lücke ermöglicht Diebstahl von Cloud-Zugangsdaten

16 Mai 20267 Min. LesezeitJames O'Brien

Stellen Sie sich einen Hotelconcierge vor, der bereitwillig jedes Zimmer im Gebäude für einen Gast anruft – ohne Rückfragen. Meistens ist das eine nützliche Funktion. An dem Tag, an dem ein Fremder hereinkommt und den Concierge bittet, den Safe des Managers anzurufen und die Kombination vorzulesen, wird es zur schlechtesten Stellenbeschreibung im ganzen Haus. Ungefähr das ist gerade dem WebSocket-Upgrade-Handler im Standard-Next.js-Node.js-Server passiert.

Am 15. Mai 2026 tauchte eine hochgefährliche SSRF-Schwachstelle im Next.js-Ökosystem auf, und wer seine eigene Infrastruktur betreibt, hat jetzt einen Concierge mit sehr schlechtem Urteilsvermögen an der Rezeption sitzen.

Was ist passiert

Der Fehler wird als CVE-2026-44578 und auf GitHub als GHSA-c4j6-fc7j-m34r geführt. Wie CyberSecurityNews berichtete, liegt die Schwachstelle darin, wie der integrierte Next.js-Node.js-Server WebSocket-Upgrade-Anfragen verarbeitet. Eine manipulierte Upgrade-Anfrage überredet den Server, als Proxy zu fungieren und die Nutzlast des Angreifers an ein beliebiges Ziel weiterzuleiten: ein internes Admin-Dashboard, einen Service-Mesh-Endpunkt oder den Cloud-Metadatendienst unter der link-lokalen Adresse, die jeder Backend-Entwickler fürchten gelernt hat.

Die Offenlegung erfolgte durch Tim Neutkens auf GitHub, und das Next.js-Wartungsteam hat Patches für zwei separate Release-Tracks veröffentlicht. Die bereinigten Versionen sind 15.5.16 und 16.2.5. Im gepatchten Build leitet der Server WebSocket-Upgrade-Anfragen nur dann weiter, wenn die Routing-Konfigurationen diese explizit als sichere externe Rewrites markieren. Standardmäßig gesperrt, optional aktivierbar. Das ist die richtige Grundlage für diese Art von Funktion – und wäre es wohl von Anfang an gewesen.

Zwei Klarstellungen, die für das Schadensausmaß wichtig sind. Erstens: Dies ist ausschließlich ein Problem bei selbst gehostetem Betrieb. Apps, die auf Vercel laufen, sind vollständig sicher, da Vercels Infrastruktur die anfällige WebSocket-Routing-Implementierung nicht verwendet. Zweitens ist dies kein theoretisches Problem. Der Bericht beschreibt Angreifer, die interne Netzwerkdienste abfragen, ungeschützte Admin-Dashboards erreichen und Cloud-Metadaten-Endpunkte treffen – die in einer einzigen Antwort temporäre IAM-Credentials, API-Tokens und Deployment-Secrets preisgeben können. Wer schon einmal eine Token-stehlende SSRF-Kette in einem Postmortem verfolgt hat, weiß, wie kurz der Weg von „seltsames WebSocket" zu „der Angreifer hat unsere Deploy-Rolle" ist.

Den öffentlichen CVE-Eintrag findet man im üblichen MITRE CVE-System unter CVE-2026-44578.

Technische Analyse

Das Kernproblem ist erschreckend einfach. HTTP/1.1 kennt eine eigenartige Zeremonie namens Upgrade-Handshake, bei der ein Client sagt: „Ich möchte bitte das Protokoll wechseln", und der Server – falls er zustimmt – den Socket an einen anderen Code-Pfad übergibt. WebSockets basieren auf diesem Mechanismus. Innerhalb eines Frameworks wie Next.js muss der Server entscheiden, was er mit einer Upgrade-Anfrage tut: sie lokal beenden, ignorieren oder an einen in der Route-Konfiguration definierten Upstream weiterleiten.

Das anfällige Verhalten besteht laut Offenlegung darin, dass der Standard-Server Upgrade-Anfragen in Szenarien weiterleitete, in denen er das nicht sollte. Ein Angreifer sendet ein speziell präpariertes Upgrade, und der Next.js-Prozess öffnet pflichtbewusst eine Verbindung zu einem Ziel, das der Angreifer beeinflusst. Da der Server selbst die ausgehende Anfrage ausführt, umgeht sie externe Firewalls. Die Pakete kommen nicht mehr aus dem öffentlichen Internet. Sie kommen von einer vertrauenswürdigen Maschine innerhalb Ihrer VPC, mit den Egress-Regeln und dem IAM-Kontext, die diese Maschine zufällig genießt.

Von dort aus ist es klassisches SSRF. Das attraktivste Ziel in jedem cloud-gehosteten Node-Prozess ist der Metadaten-Endpunkt: die link-lokale Adresse, die Instanz-Rollen-Credentials zurückgibt. Ein erfolgreicher Treffer liefert kurzlebige, aber sehr reale IAM-Tokens. Andere Pfade führen zu internen Admin-Panels, die als „sicher" galten, weil sie von außen unerreichbar waren, zu Redis- oder Elasticsearch-Instanzen, die nie mit einem authentifizierten Aufrufer rechneten, und zu allem anderen, was in einem privaten Subnetz liegt. Das ist OWASP A10:2021 in Lehrbuchform, bewaffnet durch ein Framework, das die meisten Teams als Black Box behandeln.

Das Patch-Design verrät etwas über die Denkweise der Maintainer. Anstatt zu versuchen, Ziele zu bereinigen oder nach Metadaten-IPs zu suchen (ein aussichtsloses Unterfangen, wie jeder bestätigen kann, der versucht hat, 169.254.169.254 über IPv6, DNS-Rebinding und Redirect-Ketten zu sperren), haben sie den Standard umgekehrt. Kein Proxying, es sei denn, die Route-Konfiguration sagt ausdrücklich „Ja, das ist ein externer Rewrite, und ich meine es so". Das ist der richtige Ansatz. Das Ärgerliche ist, dass die meisten Teams das implizite Upgrade-Forwarding-Verhalten erst bemerken werden, wenn sie das Changelog lesen.

Wer ist betroffen

Betroffen ist jeder, der selbst gehostetes Next.js auf dem Standard-Node.js-Server betreibt. In der Praxis ist das eine lange Liste: iGaming-Betreiber, die ihren spielerseitigen Stack aus Latenz- oder Compliance-Gründen in-house gebracht haben, Fintech-Teams, die Kundendaten nicht über eine Drittanbieter-Edge-Plattform leiten können, Krypto-Frontends, die sich bewusst für Self-Hosting entschieden haben, weil sie nicht wollten, dass ein einzelner Anbieter den Stecker ziehen kann, und jedes Unternehmen, das Next.js innerhalb einer regulierten VPC betreibt.

Der iGaming-Aspekt ist derjenige, der mich am meisten beunruhigt. Sportwettenanbieter betreiben tendenziell Admin-Panels für Trading-Desks, Risikokontrollen und Spielerverwaltung in internen Subnetzen – in der Annahme, dass die öffentliche Web-Schicht sie nicht erreichen kann. Ein SSRF in der öffentlichen Web-Schicht bricht diese Annahme mit einem einzigen Hop. Wenn derselbe Kubernetes-Cluster auch das Storefront betreibt, hat der Angreifer nun einen Proxy ins Trading-Floor.

Fintech-Teams haben eine andere Ausprägung desselben Problems. PCI-Umfang und SOC-2-Grenzen werden normalerweise im Netzwerk gezogen. Ein Web-Frontend, das plötzlich mit internen Diensten kommunizieren oder – schlimmer noch – AWS-Credentials über den Metadaten-Endpunkt erzeugen kann, reißt Lücken in Audit-Annahmen, deren Erstellung Monate gedauert hat.

Krypto-Frontends tragen ein besonderes Risiko: Wenn die selbst gehostete Next.js-Box Signing-Keys, Deployment-Secrets oder RPC-Credentials lokal gespeichert oder im selben Netzwerk erreichbar hat, kann ein Angreifer, der mit Cloud-Metadaten-Tokens abzieht, schnell pivotieren. Die nächsten 90 Tage sollten diese Teams für eine Credential-Rotation nutzen – unabhängig davon, ob sie glauben, betroffen gewesen zu sein –, da temporäre IAM-Tokens still auslaufen und die Logs zum Nachweis des Gegenteils oft nicht existieren.

Vercel-Kunden können sich, um es klar zu sagen, zurücklehnen. Das ist eine echte architektonische Dividende für den verwalteten Pfad. Es ist auch ein nützliches Argument beim nächsten Mal, wenn ein CFO fragt, warum die Hosting-Rechnung nicht niedriger ist.

Maßnahmenplan für Sicherheitsteams

Schritt eins diese Woche: aktualisieren. Next.js 15.5.16, wenn Sie auf dem 15.x-Track sind, 16.2.5, wenn Sie auf 16.x sind. Es gibt hier keine clevere Mitte. Der Patch ändert das Standardverhalten, also testen Sie Ihre Routen – insbesondere alles, was WebSocket-Rewrites zu einem Upstream tatsächlich nutzt –, da diese nun eine explizite Konfiguration benötigen, um weiter zu funktionieren.

Wo ein Patchen diese Woche nicht möglich ist (und es gibt immer einen Dienst irgendwo, der auf einem alten Build feststeckt, weil eine Node-Version fixiert oder ein eingefrorenes Vendor-Image vorhanden ist), empfiehlt die Offenlegung zwei kompensierende Kontrollen. Erstens: Konfigurieren Sie Ihren Reverse-Proxy oder Load-Balancer so, dass alle WebSocket-Upgrade-Anfragen blockiert werden, wenn die Anwendung sie nicht aktiv nutzt. Ein nginx-Connection- und Upgrade-Header-Strip vor dem Origin ist eine Fünf-Minuten-Änderung mit sehr hoher Rendite. Zweitens: Schränken Sie den ausgehenden Datenverkehr des Origin-Servers ein. Blockieren Sie Egress zu internen Cloud-Metadatendiensten und zu nicht zusammenhängenden internen Netzwerken auf der Ebene der Security Group oder Netzwerkrichtlinie.

Für AWS-Nutzer insbesondere ist der Wechsel zu IMDSv2 mit einem Hop-Limit von 1 seit Jahren Best Practice und der wirksamste einzelne Härtungsschritt gegen genau diese Angriffskette. Falls Sie das noch nicht getan haben, ist dies Ihr Anstoß. Ordnen Sie die TTP beim Schreiben des Postmortems MITRE ATT&CK T1552.005 (Cloud Instance Metadata API) zu, denn jemand in Ihrer Organisation wird fragen.

Schließlich: Suchen Sie aktiv. Prüfen Sie Ihre Zugriffslogs auf ungewöhnliche Upgrade: websocket-Anfragen, insbesondere solche mit merkwürdigen Host-Headern oder Zielen, die nicht Ihrem normalen Datenverkehr entsprechen. Wenn Sie welche aus der Zeit vor dem Patch finden, gehen Sie von einer Credential-Gefährdung aus und rotieren Sie.

Wichtigste Erkenntnisse

  • CVE-2026-44578 ist eine hochgefährliche SSRF-Schwachstelle im WebSocket-Upgrade-Handler des Standard-Node.js-Servers von Next.js, offengelegt von Tim Neutkens.
  • Sofort auf Next.js 15.5.16 oder 16.2.5 aktualisieren. Der Patch macht Upgrade-Proxying über explizite sichere externe Rewrite-Konfiguration zu einer Opt-in-Funktion.
  • Nur selbst gehostete Deployments sind betroffen. Auf Vercel gehostete Apps sind nicht anfällig, da Vercel den betroffenen WebSocket-Routing-Pfad nicht verwendet.
  • Wenn ein Patchen nicht möglich ist, WebSocket-Upgrades am Reverse-Proxy entfernen und ausgehenden Datenverkehr des Origins zu Cloud-Metadaten-Endpunkten und nicht zusammenhängenden internen Subnetzen sperren.
  • Die Concierge-Analogie gilt: Wenn der Empfang auf Anfrage jedes Zimmer anruft, ist die einzig sichere Richtlinie eine Gästeliste. Default-Deny bei internem Proxying ist die einzige Architektur, die einem entschlossenen Angreifer standhält.

Häufig gestellte Fragen

F: Ist meine auf Vercel gehostete Next.js-App von CVE-2026-44578 betroffen?

Nein. Die Schwachstelle betrifft ausschließlich selbst gehostete Next.js-Anwendungen, die auf dem integrierten Standard-Node.js-Server laufen. Vercels Infrastruktur verwendet die anfällige WebSocket-Routing-Implementierung nicht, sodass dort gehostete Apps dieser SSRF-Schwachstelle nicht ausgesetzt sind.

F: Welche Next.js-Versionen enthalten den Fix?

Das Next.js-Wartungsteam hat Patches für zwei Release-Tracks veröffentlicht. Die empfohlenen Upgrade-Ziele sind 15.5.16 und 16.2.5. Beide Versionen fügen strenge Sicherheitsprüfungen hinzu, sodass der Server WebSocket-Upgrade-Anfragen nur dann weiterleitet, wenn die Routing-Konfigurationen diese explizit als sichere externe Rewrites markieren.

F: Was können Angreifer mit dieser SSRF-Schwachstelle tatsächlich tun?

Sie können den Next.js-Server dazu bringen, manipulierte WebSocket-Upgrade-Anfragen an beliebige Ziele weiterzuleiten und dabei externe Firewalls zu umgehen, da die Anfrage vom vertrauenswürdigen Server selbst stammt. Damit können sie interne Dienste abfragen, ungeschützte Admin-Dashboards erreichen und Cloud-Metadaten-Endpunkte treffen, die temporäre IAM-Credentials, API-Tokens und Deployment-Secrets zurückgeben können.

JO
James O'Brien
RiverCore Analyst · Dublin, Ireland
TEILEN
// RELATED ARTICLES
StartseiteLösungenProjekteÜber unsKontakt
News06
Dublin, Irland · EUGMT+1
LinkedIn
🇩🇪DE