Next.js, Astro, Nuxt und Headless WordPress – Sicherheit 2026

Headless hat die Angriffsfläche nicht beseitigt. Sie wurde verschoben. Die Bilanz 2025–26 zeigt wohin: React Server Components (CVE-2025-55182, unauthentisierte Remote-Code-Ausführung, veröffentlicht 3. Dezember 2025), Astros Server Islands und Image-Endpoint, Nuxt-Payload-Caching hinter einem CDN, npm-Pakete und ein WordPress-Backend, das noch PHP ausführt. Ein vollständig statischer Export ohne Server-Runtime reduziert das Framework-Risiko tatsächlich erheblich. Viele „statische" Websites sind aber gar nicht statisch. Im Folgenden die Vorfälle Framework für Framework, dann Secrets, CSP, die Supply Chain, die WordPress-Quelle und Edge-Controls – zum Abschluss eine Härtungstabelle, die Sie auf Ihren Stack anpassen können.

Warum „statisch bedeutet unhackbar" nicht mehr stimmt

Sagen Sie es zuerst deutlich: Falls Ihr Build plain HTML-, CSS- und JS-Dateien ausgibt und ein CDN sie bereitstellt, gibt es keinen Framework-Server zum Angreifen. Keinen React Server Components Endpoint. Keine Server Action. Keine Middleware zum Umgehen. Das ist eine echte kleine Angriffsfläche, und darum hatte das alte Jamstack-Versprechen Gewicht.

Aber schauen Sie sich an, was die meisten Next.js-, Astro- und Nuxt-Projekte 2026 tatsächlich deployed. Eine Server Action für das Kontaktformular. Middleware, die einen Cookie prüft. Ein Image-Optimierungs-Endpoint. Server Islands für einen personalisierten Header. ISR oder On-Demand-Revalidation. Jedes davon bedeutet, dass ein Prozess auf Anfragen lauscht, Eingaben parst und Umgebungsvariablen hält. Das ist ein Server. Er sieht nur nicht so aus in Ihrem Repo.

Die Frage ist also nicht „ist diese Website headless?" Sondern „was läuft zur Request-Zeit?" Es gibt drei ehrliche Antworten:

• Nichts. Pure statische Ausgabe. Ihr Risiko sitzt in der Build-Pipeline und dem CMS, nicht dem Framework.
• Ein kleiner, bekannter Satz von Endpoints. Image-Optimierung, ein Form Handler. Patchen Sie sie, beschränken Sie sie, rate-limitieren Sie sie.
• Eine vollständige Application-Runtime. SSR, Server Actions, Auth, Datenbankzugriff. Behandeln Sie es wie jede Web-App, weil es eine ist.

Ich habe den architektonischen Vergleich mit WordPress anderswo gemacht (siehe headless vs WordPress security), darum wiederhole ich ihn nicht. Dieser Post ist die Vorfallsbilanz und was man dagegen tut.

Next.js: React2Shell, Server Actions und die Proxy-Falle

React2Shell

CVE-2025-55182 (React) und CVE-2025-66478 (Next.js) wurden am 3. Dezember 2025 veröffentlicht. Kritisch. Unauthentisierte Remote-Code-Ausführung über manipulierte Anfragen an React Server Components. Laut Vercels Changelog sind betroffene Next.js-Versionen >=14.3.0-canary.77, 15.x und 16.x mit dem App Router. Die gefixtten Next.js-Releases sind 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 und 16.0.7; React ist gefixt in 19.0.1, 19.1.2 und 19.2.1.

Schnelligkeit zählt hier. Datadog Security Labs meldete öffentlichen Exploit-Code und aktive Exploitations-Versuche bis 5. Dezember 2025. Zwei Tage. Falls Ihr Patch-Prozess monatlich läuft, ist diese Lücke die Exposition.

Vercel versendet npx fix-react2shell-next, um betroffene Versionen zu bumpen. Egal welche Route Sie nehmen – bestätigen Sie die aktuelle gefixte Version für Ihre Release-Linie in der verlinkten Empfehlung, weil die Nachfolgeupdates die Ziele änderten.

Die Nachfolgeupdates vom 11. Dezember

Am 11. Dezember 2025 veröffentlichte das Next.js-Team ein weiteres Sicherheits-Update mit zwei zusätzlichen Problemen:

• CVE-2025-55184, Denial of Service (hoch). Ein App-Router-Request kann den Server zum Hängen bringen. Der erste Fix war unvollständig; der vollständige Fix wird unter CVE-2025-67779 verfolgt.
• CVE-2025-55183, Quellcode-Offenlegung (mittel). Ein präparierter Request kann eine Server Function dazu bringen, den kompilierten Quellcode anderer Server Functions zurückzugeben. Alles, was darin hartcodiert ist, wird offengelegt. Secrets, die zur Laufzeit aus der Umgebung gelesen werden, nicht.

Der Pages Router war nicht betroffen, und es gibt keinen Workaround. Upgrade. Behobene Versionen sind 14.2.35, 15.5.9 und 16.0.10 (siehe die Empfehlung für Ihre Version).

Die Lektion zu Server Actions ist eindeutig: Eine Server Action ist ein öffentlicher HTTP-Endpoint mit einer praktischeren Aufrufkonvention. Behandeln Sie ihre Argumente als feindselige Eingaben. Autorisieren Sie darin. Und schreiben Sie nie ein Secret als String-Literal in eine Datei, auf die eine Server Function zugreifen kann.

Middleware ist keine Autorisierungsgrenze

CVE-2025-29927, offengelegt am 21. März 2025 (CVSS 9.1), ermöglichte es einem präparierten x-middleware-subrequest-Header, die Middleware vollständig zu umgehen. Wenn Ihre einzige Authentifizierungsprüfung in der Middleware stattfand, wurde sie umgangen. Datadog's Analyse listet Fixes in 12.3.5, 13.5.9, 14.2.25 und 15.2.3 auf. Vercel-gehostete Apps waren auf Infrastrukturebene geschützt. Selbst-gehostete Apps waren bis zum Patch gefährdet.

Next.js 16 benennt middleware.ts in proxy.ts um und führt es standardmäßig auf der Node.js-Runtime aus; middleware.ts ist veraltet. Die Umbenennung ist ehrlich, finde ich. Ein Proxy sitzt vor der App. Er kann umleiten, umschreiben, Header hinzufügen. Er sollte nicht das Einzige sein, das zwischen einem Fremden und Ihren Daten steht.

Wo man die echte Prüfung durchführt:

1. In der Datenschicht, neben der Query, die die Zeilen zurückgibt.
2. In jeder Server Action, die etwas verändert.
3. In Route Handlern, pro Route.
4. Im Proxy nur als praktische Umleitung für abgemeldete Benutzer, nie als das Schloss.

Wenn das Entfernen von proxy.ts Daten offenlegen würde, befindet sich Ihre Autorisierung am falschen Ort.

Astro: Server Islands, Image Endpoints und Middleware-Pfade

Astros Standard ist statisch, was eine Stärke ist. Aber drei Empfehlungen von 2025 trafen die Teile, die eine Runtime hinzufügen.

Server Islands XSS. CVE-2025-64764, veröffentlicht am 19. November 2025, hoch (CVSS 7.1). Ein reflektiertes XSS über den slots-Parameter des Server-Islands-Endpoints. Es betraf jede App, die Server Islands nutzt, auch wenn die Island-Komponente keine Slots verwendet. Versionen 5.15.6 und älter waren betroffen; 5.15.8 behoben es. Details finden Sie in der GitHub-Empfehlung.

Image Endpoint SSRF. CVE-2025-58179 betraf den @astrojs/cloudflare-Adapter (11.0.3 bis 12.6.5). Mit output 'server' und dem Standard-Compile-Image-Service validierte der Image Endpoint URLs nicht, was Server-Side Request Forgery ermöglichte. SSRF ist unangenehm, weil der Server die Anfrage aus innerhalb Ihres Netzwerks stellt, wo er Metadaten-Services oder interne APIs erreichen kann.

Middleware-Pfad-Umgehung. Astro 5.15.8 behoben auch einen Pfad-Normalisierungs-Bypass mit doppelt codierten URLs (CVE-2025-64765). Dieselbe Fehlerfamilie wie der Next.js-Header-Trick: Autorisierung, die davon abhängt, dass die URL eine bestimmte Form hat.

Überprüfen Sie genaue Versionsbereiche in den withastro/astro-Sicherheitsempfehlungen, bevor Sie entscheiden, ob Sie betroffen sind. Ich werde nicht raten bei Grenzen, auf die ich nicht zeigen kann.

Astro 6 und eingebautes CSP

Astro 6 liefert eine CSP-API unter security.csp. Nach der Astro-6-Beta-Ankündigung hasht es gebündelte Skripte und Styles (SHA-256 standardmäßig), und es funktioniert in Build und Preview, aber nicht in Dev. Dieser letzte Punkt überrascht Leute: eine Seite, die unter astro dev gut aussieht, kann brechen, wenn die Policy in einem Production-Build angewendet wird. Testen Sie immer die erstellte Ausgabe.

Wenn du Astro-Websites für Kunden erstellst und diese Sicherheit von Anfang an haben möchtest, behandelt unsere Astro-Entwicklungsseite, wie wir Projekte aufsetzen.

Nuxt: Payload-Cache-Poisoning und was `runtimeConfig.public` offenlegt

CVE-2025-27415

Veröffentlicht 19. März 2025. High, CVSS 7.5, die Auswirkung ist Verfügbarkeit. Die Bedingung: du betreibst Nuxt hinter einem CDN, das die Query-String in seinem Cache-Key ignoriert. Ein Angreifer fordert etwas wie /?/_payload.json an. Nuxt rendert JSON für diese Anfrage. Das CDN speichert es unter dem Key für / und serviert dieses JSON allen Besuchern. Wiederholbar bei jeder Cache-Expiry. Betroffen: 3.0.0 bis vor 3.16.0; gepatcht in 3.16.0 (advisory).

Bemerke, was für einen Bug das ist. Nuxts Code und die CDN-Konfiguration verhielten sich einzeln vernünftig. Zusammen zerstörten sie deine Homepage. Die Lektion geht über „upgrade Nuxt" hinaus: CDN-Cache-Key-Konfiguration ist Teil der Applikationssicherheit. Jemand in deinem Team sollte dafür verantwortlich sein, und es sollte dokumentiert sein, nicht als Dashboard-Standard hinterlassen.

Ein schneller Staging-Check mit deiner eigenen Staging-Domain: Rufe die Seite mit einem ungewöhnlichen Query-String auf, schaue, was zurückkommt, dann fordere die saubere URL an und bestätige, dass es immer noch HTML ist. Wenn deine Cache-Schicht das Ignorieren von Query-Strings aus Performance-Gründen erlaubt, stelle sicher, dass die internen Routes des Frameworks von dieser Regel ausgenommen sind.

Was `runtimeConfig.public` offenlegt

Nuxt trennt runtimeConfig in private Keys (nur Server) und runtimeConfig.public (an den Browser gesendet). Der Name ist die Warnung. Alles unter public steht im Page-Payload zur Einsicht für jeden. Ein Stripe-Publishable-Key dort, kein Problem. Ein CMS-Admin-Token dort und du hast ihn veröffentlicht.

Secrets und Env-Variablen über alle drei

Jedes Framework hat eine Prefix-Regel, und das Prefix bedeutet „an den Browser senden":

Lies die Docs jedes Frameworks zu diesem Thema, weil die Details unterscheiden (Next.js fügt NEXT_PUBLIC_-Werte bei der Build-Zeit in das Bundle ein, das bedeutet auch, dass das Ändern eines Wertes einen Rebuild braucht). Das Prinzip unterscheidet sich nicht. Wenn eine Variable ein öffentliches Prefix hat, behandle sie, als wäre sie auf der Homepage gedruckt.

Drei Gewohnheiten fangen die meisten Fehler:

• Gib einen schreibfähigen Token nie hinter ein öffentliches Prefix, auch nicht „temporär".
• Durchsuche deine Built-Output (.next/static, dist/, .output/public) nach Token-Fragmenten, bevor du deployest.
• Gib deinem Frontend ein schreibgeschütztes, eng gefastes Credential für das CMS, getrennt von allem, das ein Editor benutzt.

Die Lektion von CVE-2025-55183

That Next.js source-exposure bug is a neat illustration. It could return compiled source of Server Functions. Secrets read from the environment at runtime weren't in that source. Secrets pasted into the code as literals were. The framework bug was the framework's fault; the leaked API key was ours. After patching, if a literal secret ever lived in a server function on an affected version, assume it was readable and rotate it. Moving it to an env var is the fix for next time, not for the past.

Security Header und CSP für Jamstack-Seiten

Bei statischem Hosting ist es leicht, Header zu vergessen, weil es keine Server-Config-Datei im Repo gibt. Aber Header sind der Ort, wo du billigen, echten Schutz vor XSS-Folgen bekommst (wie das Astro-Server-Islands-Problem oben).

Basis-Set zum Versand auf jeder Seite: Content-Security-Policy , Strict-Transport-Security , X-Content-Type-Options: nosniff , eine Referrer-Policy und frame-ancestors (innerhalb von CSP) oder X-Frame-Options.

Nonce oder Hash, nicht `unsafe-inline`

Eine CSP, die 'unsafe-inline' für Skripte erlaubt, hilft kaum gegen XSS. Du hast zwei echte Optionen:

• Hashes. Build-Zeit-SHA-256-Hashes jedes Inline-Skripts und jeder Inline-Style. Funktioniert gut für statische Ausgabe, weil sich der Inhalt nicht pro Request ändert. Das ist, was Astro 6's security.csp automatisiert.
• Nonces. Ein zufälliger Wert, der pro Request generiert wird, in den Header und in jedes Script-Tag eingefügt. Benötigt einen Server oder eine Edge Function zum Generieren, passt also besser zu SSR als zu statischen Dateien. Next.js dokumentiert ein Nonce-Pattern mit seiner Proxy-Schicht.

Wähle nach Rendering-Modell. Rein statisch: Hashes. Dynamisch: Nonces.

Liste jeden Third-Party-Origin pro Direktive auf

Das ist der mühsame Teil und hier versagen Policies. Analytics, Tag Manager, Fonts, Video Embeds, Chat Widgets, Formular-Provider, dein CMS-Image-Host. Jeder muss unter der richtigen Direktive aufgelistet sein: script-src , connect-src , img-src , font-src , frame-src. Ein Widget, das ein Skript von einem Origin lädt und eine API auf einem anderen aufruft, braucht beides.

Ein Beispiel-Header, um die Form zu zeigen (tausch deine echten Origins ein, und die Nonce muss pro Request generiert werden):

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-RANDOM' https://analytics.example.com; connect-src 'self' https://api.example.com; img-src 'self' data: https://cms.example.com; frame-ancestors 'none'; base-uri 'self'

Beginne mit Content-Security-Policy-Report-Only, sammle Violations eine oder zwei Wochen lang, fix die Liste, dann enforce. Und führe eine kurze Inventardatei mit Third-Party-Origins und wer jeden angefordert hat. Sechs Monate später erinnert sich niemand mehr, warum ein Chat-Widget in script-src ist.

Die npm-Lieferkette: chalk, debug und Shai-Hulud

Dein Framework mag gepatcht sein und dein Server abgeriegelt, und eine Abhängigkeit kann dir trotzdem die Woche ruinieren. Zwei Ereignisse von 2025 zeigen wie.

chalk und debug, 8. September 2025. Ein Maintainer wurde mit einer gefälschten 2FA-Reset-E-Mail von npmjs.help geangelt. Angreifer veröffentlichten bösartige Versionen von etwa 18 Paketen, darunter chalk und debug. Die Payload zielte auf den Diebstahl von Crypto-Wallet-Aktivitäten aus Browser-Bundles. Pakete wurden innerhalb von etwa 2 bis 2,5 Stunden entfernt, laut Upwind-Analyse. Zwei Stunden sind kurz. Aber ein CI-Job, der frische Versionen in diesem Fenster aufgelöst hat, sendete die Payload in die Produktion.

Shai-Hulud, September 2025. CISAs Alert vom 23. September 2025 beschreibt einen selbstreproduzierenden Wurm, der über 500 npm-Pakete kompromittierte. Er erntet GitHub-Token und Cloud-Keys (AWS, GCP, Azure), veröffentlichte sie in öffentlichen GitHub-Repos namens Shai-Hulud und republizierte sich selbst in andere Pakete mit den Zugangsdaten der Opfer. Eine zweite Welle im November 2025 traf angeblich etwa 796 Pakete (sekundäre Berichterstattung, daher die Zahl als berichtet behandeln).

Kontrollen, die sie enthalten hätten

Keiner der Incidents brauchte einen cleveren Exploit. Beide verließen sich auf automatisches Vertrauen in „latest". Also:

1. Committe deine Lockdatei und installiere mit `npm ci`. Es installiert genau das, was die Lockdatei sagt, und schlägt fehl, wenn package.json nicht zustimmt. Kein stilles Abdriften zu einer vergifteten Version.
2. Füge eine Verzögerung hinzu. Nimm Versionen nicht in der Stunde an, in der sie veröffentlicht werden. pnpm dokumentiert eine Einstellung für minimales Release-Alter dafür. Eine Verzögerung von sogar nur einem Tag hätte das chalk/debug-Fenster vollständig überstanden.
3. Deaktiviere Install-Skripte wo möglich. Würmer wie Shai-Hulud laufen durch Lifecycle-Skripte. Eine Beispiel-.npmrc-Zeile: ignore-scripts=true. Dann liste die wenigen Pakete, die wirklich einen Build-Schritt brauchen, zu.
4. CI-Token begrenzen. Ein Build-Job benötigt selten Publish-Rechte oder breite Cloud-Keys. Kurzlebige, nach dem Least-Privilege-Prinzip vergebene Zugangsdaten bedeuten, dass ein gestohlener Token wenig bringt.
5. Folgen Sie CISAs Empfehlungen. Überprüfen Sie Lockfiles einschließlich verschachtelter Abhängigkeiten, kontrollieren Sie Artifact-Caches, pinnen Sie auf bekannt sichere Versionen, rotieren Sie Entwickler-Credentials, erzwingen Sie Phishing-resistente MFA auf npm und GitHub, und aktivieren Sie Secret Scanning, Dependabot und Branch Protection.

Dieselbe Skepsis gilt für AI-Tools, die jetzt in Dev-Umgebungen sitzen. Ich habe aufgeschrieben, wie man Claude Code Skills, Plugins und MCP Server überprüft, weil sie eine weitere Möglichkeit sind, wie Third-Party-Code an Ihre Token gelangt.

Headless WordPress: Decoupling versteckt das Theme, nicht das PHP

Das ist der Teil, der Teams überrascht. Headless zu gehen entfernt die öffentliche Theme-Ebene. Es entfernt nicht WordPress. Die PHP-Anwendung, die Datenbank, die REST API und wp-admin sind alle noch da, normalerweise auf einem öffentlichen Hostname, weil das Frontend sie erreichen muss.

wp2shell

Das 2026-Beispiel ist deutlich. CVE-2026-63030 (REST API Batch-Route-Verwirrung, CVSS 9.8) kombiniert mit CVE-2026-60137 (SQL-Injection in WP_Query author__not_in, CVSS 5.9) führt zu unauthentisierter Remote Code Execution auf WordPress 6.9.0 bis 7.0.1. Standard-Installationen. Keine Plugins erforderlich. Der Einstiegspunkt ist /wp-json/batch/v1. Fixes wurden am 17. Juli 2026 in 7.0.2, 6.9.5 und 6.8.6 bereitgestellt, wie Tenables FAQ darstellt.

Angreifer waren schnell. Patchstack sah die ersten Exploitationsversuche etwa 90 Minuten nach der 7.0.2-Veröffentlichung, blockierte mehr als 65.000 Versuche von über 1.500 IPs und stellte fest, dass 97% auf den Batch-Endpoint zielten. Ein weiteres Detail ist wichtig für alle, die sich auf eine Firewall verlassen: URL-only WAF-Regeln reichen nicht aus, weil WordPress rest_route im POST-Body akzeptiert. Eine Regel, die /wp-json/batch/v1 im Pfad abgleicht, verfehlt ihn.

Das Backend absichern

Das Ziel: den WordPress-Origin zu einer Stelle machen, die Fremde nicht erreichen können, statt nur zu hoffen, dass er rechtzeitig gepatcht wird.

• Halten Sie den Origin wo möglich vom öffentlichen Internet fern. IP-Whitelist, ein authentifizierender Proxy oder ein privates Netzwerk zwischen Frontend und CMS. Wenn Sie Inhalte zur Build-Zeit für eine statische Site abrufen, muss der Origin nur mit Ihrem Build Runner kommunizieren.
• Exponieren Sie nur die Felder, die das Frontend nutzt. Trimmen Sie REST-Responses und GraphQL-Schemas. Weniger Daten raus, weniger zu missbrauchen.
• Deaktivieren Sie ungenutzte Routes, den Batch-Endpoint eingeschlossen, wenn nichts in Ihrem Stack ihn aufruft.
• Schränken Sie WPGraphQL ein. Schalten Sie öffentliche Introspection und unauthentifizierte Queries aus, es sei denn, Sie brauchen sie wirklich.
• Begrenzen Sie Application Passwords und Preview Tokens. Eins pro Integration, Least Privilege, widerrufen, wenn die Integration endet.
• Halten Sie Core Auto-Updates an. Bei einem 90-Minuten-Exploitationsfenster ist ein manueller wöchentlicher Patch-Tag das falsche Tempo.

Wenn Sie diesen Teil lieber an Spezialisten abgeben möchten, deckt unser WordPress-Sicherheitsservice das Absichern und Überwachen des Backends ab. Für die Architektur drumherum siehe den Headless WordPress 2026 Guide und unsere Headless WordPress Development-Seite.

Hosting und Edge Controls

Plattformen unterscheiden sich darin, was sie schützen, und es lohnt sich, die Spezifika zu kennen, statt es anzunehmen. Nehmen Sie CVE-2025-29927: Vercel-gehostete Apps waren auf Infrastrukturebene geschützt, selbstgehostete nicht. Das ist ein echter, dokumentierter Vorteil einer verwalteten Plattform. Netlify und Cloudflare laufen ebenfalls mit Schutzebenen an ihrem Edge (WAF-Features, DDoS-Mitigation, verwaltete Regeln, je nach Plan). Self-Hosting gibt Ihnen Kontrolle und legt diese Ebenen auf Ihre To-Do-Liste.

Die ehrliche Einordnung: Edge-Protections kaufen dir Zeit. Sie ersetzen nicht das Patchen. Eine Plattformregel, die heute ein Exploit-Muster blockiert, sagt nichts über das nächste Advisory aus, und ein selbstgehostetes Setup mit einer gut geführten Patch-Pipeline kann perfekt solide sein.

Was überall konfiguriert werden muss, egal wo du hostest:

• WAF-Regeln, die Bodies inspizieren, nicht nur Pfade. Das wp2shell rest_route-Detail ist das Beispiel zum Merken.
• Rate Limits auf Form-Handler, Server Actions, Login-Routes und alle Endpoints, die teure Operationen auslösen. Das schwächt auch Denial-of-Service-Bugs wie CVE-2025-55184 ab.
• Image `remotePatterns`. In Next.js beschränkt images.remotePatterns, von welchen Remote-Hosts der Image Optimizer fetchen darf. Astro hat äquivalente Einstellungen für Image-Domains und Patterns. Erlaube nur deinen CMS-Host und nichts sonst. Ein offener Image Proxy ist eine SSRF-Einladung.
• Cache-Key-Überprüfung. Nach dem Nuxt-Incident: Wisse, was dein CDN ignoriert.
• Origin-Schutz. Konfiguriere den App-Origin so, dass er Traffic nur von deinem CDN oder der Plattform akzeptiert, wo Setup das erlaubt. So können Angreifer nicht um die Edge herumlaufen.

Wenn du auf Next.js mit einer Datenbank dahinter baust, zeigt die Next.js- und Supabase-Entwicklungsseite, wie wir serverseitigen Zugriff scopen.

Die Hardening-Checkliste

Passe das an deinen Stack an. Jeder hier genannte Incident stammt aus den zitierten Quellen; bestätige aktuelle Fixed Versions in jeder verlinkten Advisory, statt irgendwelchen Tabellen (auch dieser hier) für Versionsnummern zu trauen.

FAQ

Ist der Pages Router von den Next.js-Problemen vom Dezember 2025 betroffen?

Bei CVE-2025-55183 (Quellcode-Offenlegung) und CVE-2025-55184 (Denial of Service) beschreibt die Next.js-Advisory den betroffenen Pfad als App Router mit Server Functions und besagt, dass der Pages Router von der Quellcode-Offenlegung nicht betroffen ist. Lesen Sie das nicht als „für immer sicher". React2Shell zielte auch auf React Server Components im App Router ab, und Sie müssen trotzdem auf einem gepatchten Release sein. Überprüfen Sie die Dezember-2025-Advisory für Ihre exakte Version.

Sollte ich Secrets nach dem Patchen rotieren?

Wenn ein Secret jemals in einer Server Function in einer betroffenen Next.js-Version hart-codiert war, ja. Gehen Sie davon aus, dass es gelesen werden konnte, weil der Bug kompilierten Quellcode zurückgab. Rotieren Sie es, dann verschieben Sie den Ersatz in eine Runtime-Umgebungsvariable. Secrets, die nur aus der Umgebung gelesen wurden, waren nicht in diesem Quellcode, also ist das Expositions-Argument für sie viel schwächer.

Wie bleibe ich über Advisories informiert, ohne jeden Changelog zu lesen?

Überwachen Sie die GitHub-Security-Advisories für die Repositories, von denen Sie abhängen (Next.js, withastro/astro, Nuxt), und schalten Sie Dependabot-Alerts für Ihre eigenen Repositories ein. Abonnieren Sie diese Feeds derjenigen Person, die für Patching zuständig ist, nicht eines gemeinsamen Postfachs, das niemand liest. Für WordPress Core halten Sie Auto-Updates an und fügen Sie einen Vulnerability-Feed wie den von Patchstack hinzu.

Kann ich wp-admin öffentlich lassen, wenn das Frontend nur zur Build-Zeit Content pullt?

Sie können, sollten aber nicht. Wenn das Frontend den Origin nur während Builds benötigt, gibt es keinen Grund, ihn allen auszusetzen. Allowlist Ihren Build-Runner und die IPs Ihrer Editoren, oder setzen Sie einen authentifizierenden Proxy davor. Editoren mit wechselnden IPs sind der übliche Grund, und ein Proxy mit Single Sign-On löst das.

Patch-Geschwindigkeit und Cache-Key-Konfiguration sind die zwei Dinge, die Teams am häufigsten falsch machen: Next.js- und WordPress-Exploits kamen Tage oder Stunden nach der Offenlegung, und der Nuxt-Bug existierte nur, weil ein CDN den Query String ignorierte. Überprüfen Sie, was tatsächlich zur Laufzeit ausgeführt wird, authorisieren Sie in der Datenschicht statt im Proxy, und halten Sie den WordPress-Origin aus dem offenen Internet.