Finding the Bug Was Easy… Proving the Impact Wasn’t

Chasing Impact: A Disposable Email Bypass That Couldn't Go Further

Overview

While assessing a target, I noticed that the application enforced a restriction against disposable email providers. My first attempt was to register using a temporary email address, but the request was immediately rejected. At first glance, the validation appeared to be working correctly.

Rather than spending more time on the registration page, I created an account using a legitimate email address and continued exploring the application. I wanted to understand how email validation was implemented throughout the user lifecycle.

Discovery

After logging in, I found an option to change the account's email address.

I repeated the same test by replacing my email with a disposable one.

Once again, the application rejected the request.

At that point, I started thinking about how the validation worked. Most disposable email addresses have random-looking local parts (the portion before the @ symbol), so I wondered whether the validation logic was inspecting the email exactly as it was received.

To test this idea, I URL-encoded only the local part of the email address.

Instead of sending:

bughunter@test.com

bughunter@test.com

I sent:

%62%75%67%68%75%6e%74%65%72@test.com

%62%75%67%68%75%6e%74%65%72@test.com

To my surprise, the request was accepted.

The application stored the email exactly as it was submitted, including the URL-encoded characters, allowing me to bypass the disposable email restriction.

Key Finding

The root cause of the issue was improper input validation.

The application accepted URL-encoded characters inside the local part of an email address without first normalizing or canonicalizing the input. As a result, the disposable email detection logic failed to recognize the encoded email as belonging to a restricted provider.

Rather than decoding the email before validation, the application simply accepted and stored the encoded value as-is, allowing the email policy to be bypassed.

Vulnerability Behavior

Once I confirmed the bypass, my next objective was no longer finding the vulnerability — it was increasing its impact.

My first idea was to determine whether the application would treat the encoded email as a different identity during sensitive workflows such as password reset or account recovery.

If the backend considered the encoded and non-encoded versions of the same email to be different, there might have been an opportunity for account confusion or identity-related issues.

However, after testing those scenarios, the backend handled them correctly. There was no way to abuse the password reset flow or confuse the application's identity management.

Next, I searched for every location where the stored email appeared inside the application.

I wanted to determine whether the application decoded the stored value before rendering it, or whether it transformed the email into a clickable hyperlink. Either behavior could potentially open the door for HTML injection or Stored XSS.

Unfortunately, neither happened.

The encoded email was displayed exactly as it had been stored — as plain text. The application never decoded the value when rendering it, and it never interpreted it as HTML or any executable content.

Since the email address had very limited usage throughout the application, there were no practical opportunities to chain this bypass into a more impactful vulnerability.

Impact

From a security perspective, the issue allowed users to bypass the application's policy that prohibited disposable email providers.

However, because the encoded value remained encoded after storage and was never interpreted in a dangerous context, I couldn't leverage the bypass into a more serious vulnerability.

As a result, the report was ultimately classified as Informational (P5).

Although the severity was low, the experience reinforced an important lesson: finding a vulnerability is only the first step. The real challenge is demonstrating how that vulnerability can impact the application's security.

Conclusion

This finding wasn't memorable because of the bypass itself — it was memorable because of everything that came afterward.

Once the bypass was confirmed, most of the work shifted toward trying to increase its impact. I explored different attack paths, tested multiple scenarios, and looked for opportunities to chain the issue into something more significant.

None of those attempts succeeded.

At first, receiving an Informational classification was disappointing. But looking back, I realized that this engagement taught me something more valuable than a higher severity rating.

Bug bounty isn't just about finding vulnerabilities.

It's about understanding how applications behave, thinking beyond the initial discovery, and asking one important question:

"What can this vulnerability become?"

Sometimes the answer leads to a critical finding.

Sometimes it doesn't.

And that's perfectly fine.

Every failed escalation attempt improves your methodology, strengthens your technical thinking, and prepares you for the next vulnerability that can be turned into something much more impactful.