CVE-2025-29927 – <\/p>\n
Am 21.\u00a0M\u00e4rz\u00a02025 gaben die Maintainer von Next.js eine neue Sicherheitsl\u00fccke bekannt, die eine Umgehung der Autorisierung erm\u00f6glicht\u00a0\u2013 CVE-2025-29927. Diese Sicherheitsl\u00fccke kann leicht ausgenutzt werden, um die Autorisierung zu umgehen. In einigen F\u00e4llen kann die Ausnutzung der Sicherheitsl\u00fccke auch zu Cache Poisoning und einem Denial-of-Service f\u00fchren.
\nWelche Versionen von Next.js sind betroffen?
\nNext.js 15.x\u00a0\u2013 von Version 15.0.0 bis einschlie\u00dflich 15.2.2.<\/p>\n
Next.js 14.x\u00a0\u2013 von Version 14.0.0 bis einschlie\u00dflich 14.2.24.<\/p>\n
Fr\u00fchere Next.js-Versionen\u00a0\u2013 ab Version 11.1.4 bis einschlie\u00dflich 13.5.6.
\nAngriffsszenarien f\u00fcr CVE-2025-29927
\nDamit die Schwachstelle \u00fcberhaupt ausgenutzt werden kann, muss der betroffene Next.js-Server eine Next.js-Middleware verwenden. Dies umfasst das Einbinden einer Datei middleware.js oder middleware.ts ( _middleware.js oder _middleware.ts\u00a0 f\u00fcr \u00e4ltere Versionen von Next.js). Diese Datei definiert und exportiert die Funktion middleware, die die Logik enth\u00e4lt, die bei jeder eingehenden HTTP-Anfrage ausgef\u00fchrt wird.
\nUmgehung der Autorisierung
\nDies ist das wahrscheinlichste Szenario, das CVE-2025-29927 ausnutzt.<\/p>\n
Dieses Szenario ist relevant, wenn der Next.js-Server des Opfers die Middleware-Funktion zur Durchf\u00fchrung der Autorisierung verwendet (und die zugrunde liegende Anwendung keine anderen Autorisierungsebenen verwendet).<\/p>\n
Szenario in Bezug auf die Autorisierungs-Middleware ohne Ausnutzung von CVE-2025-29927<\/p>\n
Autorisierungs-Middleware-Szenario ohne Ausnutzung von CVE-2025-29927<\/p>\n
Denial of Service durch Cache Poisoning
\nNext.js-Middleware kann auch bei der Lokalisierung von Websites helfen. Beispielsweise kann die Middleware Nutzer basierend auf ihrem Standort automatisch weiterleiten, indem sie etwa \/en f\u00fcr englischsprachige oder \/fr f\u00fcr franz\u00f6sische Besucher hinzuf\u00fcgt. Wenn jemand CVE-2025-29927 ausnutzt und die Middleware umgeht, die diese Weiterleitungen durchf\u00fchrt, landen sie, statt auf einer lokalisierten Seite, auf der Website-Root (\/), f\u00fcr die die Entwickler nie eine Seite erstellt haben. Wozu f\u00fchrt das? Einem 404-Fehler oder einem 500-Serverfehler, je nach Konfiguration.<\/p>\n
Wenn die Website ein\u00a0CDN oder eine andere Caching-Schicht verwendet, k\u00f6nnen diese Fehlerantworten gespeichert und zuk\u00fcnftigen Besuchern bereitgestellt werden. Sobald sie zwischengespeichert sind, sehen legitime Nutzer m\u00f6glicherweise weltweit fehlerhafte Seiten. Dadurch entsteht ein selbst verursachter Ausfall, der die Verf\u00fcgbarkeit beeintr\u00e4chtigt, ohne eine einzige Zeile Code zu \u00e4ndern.<\/p>\n
Redirector-Middleware-Szenario ohne Ausnutzung von CVE-2025-29927
\n\u00a0<\/p>\n
Redirector-Middleware-Szenario mit Ausnutzung von CVE-2025-29927
\n\u00a0
\nNext.js-Middleware verstehen
\nNext.js-Middleware ist eine leistungsstarke Funktion, die in Next.js v12 eingef\u00fchrt wurde und Entwicklern erm\u00f6glicht, Code auszuf\u00fchren, bevor eine Anfrage abgeschlossen wird. Middleware wird am Edge ausgef\u00fchrt, n\u00e4her am Nutzer als herk\u00f6mmlicher serverseitiger Code, und kann Response-Header \u00e4ndern, Anfragen umschreiben oder umleiten und\u00a0\u2013 was am wichtigsten ist\u00a0\u2013 Authentifizierungs- und Autorisierungspr\u00fcfungen implementieren.<\/p>\n
Middleware in Next.js wird vor dem Rendering ausgef\u00fchrt und kann \u00fcber Matcher-Konfigurationen f\u00fcr die Ausf\u00fchrung auf bestimmten Pfaden konfiguriert werden.<\/p>\n
Einige Anwendungsbeispiele f\u00fcr Next.js-Middleware sind:<\/p>\n
\t\u00dcberpr\u00fcfung von Authentifizierungs-Tokens
\n \tImplementierung einer rollenbasierten Zugriffskontrolle
\n \tWeiterleitung nicht authentifizierter Benutzer<\/p>\n
Eine typische Next.js-Middleware-Implementierung, die eine Authentifizierung durchf\u00fchrt, k\u00f6nnte wie folgt aussehen:<\/p>\n
import { NextResponse } from ’next\/server‘
\n import type { NextRequest } from ’next\/server‘<\/p>\n
export function middleware(request: NextRequest) {
\n \/\/ Token des Benutzers aus den Cookies abrufen
\n const token = request.cookies.get(‚token‘).value<\/p>\n
\/\/ Pr\u00fcfen, ob der Benutzer authentifiziert ist
\n const isAuthenticated = validateToken(token)<\/p>\n
\/\/ Wenn nicht authentifiziert, zur Anmeldung weiterleiten
\n if (!isAuthenticated) {
\n return NextResponse.redirect(new URL(‚\/login‘, request.url))
\n }<\/p>\n
\/\/ Bei erfolgreicher Authentifizierung mit der gesch\u00fctzten Route fortfahren
\n return NextResponse.next()
\n }<\/p>\n
\/\/ Konfigurieren, welche Routen diese Middleware verwenden
\n export const config = {
\n matcher: [‚\/dashboard\/:path*‘, ‚\/settings\/:path*‘],
\n }
\n\u00a0<\/p>\n
Technische Analyse von CVE-2025-29927
\nCVE-2025-29927 deckt einen kritischen Fehler bei der Verarbeitung bestimmter Anfragetypen durch die Next.js-Middleware auf, der zu einer m\u00f6glichen Umgehung von Authentifizierung und Autorisierung f\u00fchrt.<\/p>\n
Diese Schwachstelle betrifft Anwendungen, die in bestimmten Konfigurationen Middleware zur Zugriffskontrolle verwenden.<\/p>\n
Die Schwachstelle beruht auf der inkonsistenten Verarbeitung der benutzerdefinierten x-middleware-subrequest-Header durch Next.js. Wenn dieser Header in Anfragen an gesch\u00fctzte Routen enthalten ist, erlaubt Next.js der Anfrage f\u00e4lschlicherweise, die Ausf\u00fchrung der Middleware vollst\u00e4ndig zu umgehen. Der Header veranlasst die Next.js-Laufzeitumgebung, die Phase der Middleware-Auswertung zu \u00fcberspringen, w\u00e4hrend der zugrundeliegende Route-Handler weiterhin verarbeitet wird.<\/p>\n
Um diese Schwachstelle auszunutzen, muss ein Angreifer beim Zugriff auf gesch\u00fctzte Ressourcen lediglich den Header x-middleware-subrequest zu seinen HTTP-Anfragen hinzuf\u00fcgen. Beispielsweise wird eine Anfrage an \/api\/admin\/users, die normalerweise durch Autorisierungspr\u00fcfungen der Middleware blockiert w\u00fcrde, bei Vorhandensein dieses Headers normal verarbeitet. Der Server verarbeitet die Anfrage, als w\u00e4re die Middleware bereits ausgef\u00fchrt worden und h\u00e4tte sie genehmigt, wodurch eine vollst\u00e4ndige Umgehung der Sicherheitsmechanismen entsteht. Diese Header-Manipulation l\u00e4sst sich einfach mit Browser-Entwicklertools, curl-Befehlen oder einfachen Skripten umsetzen.<\/p>\n
Der anf\u00e4llige Code in der neuesten anf\u00e4lligen Version (v15.2.2) lautet wie folgt:<\/p>\n
export const run = withTaggedErrors(async function runWithTaggedErrors(params) {
\n const runtime = await getRuntimeContext(params)
\n const subreq = params.request.headers[`x-middleware-subrequest`] [1]
\n const subrequests = typeof subreq === ’string‘ ? subreq.split(‚:‘) : [] [2]<\/p>\n
const MAX_RECURSION_DEPTH = 5
\n const depth = subrequests.reduce( [3]
\n (acc, curr) => (curr === params.name ? acc + 1 : acc),
\n 0
\n )<\/p>\n
if (depth >= MAX_RECURSION_DEPTH) { [4]
\n return {
\n waitUntil: Promise.resolve(),
\n response: new runtime.context.Response(null, {
\n headers: {
\n ‚x-middleware-next‘: ‚1‘,
\n },
\n }),
\n }
\n }
\n\u00a0<\/p>\n
Der Header x-middleware-subrequest wird in [1] aus der Anfrage \u00fcbernommen.
\nAnschlie\u00dfend wird er mithilfe des Trennzeichens : in [2] aufgeteilt und durch eine Reduce-Funktion gef\u00fchrt, die z\u00e4hlt, wie viele Elemente in diesem Array (subrequests) in [3] mit dem Dateinamen der Middleware \u00fcbereinstimmen.
\nWenn diese Zahl in [4] gleich oder gr\u00f6\u00dfer als MAX_RECURSION_DEPTH (also 5) ist, umgeht sie die Funktionalit\u00e4t der Middleware und leitet sie an ihre Route weiter.
\nM\u00f6gliche Werte f\u00fcr Attack-Header<\/p>\n
Wie bereits erl\u00e4utert, lautet der Name des anf\u00e4lligen Headers\u00a0 x-middleware-subrequest. Der ihm zugewiesene Wert h\u00e4ngt von Next.js ab, da er entsprechend dem Wert von middlewareInfo.name festgelegt wird, der im Wesentlichen dem Pfad zur Datei middleware.js oder middleware.ts entspricht.<\/p>\n
Vor Version 12.2 hie\u00df die Middleware-Datei tats\u00e4chlich _middleware.js\/_middleware.ts und konnte sich auf jeder Ebene des Unterverzeichnisses befinden, auf das man zugreifen m\u00f6chte. In diesem Fall versuchen wir, auf \/admin\/dashboard zuzugreifen, was bedeutet, dass middlewareInfo.name pages\/_middleware\u00a0oder\u00a0pages\/admin\/_middleware h\u00e4tte sein k\u00f6nnen. H\u00e4tten wir\u00a0dashboard\u00a0als Verzeichnis mit einer\u00a0index.js-Datei\u00a0festgelegt,h\u00e4tte es auch\u00a0pages\/admin\/dashboard\/_middleware sein k\u00f6nnen.<\/p>\n
Wenn wir beispielsweise mit unserem PoC-Code eine Next.js-Version vor 12.2 verwendet h\u00e4tten, h\u00e4tten wir middleware.js\u00a0in das Verzeichnis pages\u00a0verschieben und in _middleware.js umbenennen m\u00fcssen, und unsere \u201eb\u00f6sartige\u201c HTTP-Anfrage w\u00fcrde lauten:<\/p>\n
GET \/admin\/dashboard HTTP\/1.1
\n x-middleware-subrequest: pages\/_middleware
\n\u00a0<\/p>\n
Seit Version 12.2 und bis Version 13 muss die Middleware-Datei im Stammverzeichnis des Projekts vorhanden sein und muss middleware.js\/middleware.ts hei\u00dfen. Um diese Versionen von Next.js anzugreifen, w\u00fcrde die Payload f\u00fcr den Header also einfach middleware lauten\u00a0\u2013 und wir wissen mit Sicherheit, dass sie sich im Stammverzeichnis befindet.<\/p>\n
H\u00e4tten wir eine Next.js-Version zwischen den Versionen 12.2 und 13 verwendet, w\u00fcrde sich unsere \u201eb\u00f6sartige\u201c Anfrage wie folgt \u00e4ndern:<\/p>\n
GET \/admin\/dashboard HTTP\/1.1
\n x-middleware-subrequest: middleware
\n\u00a0<\/p>\n
Ab Version 13 von Next.js wurde die zuvor beschriebene Rekursionspr\u00fcfung implementiert \u2013 das bedeutet, dass ein Angreifer den b\u00f6sartigen Header auf middleware:middleware:middleware:middleware:middleware setzen m\u00fcsste, um 5 Rekursionsebenen zu simulieren.<\/p>\n
Da unser PoC auf dieser Version l\u00e4uft, ist dies ein Ausschnitt aus der von uns verwendeten Anfrage:<\/p>\n
GET \/admin\/dashboard HTTP\/1.1
\n x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware
\n\u00a0<\/p>\n
Wichtig ist, dass sich der Middleware-Code in allen Phasen in einem src\u00a0-Verzeichnis h\u00e4tte befinden k\u00f6nnen \u2013 was bedeuten w\u00fcrde, dass zum Ausnutzen src den oben dargestellten Werten vorangestellt werden m\u00fcsste. Wenn wir unseren PoC-Code beispielsweise in einem src\u00a0-Verzeichnis abgelegt h\u00e4tten, h\u00e4tte unsere Payload wie folgt aussehen m\u00fcssen:<\/p>\n
GET \/admin\/dashboard HTTP\/1.1
\n x-middleware-subrequest: src\/middleware:src\/middleware:src\/middleware:src\/middleware:src\/middleware.
\n\u00a0<\/p>\n
Ausnutzung von CVE-2025-29927
\nWie immer ist es am besten, die vollst\u00e4ndige Ausnutzung der Schwachstelle zu sehen, um zu verstehen, welche Next.js-Instanzen anf\u00e4llig w\u00e4ren.<\/p>\n
Wir haben eine eigene PoC-Website mit folgendem Arbeitsbaum eingerichtet:<\/p>\n
\u251c\u2500\u2500 middleware.js
\n\u251c\u2500\u2500 package-lock.json
\n\u251c\u2500\u2500 package.json
\n\u2514\u2500\u2500 pages
\n\u251c\u2500\u2500 admin
\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 dashboard.js
\n\u2514\u2500\u2500 index.js<\/p>\n
Zun\u00e4chst unsere Anmeldeseite:<\/p>\n
Folgendes passiert, wenn ein Benutzer ohne Administratorrechte versucht, sich anzumelden:<\/p>\n
Und dies ist das Admin-Dashboard unter\u00a0\/admin\/dashboard mit den richtigen Anmeldedaten:<\/p>\n
Kommen wir zum Exploit\u00a0\u2013 versuchen wir zun\u00e4chst, eine GET-Anfrage an\u00a0\/admin\/dashboard ohne den sch\u00e4dlichen Header zu senden:<\/p>\n
Wir erhalten eine \u201e401 Unauthorized\u201c-Antwort, da unsere Middleware aktiv wird und erkennt, dass es sich nicht um ein Admin-Konto handelt:<\/p>\n
Versuchen wir jedoch dasselbe noch einmal mit dem Header\u00a0x-middleware-subrequest<\/p>\n
und wir erhalten eine 200-OK-Antwort!<\/p>\n
Mithilfe der Webvorschau k\u00f6nnen wir au\u00dferdem sehen, dass wir das Dokument bereits zuvor erhalten haben:<\/p>\n
Behebung von CVE-2025-29927
\nVersions-Upgrade
\nDer beste Weg, CVE-2025-29927 zu beheben, ist ein Upgrade Ihrer Next.js-Version auf eine der behobenen Versionen\u00a0\u2013<\/p>\n
\t15.2.3
\n \t14.2.25<\/p>\n
Stellen Sie sicher, dass Sie alle potenziell gef\u00e4hrdeten Versionen identifizieren, von 11.1.4 bis einschlie\u00dflich 13.5.6, 14.2.24 sowie 15.2.2, und aktualisieren Sie diese auf die neue, korrigierte Version.
\nBlockieren des anf\u00e4lligen Headers im Webserver
\nWenn ein Upgrade keine Option ist, kann die Schwachstelle entsch\u00e4rft werden, indem Sie Ihren Webserver anweisen, den `x-middleware-subrequest` aus eingehenden Anfragen zu entfernen \u2013<\/p>\n
F\u00fcgen Sie in Apache die folgende Direktive zu Ihrer .htaccess-Datei hinzu (mod_headers muss installiert und aktiviert sein)\u00a0\u2013
\n <IfModule mod_headers.c>
\n RequestHeader unset x-middleware-subrequest
\n <\/IfModule>
\nBearbeiten Sie in NGINX Ihre Datei nginx.conf und f\u00fcgen Sie Ihrem Serverblock die folgende proxy_set_header-Direktive hinzu\u00a0\u2013<\/p>\n
\u00a0proxy_set_header x-middleware-subrequest "";<\/p>\n
Beispiel:
\n server {
\n\u00a0 listen 80;
\n\u00a0 server_name your_domain.com;
\n\u00a0 location \/ {
\n\u00a0 \u00a0 proxy_set_header x-middleware-subrequest "";
\n\u00a0 }
\n }
\nF\u00fcgen Sie in Express.js die folgende Direktive zu Ihrem JavaScript-Quellcode hinzu\u00a0\u2013
\n \/\/ Middleware zum Entfernen des Headers x-middleware-subrequest
\n app.use((req, res, next) => {
\n delete req.headers[‚x-middleware-subrequest‘];
\n next();
\n });
\nBlockieren des anf\u00e4lligen Headers mit einer WAF
\nWenn ein Upgrade keine Option ist, kann die Schwachstelle durch den Einsatz einer Web Application Firewall entsch\u00e4rft werden, die Anfragen blockiert, welche den HTTP-Header x-middleware-subrequest` enthalten.
\nBehebung von CVE-2025-29927 mit JFrog Xray und JFrog Advanced Security
\nWie immer kann JFrog Security Essentials (Xray) verwendet werden, um das Vorkommen von Next.js in Ihrer gesamten Codebasis und kompilierten Artefakten zu identifizieren, einschlie\u00dflich Docker-Containern, Repository-Paketen und sogar eigenst\u00e4ndigen Bin\u00e4rdateien.<\/p>\n
Zus\u00e4tzlich wurde JFrog Advanced Security um einen Contextual Analysis Scanner erweitert, der automatisch \u00fcberpr\u00fcft, ob Ihre Next.js-Bereitstellung tats\u00e4chlich f\u00fcr CVE-2025-29927 anf\u00e4llig ist, indem er pr\u00fcft, ob eine Next.js-Middleware verwendet wird.<\/p>\n
JFrog Plattform: JFrog Contextual Analysis f\u00fcr CVE-2025-29927 von Next.js (Klicken Sie auf das Bild f\u00fcr Vollansicht)<\/p>\n
Informieren Sie sich im JFrog Security Research Center \u00fcber die neuesten CVEs, Schwachstellen und Fehlerbehebungen.<\/p>\n","protected":false},"excerpt":{"rendered":"
CVE-2025-29927 – Am 21.\u00a0M\u00e4rz\u00a02025 gaben die Maintainer von Next.js eine neue Sicherheitsl\u00fccke bekannt, die eine Umgehung der Autorisierung erm\u00f6glicht\u00a0\u2013 CVE-2025-29927. Diese Sicherheitsl\u00fccke kann leicht ausgenutzt werden, um die Autorisierung zu umgehen. In einigen F\u00e4llen kann die Ausnutzung der Sicherheitsl\u00fccke auch zu Cache Poisoning und einem Denial-of-Service f\u00fchren. Welche Versionen von Next.js sind betroffen? Next.js 15.x\u00a0\u2013 …<\/p>\n","protected":false},"author":590,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[10515,10157],"tags":[11015,10347,11407,10348,10848],"class_list":["post-174413","post","type-post","status-publish","format-standard","hentry","category-community-de","category-sicherheit-und-devsecops","tag-cve-de","tag-cve-analysis-de","tag-next-js","tag-security-research-de","tag-vulnerabilities-de"],"yoast_head":"\n