"With Great Power Comes Great Responsibility"

⚠️ Disclaimer

To follow responsible disclosure practices, I will refer to the target as:

redacted.com

Recon & Discovery

It started like any other recon session.

I was enumerating subdomains using subfinder, followed by filtering for active assets. Nothing unusual — just the usual process of going through each subdomain one by one, looking for anything that stood out.

subfinder -d redacted.com -all > subdomains.txt
cat subdomains.txt | httpx > active.txt

Whlie checking the domains from the list one by one

Most of them were expected.

Until one wasn't.

A subdomain caught my attention:

mailcatcher.redacted.com

That name alone was enough to pause.

Curiosity Kicked In

From experience, naming conventions often reveal more than intended. Words like admin, dev, staging — and in this case, mailcatcher — usually point toward internal or development services.

So I opened it in the browser.

And that's when things got interesting.

An Inbox… Open to the Internet?

What loaded wasn't a login page or an API response.

It was an inbox.

A clean interface showing a list of emails.

No authentication. No access control. No restrictions.

Just… emails.

Within seconds, it became clear — this was a MailCatcher instance exposed to the public internet.

🧠 Connecting the Dots

MailCatcher is typically used in development environments to capture outgoing emails like:

• Account verification
• Password resets
• System notifications

It's never meant to be public.

Understanding the Setup

As I continued testing, I noticed something important.

Both services were hosted under the same root domain, but on different subdomains:

• mailcatcher.redacted.com → Exposed MailCatcher interface
• app.redacted.com (or similar) → Actual application where users sign up and log in

This means the application handling user accounts is separate from the MailCatcher service — but still within the same domain scope.

And that's where the problem begins.

Digging Deeper

Now I needed to confirm one thing:

"Are these emails tied to real user accounts from the application subdomain?"

I started scrolling through the inbox.

And there it was:

• Account-related emails
• System notifications
• Verification emails generated from the application subdomain

That's when things got serious.

If these emails were being captured here, then the tokens inside them were exposed publicly.

To validate the impact, I performed a simple test.

I navigated to the signup page on the main application:

https://app.redacted.com/users/sign_up

I created a new account.

Normally, I would check my email inbox for the verification link.

But this time, I did something different.

I went back to:

https://mailcatcher.redacted.com/

And there it was.

My verification email.

Sitting in a public inbox.

I opened it.

Inside was a verification link containing a valid token.

No need to open Gmail. No need to access my inbox.

Everything was exposed publicly.

🚨 From Discovery to Account Takeover

At this point, the attack path was clear.

If I could see my own verification token, I could also see tokens belonging to other users.

Which means:

1. A user registers or requests password reset on app.redacted.com
2. The email is captured by mailcatcher.redacted.com
3. An attacker accesses the MailCatcher interface
4. Extracts verification or reset tokens
5. Uses them to gain unauthorized access

No interaction required from the victim.

Just a publicly exposed service leaking sensitive data.Complete Account Takeover

Impact

This vulnerability leads to:

• Exposure of sensitive email communications
• Leakage of verification and reset tokens
• Unauthorized access to user accounts
• Full Account Takeover (ATO)

An attacker does not need access to the victim's email inbox.

Recommended fixes:

• Restrict MailCatcher to localhost
• Remove MailCatcher from public-facing environments
• Implement authentication controls
• Use firewall rules to block external access
• Ensure proper separation of development and production systems

Lessons Learned

• Subdomain enumeration reveals hidden attack surfaces
• Naming conventions can leak sensitive functionality
• Always investigate unusual subdomains
• Misconfigured dev tools can lead to critical vulnerabilities

Final Thought

Sometimes the most critical bugs are the simplest ones.

Just sitting there… waiting to be noticed.

A Small Note

Although this finding demonstrated a critical impact, it was ultimately marked as a duplicate.

Still, the experience was valuable — it reinforced the importance of thorough recon and thinking from an attacker's perspective.

Every finding, even duplicates, is a step forward in becoming a better hunter.

#bugbounty #cybersecurity #infosec #accounttakeover #ethicalhacking #securityresearch #hacking #web #infoseccommunity #responsibledisclosure #bugcrowd #vulnerability