When One Bug Isn't Enough: Finding a Full House of Vulnerabilities

4 min readJun 14, 2025

السلام عليكم ورحمة الله وبركاته

Hi everyone!

It’s been a while since my last writeup, This time, my target was a web application at https://sub.example.com. Initially, I was met with an "Authorized access only!" message, which, as any seasoned bug hunter knows, is merely an invitation to dig deeper.

1. Open Redirect

My initial reconnaissance involved some basic directory fuzzing. Using a standard dirsearch wordlist, I discovered an interesting directory: /api/app/. Intrigued, I continued fuzzing within this directory and hit a 200 OK response on /auth/. Navigating to this endpoint, I noticed a "Back" button with a suspicious-looking link:

https://sub.example.com/api/app/auth/unauthorize?returnUrl=https://sub.example.com

Clicking the “Back” button indeed redirected me to subs.example.com. On a hunch, I manipulated the returnUrl parameter to an external malicious site. To my surprise, the application seamlessly redirected me without any validation! This clear open redirect vulnerability was promptly reported and accepted by the program.

2. Information Disclosure: Internal User Details

Further exploration of the /api/app/ endpoint revealed another critical issue. The /api/app/user endpoint was accessible without any form of authentication. This allowed me to retrieve sensitive information about internal users, including their IDs, email addresses, names, and potentially other Personally Identifiable Information (PII) and system metadata.

3. Information Disclosure: Internal Application Configuration

Continuing my investigation of the /api/app/ endpoint, I discovered that /api/app/application returned a wealth of sensitive information in its JSON responses. This included internal user details, application configurations, and organizational data – all without requiring any authorization. This exposed critical internal workings of the application to unauthorized eyes.

4. Unrestricted File Upload

During my fuzzing efforts, I stumbled upon an /upload endpoint. Testing this endpoint, I quickly realized it lacked any authentication mechanisms, allowing anyone to upload arbitrary files.

To demonstrate the impact, I first used DeepSeek to generate the raw HTTP request for a simple image upload:

POST /api/app/upload HTTP/1.1
Host: subs.expmple.com
X-Application: ticketSystem
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Length: [CALCULATED_LENGTH]

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="587829.jpg"
Content-Type: image/jpeg

[Binary content of 587829.jpg]
------WebKitFormBoundary7MA4YWxkTrZu0gW--

I then crafted a malicious HTML file containing a simple XSS payload:

<script>alert(document.cookie)</script>

Using DeepSeek again, I obtained the raw HTTP request for uploading this malicious file:

POST /api/app/upload HTTP/1.1
Host: sub.example.com
Authorization: bearer [VALID_TOKEN]
X-Application: ticketSystem
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXYZ456

------WebKitFormBoundaryXYZ456
Content-Disposition: form-data; name="file"; filename="xss.html"
Content-Type: text/html

<script>alert(document.cookie)</script>
------WebKitFormBoundaryXYZ456--

Pasting this into Burp Repeater and sending the request resulted in a successful upload. The server provided a link to the uploaded file, confirming the unrestricted file upload vulnerability.

5. Information Disclosure: Internal Ticket Groups

Not content with the findings in /api/app/, I went back to the root /api/ and continued fuzzing. This led me to the /api/ticket/ endpoint. Fuzzing further within this revealed /api/ticket/group, an unauthenticated endpoint that exposed sensitive internal metadata. This included employee names, email addresses, associated groups/roles, internal entity/department names (in both English and Thai), and role permissions.

6. Information Disclosure: Sensitive Ticket Categories and Metadata

The /api/ticket/category endpoint also proved to be accessible without authentication. This allowed retrieval of detailed information about ticket categories, subcategories, and associated metadata, such as SLA details, retention periods, reviewer requirements, and field configurations.

7. Information Disclosure: Internal Business Information

Further exploration within /api/ticket/ uncovered the /api/ticket/Business endpoint. This endpoint lacked proper authorization checks, allowing unauthenticated users to retrieve sensitive business-related data.

8. Information Disclosure: Entity Information

Similarly, the /api/ticket/Entity endpoint was found to be accessible without any authorization. This allowed unauthenticated retrieval of sensitive entity-related data.

9. Local File Inclusion

After reporting the previous eight vulnerabilities, I decided to revisit the main application. Navigating to https://sub.example.com/ticket redirected me to https://sub.example.com/ticket/login. I then used Linkfinder to analyze the JavaScript files on this page. This revealed several of the API endpoints I had already identified, as well as a potentially interesting path: /download/file=.

My initial thought was a potential Local File Inclusion (LFI) vulnerability. I attempted to fuzz this endpoint using Seclists but didn’t find anything. Suspecting an issue with the endpoint itself, I provided a snippet of the relevant JavaScript code to DeepSeek and asked it to reconstruct the full endpoint. It suggested /api/ticket/download?file=.

Armed with this new endpoint, I went back to my testing and successfully managed to read the /etc/passwd file, confirming a critical Local File Inclusion vulnerability.

Key Takeaway

This experience reinforces a crucial principle in bug bounty hunting: never stop digging. Even when you encounter initial roadblocks like “Forbidden” messages, persistent fuzzing and a curious mindset can lead to the discovery of significant vulnerabilities. There’s no such thing as an absolutely secure website — you just need to be determined enough to find its weaknesses.

Thank you for reading. If you have any questions , feel free to ping me on X , or LinkedIn.