How I Found and Bypassed a Newsletter Confirmation System (IDOR).

I Almost Ignored This… Until It Turned Into a High Severity IDOR.

I go by kjulius, a self-taught Ethical Hacker. 🪞🗿

🌱 It Started Like Any Other Test…
I was casually testing a target and came across a newsletter subscription feature.

Nothing fancy. Nothing exciting.
Just:
• Enter your first & last name.
• Enter your email.
• Click subscribe.
• Confirm via email.

Honestly?
I almost skipped it.
But something spoke in me:

“Try it… just a little deeper.”

🔍 The Small Detail That Changed Everything.

After signing up, I received a confirmation link:

https://newsletter.target.ch/...&p_id=428756&hash=49hbr8wi&lang=it&data=ey....==

At first, it looked normal.

But then I registered again… and again…

I noticed:

• p_id=428757
• p_id=428758
• p_id=428759

👉 Sequential IDs

That tiny detail!
That’s where things got interesting.

🤔 First Attempt… Failed.

I tried swapping IDs between links.

❌ Didn’t work.

Mistake

“An error occurred. We apologize and kindly try again later.”

At that moment, it’s easy to think:
“Okay, it’s secure. Move on.”

But here’s the thing about bug hunting:

“The first attempt failing doesn’t mean the system is secure”.

🔁 Trying Again (This is Where It Matters).

Instead of stopping, I asked:

“What if the system isn’t checking everything it should?”

So I tried something simple…

👉 I took away the hash parameter entirely.

💥 Boom. That Was It.

https://newsletter.target.ch/..&p_id=428757&lang=it&data=ey....==

I opened the link…

✅ “Subscription confirmed successfully”.

“A success message sent to my inbox confirming a successful subscription.”

No token.
No verification.
No ownership check.

🧠 What I Learned Right There.

That moment reinforced something powerful:

“Sometimes the vulnerability isn’t in what’s there… but in what’s NOT being checked.”

🐞 Visualizing the Vulnerability (IDOR in Action).
What was happening behind the scenes:

• The system trusted p_id (user-controlled).
• The hash token was not validated.
• No check ensured the request belonged to the correct user.

👉 “So by changing p_id, I could act on behalf of another user”.

⚠️ Why This Matters

This wasn’t just a small bug.

It meant:

• ❌ Anyone could subscribe any email address without needing their inbox.
• ❌ No consent required.
• ❌ No strict verification enforced.

And because IDs were sequential:

🚨 It could be scaled easily…

🎯 Real Impact.

An attacker could:

• Subscribe thousands of users without needing their inbox.
• Trigger spam complaints.
• Damage company reputation.
• Abuse trust for phishing.

🧠 The Biggest Lesson.

This bug didn’t come from doing something advanced.

It came from:

• Looking closer.
• Trying again.
• Not stopping at the first failure.
• Thinking like a hacker.

💬 Final Thought.

“If I had stopped after my first failed attempt… I would have missed this completely.”

Bug hunting isn’t about being right the first time.

It’s about being:

• Curious.
• Persistent.
• A little stubborn… hackers!😏

🏁 Closing.

What looked like a basic feature turned into a high-impact IDOR vulnerability — all because of one mindset:

Don’t stop at the first “no.” Try again differently. Goodluck Hackers…🍀🌾
More to come… 🌇

How I Found and Bypassed a Newsletter Confirmation System (IDOR). was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.