July 27, 2026

How I Turned an “Informative” HTML Injection into My First Paid Bounty

TL;DR: HTML Injection is often marked as Informative or N/A by triagers. However, by demonstrating how a hidden CSS overlay bypassed the…

By Muhammadmaftuhk

1 min read

TL;DR:_ HTML Injection is often marked as_ Informative or N/A by triagers. However, by demonstrating how a hidden CSS overlay bypassed the platform's external link warning page, I successfully escalated the issue to a paid P4 vulnerability.

1. Introduction

HTML Injection (HTMLi) is frequently dismissed in modern bug bounty programs as a low-impact or Informative finding. Many researchers stop testing the moment they achieve basic tag injection.

In this write-up, I want to share how understanding the application's intended security behavior allowed me to escalate a simple HTMLi into an invisible click-hijacking vulnerability and earn my first bounty.

2. Context & Security Control

While testing a chat feature on the target platform, I noticed how the application handles external links:

  • Intended Behavior: When a user clicks a legitimate third-party URL in the chat, the platform redirects them to a Warning/Interstitials Page alerting them that they are leaving the main site.
  • The Goal: Find a way to bypass this warning prompt and force immediate redirection to an attacker-controlled site.

3. The Discovery & Payload

The chat feature failed to properly sanitize HTML input, allowing arbitrary tags and inline CSS styles.

Instead of injecting standard text or visible links, I crafted a payload using a full-screen CSS overlay:

HTML

<a href="https://attacker.com"
   style="position:fixed; top:0; left:0; width:100vw; height:100vh; z-index:999999; opacity:0; cursor:default;">
</a>

How the Attack Works:

  • The injected <a> tag creates a completely transparent layer (opacity:0) covering the entire viewport (100vw / 100vh).
  • The high z-index ensures it sits above all other UI elements.
  • When the victim clicks anywhere inside the chat interface, they unknowingly click the invisible link, triggering an immediate redirect to attacker.com—completely bypassing the platform's external link warning page.

4. Overcoming the "Informative" Status

When I first submitted the report, the triager initially marked it as Informative, treating it as a non-impactful HTML injection.

Instead of accepting the decision, I provided a clear impact demonstration:

  • I re-explained that this wasn't just text formatting, but a functional bypass of their security mechanism (the external link warning page).
  • I showed how an attacker could combine this with phishing campaigns to seamlessly redirect users without triggering safety prompts.

After reviewing the escalated impact, the team accepted the findings and upgraded the severity to P4 (Valid), resulting in my first bounty payout! 🎉

5. Key Takeaways

  • Impact Over Severity Labels: A bug is only as "low impact" as your PoC makes it seem. Always look for ways to break existing security controls.
  • Understand the Application: Pay attention to how features should work (like warning prompts or tokens). Bypassing those features is where the real value lies.
  • Clear Communication: If a report gets closed as Informative, politely clarify the actual business risk with a solid PoC.