Hi everyone! I recently received an invitation to a private VDP program and decided to take a quick look. There were a few wildcard domains listed. As a first step, I gathered all the subdomains related to those wildcards. Then, I identified which ones were live and filtered them based on their status codes, creating a clean and organized list.

1 — HTML Injection in Email via Name Field

I started by quickly checking the domains that returned a 200 OK status. One of the domains had a "sign up" option. I noticed that the "name" parameter in the registration form reflected HTML input inside an email sent later to the user. I reported this finding, but unfortunately, it was marked as a duplicate.

2 — Bypassing Email Verification via Response Manipulation

While testing the registration process, I noticed that the system required a 6-digit verification code. I entered a random code like "000000" and intercepted the request using Burp Suite. Then, I manipulated the server's response by changing "status": "false" to "status": "true", which allowed me to successfully complete the registration.

I didn't report this right away and kept exploring the application. When I clicked on "Forgot Password", the system again sent a 6-digit verification code. I tried the same response manipulation technique here, and once again, I was able to bypass the verification. However, since the system also asked for an additional piece of information along with the email, the impact wasn't classified as critical, but was still marked as high.

3 — Publicly Accessible API Log File Exposing API Keys and Full PII of Leads

I spent some more time exploring the domain, but couldn't find anything noteworthy at first. However, one domain that returned a 404 status caught my attention. When I visited it, it simply showed a blank page. I ran dirsearch using default settings without any custom wordlist and discovered a path named /api.log.

When I visited the path, the page was loading extremely slowly — after waiting for several minutes, it still hadn't fully loaded and eventually crashed with a "page unresponsive" error. After waiting for about a minute, I manually stopped the loading. In the partially loaded content, I discovered sensitive information of millions of users, including full names, email addresses, phone numbers, physical addresses, and API keys. Shortly after I reported it, the issue was triaged and quickly fixed by the team.

4 — Reflected XSS, Stored XSS, Post-Based XSS Before Diving Into SQL Injection

After reporting the previous finding, I took a short break and then resumed scanning the remaining domains. Interestingly, I discovered all the remaining vulnerabilities within a single domain — including multiple Reflected XSS, Stored XSS, Post-Based XSS, and two Blind SQL Injection vulnerabilities.

I started by manually browsing the site and performing some basic directory enumeration, but didn't get any meaningful results. I ran arjun on the homepage and discovered a few parameters that were vulnerable to XSS—two Reflected XSS issues were identified and noted.

Next, I went through each page from the navbar and analyzed them one by one. There were three different login forms across the site. I ran arjun on these pages as well and found vulnerabilities in both GET and POST requests.(username,password,errormsg,code parameters …)

Additionally, there was a ticket submission form in the application. After submitting a ticket, the system would return a ticket ID via the code parameter (e.g., tst.com/?code=123xa21). When I visited this page, I could see all the data I had submitted in the form. First, I noticed that the code parameter itself was vulnerable to Reflected XSS.

Then I injected XSS payloads into fields like username and address while creating the ticket. When the ticket was later viewed via the code URL, the payloads executed successfully, confirming a Stored XSS vulnerability. Blind XSS attempts were unsuccessful, but Stored XSS was triggered reliably. I reported these findings as well.

5 — Wrapping Up with a Time-Based Blind SQL Injection

After reporting the XSS vulnerabilities on the three different login pages, I tried SQL Injection payloads in various parameters and headers — but didn't find anything conclusive. I then focused on the /auth endpoint and used a wordlist to fuzz paths like /auth/FUZZ. That's when I discovered the /auth/admin directory.

In this endpoint, I once again found XSS vulnerabilities in the username, password, and errormsg parameters—similar to the previous ones—and reported them. Next, I started testing for SQL Injection. I injected the following payload into the username field: 'XOR(if(now()=sysdate(),sleep(6),0))XOR' The response took about 13.8 seconds, which caught my attention. To rule out false positives, I tried alternative payloads and noticed consistent response delays—approximately 2x longer than usual.

When I reported it, the team asked for more technical details. Tools like sqlmap and gahuri didn't work at first, so I began customizing the payloads manually—with the help of ChatGPT. The final payload worked, especially since the application sometimes returned inconsistent responses, making manual testing essential. I submitted the refined report, and the team quickly patched the issue.

And with that, I submitted the final finding for this program. To be honest, since it was a VDP program, I wasn't planning to dig too deep. But because I genuinely enjoy hunting and had a lot of fun along the way, I decided to dedicate more time to it.

Ultimately, despite this being a VDP, my curiosity and passion for the craft drove me to invest significant time into this target. Beyond just finding bugs, the real reward was identifying impactful vulnerabilities that fundamentally strengthened the platform's security posture. For me, bug bounty is as much about the thrill of the hunt as it is about making the digital world a safer place

Stay Connected

• X (Twitter): @xelcezeri
• LinkedIn: Samet Yiğit