That was the question that started it all. I wasn’t trying to break anything. I was just poking around the email preferences page of a large business website, you know, the usual “Manage my subscriptions” page we all ignore. But what I found turned out to be a silent and surprisingly powerful vulnerability.

The innocent curiosity 👀

It began like most bug-hunting stories, a lazy evening, coffee in one hand, Burp Suite in the other.
I logged into the website, visited the “Manage Preferences” section, and changed one of my email settings just to see what kind of request it would send in the background.

Boom — there it was.
A simple POST request, clean and minimal:

Nothing fancy. No tokens. No authentication headers. Just an email parameter and a few IDs.

At first, it didn’t look dangerous. But the lack of complexity was exactly what caught my eye.

“Wait… what if I put someone else’s email?”

That thought hit me like a caffeine shot.

So I tried it.

I replaced my email with a random one, a publicly listed company email I found on their Contact Us page. Then, I hit Send.

Response?

{"code":200,"status":"SUCCESS","message":"OK","data":{"message":"Unsubscribed Successfully."}}

Success.
No error, no permission check, no authentication required.

It actually worked.

The server had just accepted my request and unsubscribed someone else’s email address as if I were them.

The confirmation endpoint —> the double punch 🥊

If that was bad, the next discovery was the knockout. While testing, I found a second endpoint — one that returns the current email preferences when you supply an email. Guess what it checked?

You guessed it: only the email. No login, no token, no captcha — just the email.

That meant the workflow was terrifyingly simple:

1. Send an unauthenticated request to change preferences for [email protected].
2. Query the second endpoint with [email protected] and see the response showing all their preferences now changed.
3. Repeat at scale.

BOOM!!!

I could ensure my silent tampering actually worked and automate checks across thousands of addresses. The confirmation endpoint turned a one-off annoyance into an efficiently verifiable and therefore exploitable vector.

The silent impact

Here’s the scary part:
The victim (the real owner of the email) received no notification at all.

No “Your preferences were changed.”
No “If this wasn’t you, click here.”
Nothing.

That meant I could:

• Silently unsubscribe anyone from all company emails.
• Disable marketing or alert emails for thousands of users if I wanted to automate it.
• Even prevent users from receiving important security notifications or billing updates.

And with the confirmation endpoint, I had instant proof of success. The system not only let me tamper, it let me verify the tampering — all without authentication.

Lessons learned 🧠

This bug wasn’t glamorous. It didn’t require fancy payloads or deep protocol bugs. It was a failure of trust assumptions: the system trusted an email string as an authority and trusted that returning preference data was safe.

The lesson for engineers: treat emails and public identifiers as attributes — never as authentication. And for product folks: if a change affects someone else, make sure that someone else knows about it.

If you enjoyed this write-up, drop a 💬 or share it with someone who still thinks “it’s just an email preference page.”

💬 Let’s Connect:

• 🐦 Twitter/X: @mr0x1_