After discovering an unauthenticated endpoint leaking sensitive user data in the same application (see my previous writeup here), I had a feeling there was more waiting beneath the surface. The app was behaving oddly, and I was still navigating it through an anonymous session.

While browsing the profile settings page, I noticed the input fields were blank. This was probably because no real user was associated with the session. Still, I decided to fill them out and observe what happened behind the scenes.

When I submitted the form and captured the request, something in the structure caught my attention. It was subtle but interesting enough to take a closer look.

1. The PII leak that started it all

Earlier in this same application, I discovered an unauthenticated endpoint that exposed detailed user information. By manipulating a factoryId parameter, I was able to enumerate users across different tenants and retrieve sensitive fields like names, email addresses, phone numbers, and admin flags; all without authentication:

That vulnerability had already raised concerns, but the user data I found there ended up playing a key role in this second discovery.

2. Finding the entry point

After revisiting the data I had uncovered earlier, I decided to go back into the application and interact with as many features as I could. I clicked through every visible option, trying to understand what kind of functionality was available inside the anonymous session.

That’s when I found the profile settings page.

At first, the page looked empty. All of the input fields were blank, with no user data filled in. Still, I was curious. I filled in every field with dummy values and submitted the form while intercepting the request. What came through in Burp caught my attention.

3. Exploitation

After submitting the form and intercepting the request in Burp Suite, I took a closer look:

I replaced the default user ID in both the query parameter (id) and the request body (User.Id) with the ID of a real user I had previously identified during the PII enumeration.

I left everything else the same and changed only one field: the email address.

When I forwarded the request, the server responded with a 302 Found status and redirected me to /users/u001:

That path itself redirected again back to the blank profile settings page, just like before. Nothing in the UI indicated whether the update had worked.

4. Proving the vulnerability

After submitting the modified request, I wanted to confirm whether the change had any real impact beyond the user interface. Specifically, I was interested in seeing if the updated email address was being used by the application in account-related workflows.

I found a password reset feature on the login page and entered the new email address I had used during testing: [email protected]. Shortly after, I received a password reset email containing a working reset link.

This confirmed that the application had successfully updated the user’s email and was relying on that field for account recovery. In a real-world scenario, this would have allowed a malicious actor to take full control of another user’s account by triggering a password reset.

To avoid any disruption, I immediately used the same request format to revert the email address back to its original value. No further actions were taken.

This was enough to fully confirm the vulnerability and demonstrate its severity without causing any lasting impact.

5. Reporting

After verifying the impact and restoring the affected data, I submitted a detailed report to the program. I included full reproduction steps, the modified request, and the confirmation via the password reset flow.

The response was quick and professional. The issue was acknowledged, reproduced, and triaged shortly after submission.

The vulnerability was assessed as critical due to its potential to allow full account takeover without authentication.

It only takes one forgotten check to open the door completely.