Post cover image

July 14, 2026

The Parameter That Redirects Nowhere: HTML Injection via redirect_page $125 Bounty

Not every finding is a takeover. This one is a small, clean bug with a real phishing angle: a parameter meant to control post-login…

By Gautam Sharma

2 min read

Not every finding is a takeover. This one is a small, clean bug with a real phishing angle: a parameter meant to control post-login redirects reflected its value straight into the page's HTML, letting an attacker inject arbitrary markup links, text, whatever that renders on the legitimate domain. It was rewarded ~$125, and it's a good example of why "low severity" isn't the same as "not worth reporting."

Where it lives

Log in, then log out, and the app drops you at a login URL that carries a redirect parameter:

https://target/?show_box=login&redirect_page=

The name suggests redirect_page decides where you land after authenticating. What it actually does is get reflected into the page's HTML and that's the whole bug.

The injection

The value lands inside an HTML attribute, unencoded. Closing the attribute and its tag with "> breaks out into element content, where any markup that follows is parsed and rendered. A minimal proof:

redirect_page="> <address>Click the link below for discount voucher<br>
<a href="https://example.com">DISCOUNT</a>.</address>

URL-encoded into the parameter, the full request looks like:

https://target/?show_box=login&redirect_page=%22%3E%20%3Caddress%3E
Click%20the%20link%20below%20for%20discount%20voucher%3Cbr%3E%20
%3Ca%20href=%22https://example.com%22%3EDISCOUNT%3C/a%3E.%3C/address%3E

Open that link and the injected <address> block — heading text and a clickable link to an attacker-chosen destination renders as part of the login page.

Why it's HTML injection, not something it isn't

Worth being precise about the class, because it's easy to overclaim:

  • Not an open redirect. The parameter doesn't send the browser anywhere on its own; the attacker injects a link the victim has to click. The redirect is social, not automatic.
  • Not XSS. I tested for script execution and it didn't fire — script-bearing vectors were filtered while tags still reflected. So this is HTML injection without JS execution, and I report it as exactly that rather than dressing it up.

What it is: attacker-controlled HTML rendering on the target's own origin. That's a content-spoofing / phishing primitive, and the origin is exactly what gives it teeth.

Why a $125 bug still matters

The value here isn't the markup — it's the address bar. A phishing page hosted on attacker.com has to overcome a user's instinct to distrust an unfamiliar domain. This one renders on the real login page, at the real URL, under the real TLS certificate. "Click here for your discount voucher," injected into the genuine site, is far more convincing than the same lure sent from anywhere else and it sits one step from a credential-harvesting flow, since the surrounding page is literally the login box.

It's low severity because it needs the victim to open a crafted link and then act on injected content. It's still valid because it abuses trust in the legitimate origin, which is the one thing a normal phishing page can never borrow.

Root cause and fix

The parameter's value was written into the HTML response without context-aware output encoding, so characters like ", <, and > were treated as markup instead of text.

  • Encode reflected values for the context they land in — at minimum HTML-entity-encode " < > & so injected input renders as inert text, not parsed elements.
  • For a parameter that's supposed to be a redirect target, don't reflect it into HTML at all. Validate it against an allowlist of permitted internal paths and use it only as a redirect, never as page content.

Impact

Reflected HTML injection on the login page, usable to render attacker-controlled content including links to external sites on the legitimate origin. Primary risk is credential phishing that borrows the target's domain and TLS for credibility.

Reported with a PoC. Rewarded ~$125.

Let's connect

If this was useful and you want to talk bug bounty, methodology, or real-world testing, connect with me on LinkedIn: https://www.linkedin.com/in/gautam-sharma177/