One day, curiosity kicked in. I thought, let me poke around a bit. Didn't expect much, But within an hour, I had two XSS on the Same website.

Here's exactly how it happened.

First finding : Stored XSS in signature upload

The platform let users upload three types of signatures: Initials, Company Stamp, and Signature.

All three were on the same page :

https://www.target.com/user/signatures#stampTab

I've seen enough file upload bugs to know : SVG is dangerous.

Most developers block .html, .js, .htm. But SVG? It's an image format… that can contain JavaScript .

I created a simple SVG file :

<svg xmlns="http://www.w3.org/2000/svg">
  <script>alert('XSS in SVG')</script>
</svg>

Try to Upload it as a Company Stamp .

No error. No warning. The upload succeeded .

Finding the URL

The page didn't show the SVG directly. I had to dig :

• Burp Suite HTTP history → looked for stamp.svg

• Or page source → search for stamp.svg

The moment of truth !!

I opened that URL in a fresh browser ↪ The alert fired.

The embedded JavaScript executes, confirming a stored XSS vulnerability. 🔻✅.

A successful exploit could lead to session hijacking, account compromise, phishing attacks, or other client-side attacks affecting users who access the malicious SVG file..

I tested the same payload on Initials and Signature uploads. Both were vulnerable. Three endpoints, one bug .

Second finding : Reflected XSS in the contacts page

Still on the same target, I moved to the contacts section :

https://www.target.com/user/contacts

It looked harmless. A simple page with a contact form. But I noticed a hidden parameter ?page= I hadn't seen before ↓

By adding the ?page parameter The full URL become something like :

https://www.target.com/user/contacts?page=1

I changed 1 to testx. The word testx appeared in the response.

Reflection without encoding.so I used a classic :

"><svg onload="alert('xss-here')">

I loaded :

https://www.target.com/user/contacts?page="><svg%20onload=%27alert(%22xss-here%22)%27>

The alert popped immediately → Reflected XSS confirmed ← .

Together, they gave me two different ways to compromise users.

The stored one was more dangerous because it didn't require social engineering. Anyone who viewed the uploaded signature would be hit.

Why these happened ?

SVG upload — The developer only checked the file extension. Not the content. SVG is XML. XML can have <script>. No sanitization = stored XSS.

Reflected XSS — The page parameter value was printed directly into the HTML without encoding. Classic mistake. >, <, " were all accepted

Key takeaways for you (the hunter) :

1. Always test SVG uploads. Many bug hunters ignore file uploads because they think "only PHP matters". But SVG is everywhere — signatures, avatars, logos. Every SVG upload is a potential stored XSS.

2. Look at every parameter, even on "safe" pages. Contacts, about, help — these pages often have forgotten parameters like ?page=, ?section=, ?return=. Test them.

3. Stored > reflected for impact, but reflected is easier to find. Both count. Both pay. Don't skip reflected because it's "low impact" — chained with CSRF or open redirect, it becomes critical.

4. Use simple payloads first. "><svg onload=alert(1)> or <script>alert(1)</script> – if those work, you're done. Don't overcomplicate.

Final words

Two XSS on the same domain, found in under an hour. One was stored via a feature I used daily. One was reflected in a parameter I almost ignored.

The security team fixed both within a week.

Now it's your turn. Go test SVG uploads. Go fuzz those forgotten parameters.

And when you find them, write about it.