Reflected XSS on a Global Gaming Platform: A Detailed Case Study

Disclaimer

This article is strictly educational.
All technical actions described were performed by a security researcher within an authorized context following responsible disclosure.
Nothing here should be used for malicious activity.

Introduction

There are hundreds of ways a web application can go wrong, but some issues are so fundamental that they consistently appear in mature platforms. Reflected Cross-Site Scripting (XSS) is one of them. Even todaydecades after XSS was documentedmajor companies occasionally ship code paths that allow unsanitized user input to slip into HTML responses.

This case study examines a real-world reflected XSS vulnerability discovered on PUBG's official website, reported responsibly by a security researcher. While the core bug was simplejust a URL parameter reflected without escapingthe implications were not.

A single bug, triggered by a single link, could have allowed:

• Execution of arbitrary JavaScript in a victim’s browser
• Unauthorized interactions with PUBG accounts
• UI manipulation for phishing
• Session-related attacks, depending on cookie configurations

This blog breaks down the researcher’s findings in a story-like, highly educational walkthrough. We’ll look at what the bug was, why it mattered, how it could be tested safely, and what engineering teams should learn from it.

Understanding the Target and the Context

PUBG is a globally recognized gaming franchise with millions of monthly active users. Their public-facing site, pubg.com, contains content such as:

• Promotional pages
• Player information
• Community announcements
• Account login modules
• Regional content variations

Modern web platforms often depend on dynamic parameters to:

• Load localized content
• Filter news items
• Display sections conditionally
• Support analytics and tracking

This dynamic nature means user-controlled parameters frequently flow into templating logic. If any of these flows are not protected by output encoding, you have the recipe for reflected XSS.

That is precisely what happened here.

Step 1 - The Researcher Notices a Suspicious Parameter

The researcher began by intercepting a request to a content page that included a parameter such as:

https://www.pubg.com/?p=123

At first glance, the parameter seemed harmlesslikely referencing an internal category or content ID.

But a deeper look in an interception proxy revealed that the value of this parameter was being injected directly into the HTML without escaping.

A critical rule in application security:

Whenever a parameter’s value appears raw inside an HTML context, JavaScript context, or attribute context, treat it as a potential XSS sink.

The researcher decided to test how the webpage handled unexpected characters.

Step 2 - Intercepting the Response

Using Burp Suite, the researcher modified the parameter to include characters that would normally require escaping.

The request in the proxy looked like this (simplified):

GET /?p=<injected-value> HTTP/1.1
Host: www.pubg.com
Accept: text/html

In the server’s HTML response, the injected content appeared untouched.

This is the moment where a security researcher’s intuition activates:
If the server reflects input without encoding it, the page is potentially vulnerable.

The next step was not to run malicious scriptsbut simply to observe whether the input landed inside a scriptable HTML context.

Step 3 - Safe Proof-of-Concept (PoC)

The researcher crafted a harmless version of a test payload to check whether the browser would execute it once rendered.

In the controlled test environment, the webpage rendered the researcher’s test string and executed the simple JavaScript action associated with it.

This confirmed the presence of a reflected XSS vulnerability.

A screenshot captured the raw request/response showing the vulnerable reflection.

Step 4 - Browser Execution Proof (Non-Harmful)

After confirming the reflection, the researcher loaded the URL in the browser.

The injected scriptlimited to a harmless markerexecuted in the PUBG.com origin.

This second screenshot confirmed that:

• The browser interpreted the parameter output as active JavaScript, and
• The vulnerability reproduced consistently across sessions.

Why This Matters: Beyond an Alert Box

Many beginners think of reflected XSS as “just popping an alert box,” but in reality, it is one of the most dangerous attack primitives when chained with modern web architecture.

1. Attackers need only a single click

Reflected XSS allows delivery through:

• Social media
• Discord
• Email
• Gaming forums
• Phishing pages

No persistence needed only one visit to a crafted URL.

2. Browser trust belongs to the website

If the victim loads:

https://www.pubg.com/?p=<malicious>

…the JavaScript runs as pubg.com, with its privileges.

3. Account manipulation becomes possible

Depending on PUBG’s session implementation, injected scripts could:

• Perform actions as the victim
• Manipulate UI flows
• Access non-HttpOnly cookies (if any existed)

4. UI manipulation & phishing

Injected JavaScript can:

• Replace login forms
• Modify purchase dialogs
• Display fake account messages

5. XSS as a stepping-stone to deeper attacks

Potential chains include:

• CSRF amplification
• DOM poisoning
• Open redirect exploitation
• Attacks against admin interfaces (if reachable)

Even if PUBG hardened many layers, reflected XSS always poses a severe risk.

Safe Testing Practices

Do:

• Use only harmless proofs like basic markers
• Test only with your own accounts
• Record metadata-only differences
• Redact sensitive data in reports

Don’t:

• Attempt data exfiltration
• Mass scan or brute force
• Publish active exploit payloads
• Test on real user sessions

This is why the researcher’s approach was responsible and accepted.

Root Cause Analysis

The vulnerability stemmed from PUBG’s server-side rendering logic.

What exactly went wrong?

1. The site accepted a GET parameter p.
2. Inserted it directly inside an HTML template.
3. Did not escape characters like <, >, ', ".
4. Browser interpreted the value as executable JavaScript.

The technical mistake

User input should never be injected into:

• HTML
• JavaScript blocks
• Event handlers
• Attributes

…without context-specific escaping.

This endpoint likely:

• Used legacy rendering
• Bypassed standard sanitization
• Was overlooked during reviews

Preventing This Vulnerability

1. Output Encoding (Primary Fix)

Escape all user-supplied values before rendering.

< > & " '

2. Framework Escapers

Most frameworks have built-in protections when used correctly.

3. Content Security Policy (CSP)

CSP significantly reduces XSS impact.

4. Cookie Hardening

Use:

• HttpOnly
• SameSite=strict
• Secure

5. Audit Legacy Templates

Older pages often bypass newer sanitizers.

6. Static Analysis & CI Enforcement

Automated tools detect unescaped outputs early.

Lessons for Bug Hunters

• Reflected XSS is still valuable when impact is explained clearly.
• Legacy endpoints are gold mines.
• Reports must be clean, safe, and easy for triage to reproduce.
• Screenshots dramatically improve clarity.

Lessons for Engineering Teams

• Treat all user input as untrusted.
• Apply context-aware escaping universally.
• Implement CSP for mitigation-in-depth.
• Periodically review old templating systems.
• Use modern frameworks consistently.

Final Thoughts

Reflected XSS has existed for over two decades, yet major companies still hit this vulnerability because it takes only one unescaped parameter to reintroduce the risk.

The PUBG case shows that even globally scaled platforms must continuously audit templates, review rendering logic, and maintain layered defenses.

One unescaped parameter.
One user click.
One script running in the wrong context.

That is all it takes.