![\"CVE-2025-29927](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/23164146\/Next.js_CVE-2025-29927_863x300.png\")
<\/p>\nCVE-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<\/a>\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.<\/p>\n Next.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.<\/p>\n Damit die Schwachstelle \u00fcberhaupt ausgenutzt werden kann, muss der betroffene Next.js-Server eine Next.js-Middleware verwenden. Dies umfasst das Einbinden einer Datei Dies 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<\/em><\/p>\n Autorisierungs-Middleware-Szenario ohne Ausnutzung von CVE-2025-29927<\/em><\/p>\n Next.js-Middleware kann auch bei der Lokalisierung von Websites helfen. Beispielsweise kann die Middleware Nutzer basierend auf ihrem Standort automatisch weiterleiten, indem sie etwa Wenn die Website ein\u00a0CDN oder eine andere Caching-Schicht<\/strong> verwendet, k\u00f6nnen diese Fehlerantworten gespeichert und zuk\u00fcnftigen Besuchern bereitgestellt werden. Sobald sie zwischengespeichert sind, sehen legitime Nutzer m\u00f6glicherweise weltweit<\/strong> 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<\/em><\/p>\n \u00a0<\/p>\n Redirector-Middleware-Szenario mit Ausnutzung von CVE-2025-29927<\/em><\/p>\n \u00a0<\/p>\n Next.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 Eine typische Next.js-Middleware-Implementierung, die eine Authentifizierung durchf\u00fchrt, k\u00f6nnte wie folgt aussehen:<\/p>\n CVE-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 Um diese Schwachstelle auszunutzen, muss ein Angreifer beim Zugriff auf gesch\u00fctzte Ressourcen lediglich den Header Der anf\u00e4llige Code<\/a> in der neuesten anf\u00e4lligen Version (v15.2.2) lautet wie folgt:<\/p>\n Der Header Wie bereits erl\u00e4utert, lautet der Name des anf\u00e4lligen Headers\u00a0 Vor Version 12.2 hie\u00df die Middleware-Datei tats\u00e4chlich Wenn wir beispielsweise mit unserem PoC-Code eine Next.js-Version vor 12.2 verwendet h\u00e4tten, h\u00e4tten wir Seit Version 12.2 und bis Version 13 muss die Middleware-Datei im Stammverzeichnis des Projekts vorhanden sein und muss 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 Ab Version 13 von Next.js wurde die zuvor beschriebene Rekursionspr\u00fcfung implementiert \u2013 das bedeutet, dass ein Angreifer den b\u00f6sartigen Header auf Da unser PoC auf dieser Version l\u00e4uft, ist dies ein Ausschnitt aus der von uns verwendeten Anfrage:<\/p>\n Wichtig ist, dass sich der Middleware-Code in allen Phasen in einem Wie 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 Zun\u00e4chst unsere Anmeldeseite:<\/p>\n Der beste Weg, CVE-2025-29927 zu beheben, ist ein Upgrade Ihrer Next.js-Version auf eine der behobenen Versionen\u00a0\u2013<\/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.<\/p>\n Wenn 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 Bearbeiten Sie in NGINX Ihre Datei Beispiel:<\/p>\n F\u00fcgen Sie in Express.js die folgende Direktive zu Ihrem JavaScript-Quellcode hinzu\u00a0\u2013<\/p>\n Wenn 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 Wie immer kann JFrog Security Essentials (Xray)<\/a> 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<\/a> um einen Contextual Analysis<\/a> 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>\nWelche Versionen von Next.js sind betroffen?<\/h2>\n
Angriffsszenarien f\u00fcr CVE-2025-29927<\/h2>\n
middleware.js<\/code> oder middleware.ts<\/code> ( _middleware.js<\/code> oder _middleware.ts<\/code>\u00a0 f\u00fcr \u00e4ltere Versionen von Next.js). Diese Datei definiert und exportiert die Funktion middleware<\/code>, die die Logik enth\u00e4lt, die bei jeder eingehenden HTTP-Anfrage ausgef\u00fchrt wird.<\/p>\nUmgehung der Autorisierung<\/h3>\n
![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/24115029\/auth_nobypass.png\")
<\/p>\n![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/24115144\/auth_bypass.png\")
<\/p>\nDenial of Service durch Cache Poisoning<\/h3>\n
\/en<\/code> f\u00fcr englischsprachige oder \/fr<\/code> 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 (\/<\/code>), 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![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/24115148\/dos_nobypass.png\")
<\/p>\n![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/24115146\/dos_bypass.png\")
<\/p>\nNext.js-Middleware verstehen<\/h2>\n
\n
\r\n\r\n import { NextResponse } from 'next\/server'\r\n import type { NextRequest } from 'next\/server'\r\n\r\n export function middleware(request: NextRequest) {\r\n \/\/ Token des Benutzers aus den Cookies abrufen\r\n const token = request.cookies.get('token').value\r\n \r\n \/\/ Pr\u00fcfen, ob der Benutzer authentifiziert ist\r\n const isAuthenticated = validateToken(token)\r\n \r\n \/\/ Wenn nicht authentifiziert, zur Anmeldung weiterleiten\r\n if (!isAuthenticated) {\r\n return NextResponse.redirect(new URL('\/login', request.url))\r\n }\r\n \r\n \/\/ Bei erfolgreicher Authentifizierung mit der gesch\u00fctzten Route fortfahren\r\n return NextResponse.next()\r\n }\r\n\r\n \/\/ Konfigurieren, welche Routen diese Middleware verwenden\r\n export const config = {\r\n matcher: ['\/dashboard\/:path*', '\/settings\/:path*'],\r\n }\r\n\u00a0\r\n<\/code><\/pre>\nTechnische Analyse von CVE-2025-29927<\/h2>\n
x-middleware-subrequest<\/code>-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>\nx-middleware-subrequest<\/code> zu seinen HTTP-Anfragen hinzuf\u00fcgen. Beispielsweise wird eine Anfrage an \/api\/admin\/users<\/code>, 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\r\n export const run = withTaggedErrors(async function runWithTaggedErrors(params) {\r\n const runtime = await getRuntimeContext(params)\r\n const subreq = params.request.headers[`x-middleware-subrequest`] [1]\r\n const subrequests = typeof subreq === 'string' ? subreq.split(':') : [] [2]\r\n\r\n const MAX_RECURSION_DEPTH = 5\r\n const depth = subrequests.reduce( [3]\r\n (acc, curr) => (curr === params.name ? acc + 1 : acc),\r\n 0\r\n )\r\n\r\n if (depth >= MAX_RECURSION_DEPTH) { [4]\r\n return {\r\n waitUntil: Promise.resolve(),\r\n response: new runtime.context.Response(null, {\r\n headers: {\r\n 'x-middleware-next': '1',\r\n },\r\n }),\r\n }\r\n }\r\n\u00a0\r\n<\/code><\/pre>\nx-middleware-subrequest<\/code> wird in [1] aus der Anfrage \u00fcbernommen.
\nAnschlie\u00dfend wird er mithilfe des Trennzeichens :<\/code> in [2] aufgeteilt und durch eine Reduce-Funktion gef\u00fchrt, die z\u00e4hlt, wie viele Elemente in diesem Array (subrequests<\/code>) in [3] mit dem Dateinamen der Middleware \u00fcbereinstimmen.
\nWenn diese Zahl in [4] gleich oder gr\u00f6\u00dfer als MAX_RECURSION_DEPTH<\/code> (also 5<\/code>) ist, umgeht sie die Funktionalit\u00e4t der Middleware und leitet sie an ihre Route weiter.<\/p>\nM\u00f6gliche Werte f\u00fcr Attack-Header<\/h2>\n
\nx-middleware-subrequest<\/code>. Der ihm zugewiesene Wert h\u00e4ngt von Next.js ab, da er entsprechend dem Wert von middlewareInfo.name<\/code> festgelegt wird, der im Wesentlichen dem Pfad zur Datei middleware.js<\/code> oder middleware.ts<\/code> entspricht.<\/p>\n_middleware.js<\/code>\/_middleware.ts<\/code> und konnte sich auf jeder Ebene des Unterverzeichnisses befinden, auf das man zugreifen m\u00f6chte. In diesem Fall versuchen wir, auf \/admin\/dashboard<\/code> zuzugreifen, was bedeutet, dass middlewareInfo.name<\/code> pages\/_middleware<\/code>\u00a0oder\u00a0pages\/admin\/_middleware<\/code> h\u00e4tte sein k\u00f6nnen. H\u00e4tten wir\u00a0dashboard<\/code>\u00a0als Verzeichnis mit einer\u00a0index.js<\/code>-Datei\u00a0festgelegt,h\u00e4tte es auch\u00a0pages\/admin\/dashboard\/_middleware<\/code> sein k\u00f6nnen.<\/p>\nmiddleware.js<\/code>\u00a0in das Verzeichnis pages<\/code>\u00a0verschieben und in _middleware.js<\/code> umbenennen m\u00fcssen, und unsere \u201eb\u00f6sartige\u201c HTTP-Anfrage w\u00fcrde lauten:<\/p>\n\r\n GET \/admin\/dashboard HTTP\/1.1\r\n x-middleware-subrequest: pages\/_middleware\r\n\u00a0\r\n<\/code><\/pre>\nmiddleware.js\/middleware.ts<\/code> hei\u00dfen. Um diese Versionen von Next.js anzugreifen, w\u00fcrde die Payload f\u00fcr den Header also einfach middleware<\/code> lauten\u00a0\u2013 und wir wissen mit Sicherheit, dass sie sich im Stammverzeichnis befindet.<\/p>\n\r\n GET \/admin\/dashboard HTTP\/1.1\r\n x-middleware-subrequest: middleware\r\n\u00a0\r\n<\/code><\/pre>\nmiddleware:middleware:middleware:middleware:middleware<\/code> setzen m\u00fcsste, um 5 Rekursionsebenen zu simulieren.<\/p>\n\r\n GET \/admin\/dashboard HTTP\/1.1\r\n x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware\r\n\u00a0\r\n<\/code><\/pre>\nsrc<\/code>\u00a0-Verzeichnis h\u00e4tte befinden k\u00f6nnen \u2013 was bedeuten w\u00fcrde, dass zum Ausnutzen src<\/code> den oben dargestellten Werten vorangestellt werden m\u00fcsste. Wenn wir unseren PoC-Code beispielsweise in einem src<\/code>\u00a0-Verzeichnis abgelegt h\u00e4tten, h\u00e4tte unsere Payload wie folgt aussehen m\u00fcssen:<\/p>\n\r\n GET \/admin\/dashboard HTTP\/1.1\r\n x-middleware-subrequest: src\/middleware:src\/middleware:src\/middleware:src\/middleware:src\/middleware.\r\n\u00a0\r\n<\/code><\/pre>\nAusnutzung von CVE-2025-29927<\/h2>\n
\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![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/24120746\/image-4.png\")
<\/p>\n\n\n\n\n\nFolgendes passiert, wenn ein Benutzer ohne Administratorrechte versucht, sich anzumelden:<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/24120823\/image-5.png\")
<\/p>\n\n\n\n\n\nUnd dies ist das Admin-Dashboard unter\u00a0\/admin\/dashboard<\/code> mit den richtigen Anmeldedaten:<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/24120835\/image-6.png\")
<\/p>\n\n\n\n\n\nKommen wir zum Exploit\u00a0\u2013 versuchen wir zun\u00e4chst, eine GET-Anfrage an\u00a0\/admin\/dashboard<\/code> ohne den sch\u00e4dlichen Header zu senden:<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/24120901\/image-7.png\")
<\/p>\n\n\n\n\n\nWir erhalten eine \u201e401 Unauthorized\u201c-Antwort, da unsere Middleware aktiv wird und erkennt, dass es sich nicht um ein Admin-Konto handelt:<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/24120909\/image-8.png\")
<\/p>\n\n\n\n\n\nVersuchen wir jedoch dasselbe noch einmal mit dem Header\u00a0x-middleware-subrequest<\/code><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/24120918\/image-9.png\")
<\/p>\n\n\n\n\n\nund wir erhalten eine 200-OK-Antwort!<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/24120925\/image-10.png\")
<\/p>\n\n\n\n\n\nMithilfe der Webvorschau k\u00f6nnen wir au\u00dferdem sehen, dass wir das Dokument bereits zuvor erhalten haben:<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/24120950\/image-12.png\")
<\/p>\nBehebung von CVE-2025-29927<\/h2>\n
Versions-Upgrade<\/h3>\n
\n
Blockieren des anf\u00e4lligen Headers im Webserver<\/h3>\n
.htaccess<\/code>-Datei hinzu (mod_headers<\/code> muss installiert und aktiviert sein)\u00a0\u2013<\/p>\n <IfModule mod_headers.c>\r\n RequestHeader unset x-middleware-subrequest\r\n <\/IfModule><\/pre>\n
nginx.conf<\/code> und f\u00fcgen Sie Ihrem Serverblock die folgende proxy_set_header<\/code>-Direktive hinzu\u00a0\u2013<\/p>\n\u00a0proxy_set_header x-middleware-subrequest "";<\/code><\/p>\n server {\r\n\u00a0 listen 80;\r\n\u00a0 server_name your_domain.com;\r\n\u00a0 location \/ {\r\n\u00a0 \u00a0 proxy_set_header x-middleware-subrequest "";\r\n\u00a0 }\r\n }<\/pre>\n \/\/ Middleware zum Entfernen des Headers x-middleware-subrequest\r\n app.use((req, res, next) => {\r\n delete req.headers['x-middleware-subrequest'];\r\n next();\r\n });<\/pre>\nBlockieren des anf\u00e4lligen Headers mit einer WAF<\/h3>\n
x-middleware-subrequest`<\/code> enthalten.<\/p>\nBehebung von CVE-2025-29927 mit JFrog Xray und JFrog Advanced Security<\/h3>\n
![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2025\/03\/24162310\/image-13-e1742826359138.png\")
<\/a>