ritinify/cve-2025-29927-pocProof-of-Concept-Exploit für CVE-2025-29927, eine Umgehung der Middleware-Autorisierung in Next.js. Enthält ein verwundbares Ziellabor und ein Python-Skript zur Überprüfung der Umgehung durch Senden manipulierter x-middleware-subrequest-Header.
Ein kleines GitHub-Projekt zur Verifizierung von CVE-2025-29927 (Next.js Middleware Authorization Bypass) in einer lokalen Übungsumgebung (VMware: Ubuntu-Zielmaschine + Kali-Angriffsmaschine).
⚠️ Haftungsausschluss: Dieses Projekt dient ausschließlich der Sicherheitsschulung, für CTFs und Übungsumgebungen, die du selbst besitzt oder für die du eine ausdrückliche Genehmigung hast. Die Verwendung gegen nicht autorisierte Systeme ist strengstens untersagt. Für jegliche Konsequenzen, die aus dem Missbrauch dieses Projekts entstehen, ist der Nutzer selbst verantwortlich.
| Element | Inhalt |
|---|---|
| CVE | CVE-2025-29927 |
| Veröffentlichungsdatum | 25.03.2025 (Offizielles Sicherheitsbulletin von Next.js) |
| Betroffene Komponente | Vercel Next.js (Node.js Full-Stack-Framework) |
| Schwachstellentyp | Autorisierungsumgehung / Improper Authorization (CWE-863) |
| Betroffene Versionen | < 12.3.5, < 13.5.9, < 14.2.25, < 15.2.3 |
| Behobene Versionen | 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3 und höher |
| Schweregrad | Critical / Hoch (genauer Wert siehe NVD-Seite) |
Nach dem Bekanntwerden der Schwachstelle wurden zahlreiche Admin-Backends, Zahlungs-Callbacks und interne APIs in Produktionsumgebungen umgangen. Sowohl Metasploit als auch ProjectDiscovery Nuclei haben Erkennungsmodule aufgenommen. Es handelt sich um eine der repräsentativsten Framework-Autorisierungsumgehungen des Jahres 2025.
Next.js erlaubt es, die Authentifizierungslogik in middleware zu schreiben, zum Beispiel:
export function middleware(request) {
if (!isLogin(request)) return NextResponse.redirect("/login"); // Nicht eingeloggt → blockieren
return NextResponse.next();
}
Das Problem: Next.js verlässt sich intern auf einen vom Client fälschbaren Request-Header, um zu bestimmen, ob „dieser Request die Middleware bereits durchlaufen hat":
x-middleware-subrequest: middleware
In den betroffenen Versionen geht Next.js davon aus, dass die Middleware bereits ausgeführt wurde, sobald eine externe Anfrage diesen internen Header enthält. Dadurch wird die gesamte Authentifizierungs-Middleware übersprungen. Ein Angreifer benötigt kein Konto und kann mit diesem Header direkt auf geschützte Routen wie /admin zugreifen und erhält eine 200-Antwort — während die Seite selbst der Middleware vertraut und keine erneute Prüfung durchführt. Die Autorisierungsprüfung wird damit wirkungslos (Fehler in der Vertrauensgrenze).
💡 Der in öffentlichen Exploits am häufigsten verwendete Wert ist eine wiederholte Aneinanderreihung des Middleware-Pfads, z. B.
middleware:middleware:middleware:middleware:middleware; ein einzelnesmiddlewarefunktioniert in manchen Versionen/Verzeichnisstrukturen nicht (in dieser Übungsumgebung mit 14.2.24 getestet). Dieses PoC probiert mehrere Kandidatenwerte durch; sobald einer greift, ist die Umgehung erfolgreich.
CVE-2025-29927-PoC/
├── README.md # Dieses Dokument (Schwachstellenbeschreibung + VMware-Übungsumgebungs-Tutorial)
├── LICENSE # MIT
├── .gitignore
├── exploit.py # ★ Python3-PoC mit reiner Standardbibliothek zur Verifizierung (läuft auf Kali/beliebiger Maschine)
├── target/ # ★ Selbstgebaute Schwachstellen-Übungsumgebung (auf Ubuntu-Zielmaschine kopieren)
│ ├── package.json # Sperrt [email protected] (betroffene Version)
│ ├── middleware.js # Simuliert die „Authentifizierungs-Middleware" einer echten Produktion
│ ├── pages/
│ │ ├── index.js # Startseite
│ │ ├── login.js # Login-Seite (demonstriert die Weiterleitung hierher)
│ │ └── admin.js # ★ Geschütztes Backend, liest serverseitig flag.txt
│ ├── flag.txt # Übungsumgebungs-Flag: FLAG{...}
│ ├── setup.sh # Ein-Klick-Setup auf der Zielmaschine: Node 20 + npm install + build
│ └── start.sh # Startet im Produktionsmodus und lauscht auf 0.0.0.0:3000
└── tests/
└── mock_target.py # Simulierte Zielmaschine ohne Node (nur für Entwicklungs-Selbsttests)
┌───────────────────────────────────────────────────────────┐
│ VMware Workstation Pro 17 (Host: Windows) │
│ Netzwerk: NAT (Standard VMnet8), beide VMs im selben │
│ Subnetz, gegenseitig pingbar │
│ │
│ ┌──────────────────┐ ┌─────────────────────┐ │
│ │ Ziel: Ubuntu 24.04│ │ Angreifer: Kali Linux│ │
│ │ │ http │ │ │
│ │ Node 20 + Next │◄───────│ python3 exploit.py │ │
│ │ 14.2.24 :3000 │ GET │ │ │
│ └──────────────────┘ └─────────────────────┘ │
│ IP: <TARGET_IP> IP: <ATTACKER_IP> │
└───────────────────────────────────────────────────────────┘
| Zweck | Image/Software | Empfohlene Version |
|---|---|---|
| Virtualisierungssoftware | VMware Workstation Pro 17 (für private Nutzung kostenlos) | 17.x |
| Zielmaschinen-Image | Ubuntu Server LTS ISO | 24.04.x |
| Angriffsmaschine | Kali Linux (offizielles VMware-Image oder ISO-Installation) | 2025.x |
| (Optional) | Host mit mind. 8 GB RAM, mind. 50 GB Festplatte | — |
Alle folgenden Schritte werden auf der Ubuntu-Zielmaschine ausgeführt.
# Option A: Projekt auf das eigene GitHub pushen und dann klonen (empfohlen; nutze dies, wenn du es auf GitHub veröffentlichen möchtest)
git clone https://github.com/<dein-benutzername>/CVE-2025-29927-PoC.git
cd CVE-2025-29927-PoC
# Option B: Vom Host per scp übertragen
# scp -r CVE-2025-29927-PoC ubuntu@<TARGET_IP>:~/
cd CVE-2025-29927-PoC/target
sudo bash setup.sh # Installiert Node 20(LTS) + npm install + next build