How This $999 XSS Bug Bounty Was Found in Just 17 Minutes

“Hey, check this out!” Mike messaged me at 3 AM. “I just found an XSS vulnerability that got me a quick bounty. Want to know how?”

Introduction

Cross-site scripting (XSS) remains one of the most prevalent web security vulnerabilities in 2025. Imagine giving an attacker the keys to your users’ sessions — that’s essentially what an XSS vulnerability does. It allows malicious actors to steal cookies, hijack credentials, and perform unauthorized actions on behalf of your users.

“The scariest part? Users won’t even know they’re being attacked,” Mike explained.

Turning a hidden input field into an XSS vulnerability — the exact payload that earned a $999 bug bounty

What is Stored in XSS?

Stored XSS is like planting a digital time bomb in a website’s database. Unlike its cousins (reflected and DOM-based XSS), stored XSS attacks are persistent. Think of it this way:

“It’s like leaving a malicious note in a library book — everyone who opens that book later will see your message,” Mike analogized.

The malicious script gets stored in the database and executes every time an unsuspecting user loads the affected page. This makes stored XSS particularly dangerous in applications with user-generated content.

Methodology: Finding Hidden Input Fields

When hunting for vulnerabilities, I always pay special attention to hidden input fields. These sneaky form elements come in two common flavors:

<!-- Method 1: Using type="hidden" -->
<input type="hidden" name="userID" value="123">

<!-- Method 2: Using CSS to hide -->
<div style="display:none">
    <input type="text" name="secretField" value="sensitive-data">
</div>

“Most developers assume hidden means secure,” Mike chuckled. “That’s exactly why I love testing them.”

Attempt 1: Using Autofocus

My first attempt involved the autofocus attribute — a technique I’d seen work before. The idea was simple:

<input type="hidden" autofocus onfocus="alert(document.cookie)">

But no luck. “Back to the drawing board,” I muttered, watching the clock tick past 3:10 AM.

Bypassing Restrictions: The Pattern Attribute

Then it hit me — the pattern attribute. Most developers use it for input validation, but I had a hunch it could be our ticket to success. Here’s the payload that struck gold:

<div style="display:none">
    <input type="text" 
           value="innocent-looking-value" 
           pattern="^[a-zA-Z]+$" 
           oninvalid="alert(document.cookie)">
</div>

“Bingo!” The alert popped up at exactly 3:17 AM. The combination of pattern and on invalid created the perfect storm — the input would always be invalid, triggering our payload.

Key Takeaways

After reporting the vulnerability and receiving the $999 bounty, here’s what we learned:

1. Never trust hidden fields — they’re hidden from view, not from attackers
2. The pattern attribute combined with event handlers can be a powerful weapon
3. “Always validate on both ends,” as Mike reminds us. “Client-side hiding is not security.”

Conclusion

Web security is an endless game of cat and mouse. This 17-minute discovery proves that sometimes the simplest techniques yield the best results. Have you found interesting XSS vectors in hidden fields? Share your experiences in the comments below!

“Remember,” Mike said as we wrapped up our late-night hacking session, “the best vulnerabilities are often hiding in plain sight.”