RCE-Sicherheitslücke in React und Next.js

 (github.com/vercel)
8 Punkte von GN⁺ 2025-12-04 | 1 Kommentare | Auf WhatsApp teilen
  • In React und Next.js wurde eine Remote Code Execution (RCE)-Schwachstelle gemeldet
  • Das Problem tritt im Inneren des Next.js-Pakets auf, und ein Angreifer kann über bösartige Eingaben die Ausführung beliebigen Codes auslösen
  • Vercel hat die Schwachstelle über den GitHub-Sicherheitsvermerk (GHSA-9qr9-h5gf-34mp) veröffentlicht und eine aktualisierte Version bereitgestellt
  • Nutzer sollten die Lücke durch ein Upgrade auf die neueste Version entschärfen
  • Dieser Fall rückt erneut die Bedeutung von Sicherheitsmanagement auf Framework-Ebene in den Fokus

Überblick zur RCE-Schwachstelle

  • In Next.js- und React-Umgebungen wurde eine Sicherheitslücke entdeckt, die eine Remote Code Execution ermöglicht
    • Es besteht das Risiko, dass ein Angreifer auf der Serverseite beliebigen JavaScript-Code ausführen kann
  • Diese Schwachstelle entsteht in der internen Codeverarbeitung des Next.js-Pakets
    • Konkrete Angaben zu den betroffenen Funktionen oder Modulen wurden nicht veröffentlicht

Auswirkungen und Reaktion

  • Vercel hat das Problem über den GitHub-Sicherheitsvermerk (GHSA-9qr9-h5gf-34mp) offiziell gemeldet
    • Der Vermerk wurde im Abschnitt für Sicherheitsmeldungen des Next.js-Repositories veröffentlicht
  • Betroffene Versionen wurden nicht genannt, jedoch wurde eine aktualisierte Version ausgerollt
    • Nutzern wird empfohlen, auf die neueste stabile Version zu wechseln

Sicherheitsmaßnahmen

  • Alle Projekte mit dem Next.js-Paket müssen sofort ihre Version prüfen
    • Die Next.js-Version in package.json sollte auf dem neuesten Stand gehalten werden
  • Neben der Veröffentlichung des gepatchten Versionsstands nennt Vercel keine weiteren kurzfristigen Milderungsmaßnahmen
  • Die technischen Details der Schwachstelle bleiben nicht öffentlich; aus Sicherheitsgründen werden nur eingeschränkte Informationen bereitgestellt

Bedeutung

  • Diese Lücke zeigt das Risiko der Codeausführung in Server-Rendering-Umgebungen
  • Betreiber von React- und Next.js-basierten Diensten sollten Sicherheitsupdates regelmäßig einspielen
  • Sicherheitslücken auf Framework-Ebene können die Gesamtsicherheit einer Anwendung direkt beeinträchtigen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-04
Hacker-News-Meinungen

  • Diese Schwachstelle ist ein Fall, in dem das Worst-Case-Szenario, vor dem seit der Einführung von RSC/Server Actions gewarnt wurde, Realität geworden ist
    Der Server hat nicht vertrauenswürdige Eingaben des Clients direkt deserialisiert, dann nach Modulen und Export-Namen gesucht und sie ausgeführt
    Man kann das zwar mit einem hasOwnProperty-Patch verhindern, aber das Grundproblem ist, dass nicht klar erkannt wurde, dass React hier eine RPC-Schicht baut
    Traditionelle RPC-Frameworks wie gRPC oder SOAP ziehen mit expliziten Schemas und Service-Definitionen klare Grenzen, React ist dagegen riskant, weil es alle APIs exponiert, die der Bundler sehen kann
    Sicherheitsprobleme aus diesem Design dürften sich auch künftig wiederholen

    • Das wirkt einfach wie Nachlässigkeit
      Selbst mit einem expliziten Schema bringt es nichts, wenn im letzten Schritt nicht vertrauenswürdige Eingaben auf beliebige Objekte im Server-Namespace verweisen können
    • Tatsächlich werden nicht alle vom Client angeforderten Endpunkte offengelegt
      Exponiert werden nur Funktionen, die mit "use server" markiert sind, und dem React-Team ist bewusst, dass es ein RPC-System entwirft
      Solche Bugs können auch in anderen RPC-Systemen problemlos auftreten (ich bin React-Mitwirkender)
    • Dass so etwas trotz vorheriger Warnungen passiert ist, lässt sich am Ende nur als nachlässige Implementierung sehen
    • Aus Sicht normaler Nutzer fragt man sich, ob man sicher ist, wenn man diesen Ansatz nicht verwendet
      Aber ein altes privates Repo weiterzupflegen ist auch keine gute Option

  • Next hat statische Builds als einzigen Vorteil
    Wenn diese Unterstützung wegfällt, gibt es keinen Grund mehr, es zu verwenden

  • Laut dem Sicherheitshinweis von Facebook/Meta gibt es in React Server Components 19.0.0 bis 19.2.0 eine Schwachstelle für Remote Code Execution (RCE) vor der Authentifizierung
    Auch im Hinweis im offiziellen React-Blog wird erklärt, dass Angreifer wegen der Struktur, in der Clients Server-Funktionen aufrufen können, bösartige HTTP-Anfragen konstruieren und dadurch beliebigen Code auf dem Server ausführen können

    • Wenn der Fix im Hinzufügen einer hasOwnProperty-Prüfung besteht, lief der Angriff vermutlich über Eigenschaften der Prototyp-Kette (__proto__ usw.)
    • Wenn „Clients können Server-Funktionen aufrufen“ eine beabsichtigte Funktion ist, wirkt das wie ein ziemlich beängstigendes Design

  • Der Fix-Commit scheint dieser Commit zu sein
    Er scheint zusammen mit mehreren anderen Änderungen gesquasht worden zu sein, sodass Details verdeckt wurden
    Im Code ist an vier Stellen ein Muster zu sehen, das die Liste exponierter Funktionen per Whitelist-Ansatz einschränkt

    • Oder vielleicht ist dieser Commit die Ursache („kritische Sicherheitslücke behoben“ steht ausdrücklich dabei)

  • Vercel blockiert bösartige Anfrage-Muster bereits durch Schutz auf Plattformebene
    Siehe Ankündigung
    Cloudflare hat ebenfalls proaktiv mit WAF-Regeln reagiert

    • In Zusammenarbeit mit mehreren Partnern wurden vorbeugende Gegenmaßnahmen ausgerollt
      Trotzdem wird dringend empfohlen, Abhängigkeiten von Next, React und anderen Meta-Frameworks sofort zu aktualisieren
    • Auch die Reaktionsmeldung von Netlify und der Blogbeitrag zu Deno Deploy/Subhosting sind lesenswert
    • Ich habe selbst gepatcht und neu gebaut und zur Absicherung gegen mögliche Lücken zusätzlich Crowdsec-WAF-Regeln ergänzt

  • Mit Verweis auf das PoC-Repository habe ich die Schwachstelle nachgestellt

    • Selbst mit gepatchtem react-server-dom-webpack ließ sich RCE ausführen, daher scheint der Mechanismus nicht vollständig korrekt verstanden zu sein
      Es wäre gut, eine Demo in einem echten Next.js-Projekt zu sehen
    • Trotzdem war die Zusammenfassung wirklich beeindruckend

  • So sehr, dass schon der Satz „ohne Vercel kein RCE“ fällt, zeigt dieser Vorfall den Zusammenhang zwischen Hosting-Umgebung und Sicherheit

  • Ein CVE-Score von 10.0 ist bei einem so weit verbreiteten Projekt ein schockierender Wert

    • Beim betroffenen Paket react-server-dom-webpack steht ausdrücklich, es sei „experimentell und auf eigenes Risiko“
      Trotzdem hat es mehr als 310.000 wöchentliche Downloads
    • In solchen Fällen muss CVSS 10.0 klar genannt werden, damit das nicht von PR-artigen Aussagen überdeckt wird
    • React ist weit verbreitet, aber React Server Components sind noch nicht annähernd so allgegenwärtig

  • Es ist schwer nachzuvollziehen, warum das React-Team so viel Zeit in eine derart verwirrende Funktion steckt
    Worin der Vorteil gegenüber SSR liegen soll und wie groß der Performance-Gewinn wirklich ist, ist fraglich
    Seit der Einführung von Hooks ist die Developer Experience schlechter geworden, und statt das zu verbessern, kommt noch mehr Komplexität dazu
    Lieber hätte ich, dass man den eigentlichen Kontrollfluss von JS in der Komponentenlogik natürlich verwenden kann

    • Server Components haben mit SSR nicht direkt zu tun
      Ich sehe sie als eine komponentisierte BFF-(Backend-for-Frontend)-Schicht
      Jedes UI-Fragment ist direkt mit der zugehörigen Backend-Logik verbunden und kann Daten ohne fetch-Aufrufe laden
      So lassen sich Frontend und Backend leichter gemeinsam weiterentwickeln, und benötigte Daten können fein granular geladen werden
      Am Ende kann man serverspezifische Logik nur für die UI natürlich in die Komponentenstruktur einbetten
    • Schade, dass React zum „Standard-Framework“ geworden ist
      Das compilerbasierte Modell von Svelte oder React ist deutlich angenehmer zu handhaben
    • Grundsätzlich halte ich eher die Grenzen der JS-Sprache und fehlenden Wettbewerb für das Problem
      Vue, Svelte, Angular usw. brauchen alle einen separaten Compiler und eigene Dateiendungen
      React/JSX wird dagegen schon auf Ebene des Präprozessors bevorzugt
      Rust hat solche Probleme mit seinem Makro-System gelöst — etwa unterstützen Leptos oder Yew JSX oder HTML-Templates innerhalb normaler .rs-Dateien
      Wenn JS keine solche Erweiterbarkeit bekommt, bleibt das Web vermutlich auch künftig eine komplexe und ineffiziente Umgebung
    • Ich mag Hooks :)
    • RSC ist ein Ersatzversuch, der daraus entstanden ist, dass man SSR nicht schnell genug machen konnte
      Man wollte die Last auf der Client-Seite senken, aber selbst das wirkt nicht wirklich gelungen

  • Auch die detaillierte Erklärung im React-Blog ist lesenswert