In bug bounty hunting, not every vulnerability needs flashy payloads or JavaScript execution to matter. Sometimes, the simplest flaws — when placed in the right context — can quietly undermine user trust.

In this write-up, I’ll walk through how I discovered a Reflected HTML Injection vulnerability on an authentication endpoint, why it matters, and how it was responsibly disclosed and resolved.

Your regular self-taught Ethical Hacker kjulius 🪞🗿

This finding was discovered together with @Younghb0x1.

🎯 Target Overview

The target was an authentication-related endpoint:
For responsible disclosure, let’s call the website as “target”.

https://target-auth.domain.com/data/public/farewell?client_id=

At first glance, it looked like a standard logout/farewell page in an SSO flow. But as always, user-controlled parameters are worth testing — especially in auth flows.

🔍 Initial Discovery

While testing the application, I noticed that the client_id parameter was reflected in the response.

So I tried something simple:

<h1>Hello World</h1>
<p>Testing HTML Injection</p>

After URL encoding and sending the request, the response page rendered my HTML directly.

That’s when it became clear:

The application was reflecting user input without proper output encoding.

⚠️ The Vulnerability

Reflected HTML Injection

The endpoint was vulnerable because it:

• Took user input from client_id
• Injected it directly into the HTML response.
• Did not sanitize or encode the output.

This allowed arbitrary HTML to be rendered in the browser.

🧪 Proof of Concept.

A crafted payload like this:

Was successfully rendered on the page when passed through the URL:

https://target-auth.domain.com/data/public/farewell?client_id=...

Result:

• Headings displayed ✔
• Paragraph rendered ✔
• Clickable link injected ✔

No JavaScript execution occurred — but that doesn’t mean it’s harmless.

❌ Why This Is NOT XSS

I tested multiple XSS payloads, including:

• "><script>alert(1)</script>
• <img src=x onerror=alert(1)>
• <svg onload=alert(1)>

All were blocked or sanitized.

So this was clearly:

✅ HTML Injection
❌ Not Cross-Site Scripting (XSS)

💥 Impact: Why This Still Matters

Even without JavaScript, this vulnerability sits on a trusted authentication endpoint — and that changes everything.

👤 Impact to Users.

• Users may see attacker-controlled content on a trusted page.
• Fake messages can be displayed (e.g., logout success, warnings).
• Malicious links can be injected and clicked.
• Increased risk of phishing and social engineering.

🏢 Impact to the Company.

• Abuse of a trusted authentication domain.
• Potential phishing campaigns leveraging legitimacy.
• Brand reputation damage.
• Indicator of weak input handling in sensitive areas.

🧠 Key Insight

This bug is a perfect example of something many beginners overlook:

“No XSS” does NOT mean “No impact.”

Context matters.

If this were on a random static page, it might be ignored.
But on an SSO/logout endpoint, users inherently trust what they see.

That trust is exactly what attackers exploit.

🛠️ Remediation

The fix is straightforward but critical:

• Properly encode all user input before rendering.
• Apply strict allow-list validation for client_id
• Avoid reflecting authentication parameters in HTML.
• Implement a Content Security Policy (CSP).

✅ Final Outcome

The vulnerability was:

• Reported responsibly.
• Accepted by the program.
• Resolved.

🤝 Collaboration

This finding was made together with @Younghb0x1 — shoutout for the teamwork and sharp testing mindset.

🧾 Final Thoughts

This was a reminder that:

• Simplicity wins.
• Context defines impact.
• And clean, well-documented reports get accepted.

Not every bug needs to be “critical” to be valuable.

Sometimes, all it takes is:

A <h1> tag in the right place.