Okay, so this is my first write-up. I was a little nervous to post this, but I figured — if the server is going to hand me the tokens to someone's account in plain JSON, the least I can do is write about it.
Let's get into it.
A little background
🔒 This was submitted to a private Bugcrowd program — I can't share the target name per disclosure policy.
I was testing a web application that has a user activation flow. The idea is simple: you enter your email, the app sends you a link, you click the link, and your account gets activated.
Classic stuff. Email verification 101. Been around forever. Should be bulletproof.
It was not bulletproof.
What I was looking at
The activation flow worked like this:
You send a POST request with your email to /api/v1/Enrollment. The server processes it and — supposedly — sends you an email with a private link to activate your account. You are expected to open that email, click the link, and only then continue.
The key word there is "supposedly."
The request
Here is what I sent:
Normal looking request. Nothing fancy. I hit send and looked at the response.
The response that changed everything
And here is what came back:
The server just… gave me the activation credential. In the response. Without me verifying anything. I did not even open an email inbox. I just got it. For free.
That practiceAdminGuid? That is the token the activation link is built with. The one that is supposed to arrive only in the victim's email. The server just dropped it in the JSON response.
Using the leaked credential
At first, I checked the activation link that arrived in the email. It was long, encrypted-looking, and I could not easily spot the practiceAdminGuid inside it. Honestly, I almost moved on.
But then I went back to Burp Suite and looked at the raw API requests more carefully. That's when I noticed it — the practiceAdminGuid was sitting right there in the POST response, completely exposed, no encryption, no obfuscation. Clean and readable.
https://[redacted.com]/enrollment/{practiceAdminGuid}/enrollment-successOpened it in the browser. The app accepted it. No questions asked. Account activated. Full access to the workflow — as the victim — without ever touching their inbox.
Why this is a real problem
Email verification exists for one reason: to prove you own the email address. If the server hands you the verification token in the response body — before you prove anything — then email verification does not exist anymore.
On a healthcare-adjacent platform, this is not a minor issue. We are talking about someone being able to activate and operate an account that belongs to a real doctor, a real practice, a real person.
The fix is simple
Two things need to happen. First, the practiceAdminGuid should never appear in the API response body. Send it only via email — that is literally the whole point. Second, the server should verify that the activation was completed through the email link before allowing any further steps. Both checks. Not just one.
What I learned from this
Honestly? I almost missed this. I was focused on the UI flow and almost forgot to check what the raw API response contained. The lesson is: always read the full response body. Every field. Even the ones that look boring.
This is my first public write-up. If something is unclear or you have feedback — I am all ears. Thanks for reading, and happy hunting out there.