Starting the new year with a solid bug bounty hunt is always the goal, and in early January 2026, I decided to focus my efforts on XYZ's infrastructure. After mapping the attack surface and digging deep into the application logic, I managed to chain together five Reflected Cross-Site Scripting (XSS) vulnerabilities, resulting in a 5000€ payout.
Here is a breakdown of my methodology and how I found each bug.
Bug 1: The Power of Google Dorks & WAF Evasion
I always like to start my reconnaissance by looking for non-standard endpoints. Instead of jumping straight into active scanning, I utilized Google Dorks to map out JavaScript resource files.
Using the dork site:xyz.com ext:jsq, I discovered an interesting endpoint: /bundle/resource/js/main.jsq=
I initially tested standard XSS payloads like < "> ;, but the application was either blocking them or neutralizing the input. However, I noticed that the Web Application Firewall (WAF) wasn't throwing a 403 Forbidden error when I utilized URL encoding.
Switching my approach, I utilized XSS0r and crafted a heavily URL-encoded payload that slipped right past the filters:
The Payload:
Plaintext
%22%3e%3c%69%6d%67%2f%73%72%63%2f%6f%6e%65%72%72%6f%72%3d.%31%7c%61%6c%65%72%74%60%31%60%20%63%6c%61%73%73%3d%64%3eDecoded:
"><img/src/onerror=.1|alert`1` class=d>The payload executed perfectly. Bug #1 secured.
Bug 2: Source Code Analysis & The Forgotten Parameter
For my next target, I expanded my scope to the subdomains and landed on scl.xyz.com. I started with standard UI testing, visiting each page and noting the parameters. On a registration page (register.aspx), the only visible parameter in the UI was ?email=.
Unsurprisingly, this input was well-secured.
Building web applications teaches you a lot about where developers might cut corners. Often, parameters that aren't actively used in the frontend UI are completely overlooked in the backend sanitization logic. Instead of moving on, I dug into the raw source code and discovered an unused parameter: ?mode=.
Since it was hidden from the standard user flow, I suspected it might lack proper validation. I injected a simple payload:
The Payload:
HTML
/register.aspx?mode=PasswordReset%27%22()%26%25%3Czzz%3E%3CScRiPt%20%3Ealert(1234)%3C/ScRiPt%3EThe application reflected the input directly into the DOM context without escaping the script tags, popping the alert box. Bug #2 secured.
Bugs 3, 4, and 5: Parameter Fuzzing and the "Shivangdon" Canary
For the remaining vulnerabilities, I relied heavily on automation and parameter discovery. While testing an authentication portal, I found the endpoint sessionLogin.xjsp. The only visible parameter was login={token}.
Instead of attacking the visible parameter, I decided to hunt for hidden ones. My methodology was simple:
- Fetch all parameters used anywhere on the website.
- Append them to the target endpoint.
- Inject a unique canary string (I used
shivangdon) as the value.
For example: sessionLogin.xjsp?{fuzzed_parameter}=shivangdon
I fired up Burp Suite Intruder, loaded my private wordlist of parameters into the payload position, and let it run. After some time sifting through the responses, my canary shivangdon appeared in the reflected HTML.
Once I knew which hidden parameter was reflecting input, I swapped the canary for an obfuscated XSS payload:
The Payload:
1%3CWOQGK3%3ETCXTG[!%2B!]%27%22%3C%00!—%00%3E%3C%00Img/Src/On%00Error=(conf%00irm)(1)%3E%3C/WOQGK3%3EThis exact parameter brute-forcing methodology proved incredibly highly effective. By repeating this process across multiple endpoints, I was able to uncover the 3rd, 4th, and 5th XSS vulnerabilities.
i have used my own wordlist created by me , lemmee know if needed.
ah this is my first writeup lemmee know any mistakes and suggestions.