Post cover image
generative AI

September 4, 2026

From Auth Bypass to IDOR to Stored XSS: Completing the Attack Chain (PART 3)

In Part 1, I discovered how the “Forgot Password” feature could be used to bypass the admin verification process and grant access to an…

By Muhammad Rizqi Ramadhan

6 min read

In Part 1, I discovered how the "Forgot Password" feature could be used to bypass the admin verification process and grant access to an account that should have remained unverified. After successfully logging into the application, I continued my exploration, which led to a second discovery.

Critical Auth Bypass: How Forgot Password Feature Allowed Unverified Users to Access the Entire… In many modern applications, admin account verification is a crucial security layer to ensure only authorized users can…

In Part 2, I discovered an Insecure Direct Object Reference (IDOR) vulnerability in the Members feature. By manipulating the identifier in the endpoint, an attacker could access data belonging to other users that the account should not have been able to access.

From Auth Bypass to IDOR: Chaining Vulnerabilities to Access Other Users' Data (PART 2) In the previous write-up, I discussed how the "forgot password" feature could be exploited to bypass authentication…

However, it turned out there was still one part of the attack surface I hadn't explored. After gaining access to the application and understanding how user data was processed, I began exploring the "Edit User Profile" feature. That was where I discovered the third vulnerability: Stored Cross-Site Scripting (Stored XSS). What makes this finding interesting is that the Stored XSS did not stand alone. When combined with the two previous vulnerabilities, the three formed a far more serious attack chain:

Authentication Bypass → Unauthorized Access → IDOR → Stored XSS → Potential Account Takeover

And this time, even an attacker who hasn't logged in can initiate part of that chain.

Understanding the Stored XSS

Stored Cross-Site Scripting occurs when an application accepts user input, stores it on a server or in a database, and subsequently displays that input without adequate sanitization or output encoding. Unlike Reflected XSS, which requires a victim to open a specific URL or request, Stored XSS is persistent. The payload is stored by the application and executes when another user opens the page displaying that data. In this case, user input from several profile fields can be stored by the application and subsequently rendered on the Members page. To validate this, I used a simple XSS payload:

<img src=x onerror=alert(1)>
None

The payload is sufficient to demonstrate that the input successfully broke out of the ordinary data context and was executed as JavaScript by the browser.

Scenario 1 — Stored XSS Without Authentication

The most interesting aspect of this vulnerability is that an attacker does not need to log in first to inject the payload. I started at the web application's homepage and found a form that accepts user input. Instead of entering plain text, I entered an XSS payload:

<img src=x onerror=alert(1)>

Then, I submitted the form. At this stage, the application received the input and stored it. Since the input would be reused on the Members page, the payload did not disappear immediately after the request was completed; instead, it became part of the data stored within the application. When another user opened the Members page, the browser rendered the data, and the payload was subsequently executed. The result :

Attacker is not logged in → enters payload → payload is stored → another user opens Members → attacker's JavaScript is executed.

This is a key characteristic of Stored XSS. What makes it even more serious is the fact that an attacker does not need a verified account to inject the payload.

Scenario 2 — Stored XSS After Authentication

The second scenario unfolds after the attacker has successfully gained access to the application. This is where the vulnerability from Part 1 becomes relevant. In Part 1, we established that the admin verification process could be bypassed via the "Forgot Password" feature. This means an attacker who initially lacked dashboard access could obtain a session and enter the application without undergoing the required verification process. After logging in, I navigated to the "Edit User Profile" feature. I then modified fields such as "Name" using the same XSS payload:

<img src=x onerror=alert(1)>

After clicking Save, the payload is stored by the application. Then, when another user accesses the Members page, the profile data is displayed and the payload executes in the victim's browser. At this point, we have two different paths to Stored XSS:

Unauthenticated path

Public Form → Stored Payload → Members → XSS

Authenticated path

Auth Bypass → Dashboard → Edit Profile → Stored Payload → Members → XSS

Both paths ultimately lead to the same destination: the Members page.

From XSS to Account Takeover

An alert(1) merely proves that JavaScript was successfully executed. However, the impact of Stored XSS does not stop there.

Under certain conditions, JavaScript executed within the application's origin can be used to perform actions on behalf of the user currently viewing the page. One scenario that warrants attention is session theft or session abuse. For instance, an attacker might attempt to access session information available via JavaScript and transmit it to infrastructure under their control. Payloads of this type are frequently used to demonstrate the impact of XSS, although their success depends heavily on how the application manages sessions and whether cookies are protected by flags such as HttpOnly.

If the session is accessible via JavaScript, the consequences can be far more serious:

Victim opens Members → Stored XSS executes → session material potentially exposed → attacker impersonate victim

In a worst-case scenario, where the victim holds elevated privileges, such as an administrator. Stored XSS can escalate from mere client-side code execution into a vector for privilege escalation or account takeover. However, it is important to note that XSS does not automatically result in account takeover. The impact depends on factors such as session mechanisms, cookie security, CSRF protection, authorization, and the victim's privileges.

The Complete Attack Chain

After connecting the three findings, the picture of the attack chain becomes much clearer.

1. Authentication Bypass

The attacker creates a new account that remains unverified. Normally, the account is rejected upon login:

User → Login → Verification Check → Access Denied

Because the password reset flow does not implement the same verification status check, the application creates a session and grants access to the dashboard.

User → Forgot Password → Reset Password → Session Created → Dashboard

2. IDOR

After gaining access, the attacker explores the Members feature. The identifier in the endpoint can be manipulated, allowing the attacker to access another user's resources without proper authorization checks.

Authenticated User → Modify Identifier → Other User's Resource

This grants access to member data that should not be available to that user.

3. Stored XSS

Subsequently, the attacker discovered that certain inputs in the application could be stored without sanitization or secure output encoding. XSS payloads were injected via public forms or the "Edit Profile" feature.

Attacker Input → Server Storage → Members Page → Browser → JavaScript Execution

4. Potential Account Takeover

If Stored XSS is successfully executed in the victim's browser and the application's session mechanism allows session material to be accessed or sensitive actions to be performed via that browser, the impact can escalate to impersonation or account takeover especially if the victim holds elevated privileges.

The Bigger Picture

These three vulnerabilities highlight one important point: security controls must not be applied to only one part of an application. Authentication must verify who is permitted to enter. Authorization must determine what they are allowed to access. Input handling must ensure that user data is not transformed into executable code. In this case, each layer has a weakness:

Authentication Layer

→ Verification bypass via password reset

Authorization Layer

→ IDOR on Members

Input Security Layer

→ Stored XSS on user-generated content

If these vulnerabilities were discovered in isolation, each would already constitute a serious security issue. However, when the three can be chained together, the impact becomes far greater.

Conclusion

This Stored XSS finding marks the final stage of the exploration I conducted on the application. It began with a business logic flaw in the "Forgot Password" function, which allowed me to bypass the admin verification process. Once inside, I discovered an IDOR vulnerability that granted access to other users' resources. Further exploration of the profile feature then led me to a Stored XSS vulnerability, enabling an attacker to inject persistent JavaScript that executes whenever the "Members" page is loaded. The resulting attack chain looks like this:

Authentication Bypass ↓ Unauthorized Application Access ↓ IDOR / Unauthorized Data Access ↓ Stored XSS ↓ Potential Session Abuse / Account Takeover

This case serves as a reminder that application security is not merely about discovering and fixing a single vulnerability. Every layer authentication, authorization, input validation, session management, and access control must function consistently. The failure of a single security control can pave the way for the next vulnerability.

And sometimes, the most dangerous vulnerability isn't a single bug , it's how multiple bugs can be chained together.