WhoAmI
I am Ankit Rathva and i am a student of MCA 1st year, I am an ethical hacker and security researcher with a passion for finding logic, authorization, and data-integrity flaws in web applications. As a bug bounty hunter and red teamer, he combines hands-on testing, forensic analysis, and careful disclosure to help teams fix impactful issues while protecting users. He publishes clear, developer-friendly writeups and practical mitigation advice — connect to follow his work or collaborate on security research.
Connect with me: https://linkedin.com/in/ankitrathva
TL;DR: I discovered a high-severity vulnerability in the email verification flow of mypup.app that allows an attacker to verify any e-mail address by tampering with the emailAddress parameter in the verification request. An attacker who can intercept and modify the verification request (for example, via a proxied session) can make the server accept a verification for an address that never received or entered the OTP. This can lead to account takeover or other privilege escalation where e-mail ownership is used for recovery/identity.
Summary
While testing the account management flow on https://target.app/Account/Manage I found that the final verification request is not bound to the original email / OTP pair. By changing the emailAddress parameter in the request payload before it reaches the server, it is possible to mark an arbitrary e-mail as verified without the owner ever receiving or entering the OTP.
Vulnerability name: Email Verification Bypass Severity: High
Steps to reproduce
These steps describe how the issue can be reproduced during testing. Do not use them for malicious purposes .
1. Create a new account on the site and log in. 2. Go to the account management page: https://target.app/Account/Manage. 3. Change your account's email to a controlled attacker address (example: attacker@mail.com). The site generates two OTPs — one for the current email, and one for the new email — and prompts to enter them before saving. 4. Intercept the outgoing verification request using an intercepting proxy (e.g., Burp Suite). 5. In the request payload find the parameter:
"emailAddress": "attacker@mail.com" 6. Modify it to:
"emailAddress": "victim@mail.com"
then forward the request to the server.

7. Request and mark victim@mail.com as verified — even though the OTP was never delivered to or entered by the victim.

Impact
An attacker can mark any e-mail as verified without the owner's involvement.
If the application allows login, password reset, or account linking using verified e-mail, this issue could lead to account takeover or unauthorized access.
It bypasses the core purpose of email OTP verification by decoupling the OTP from the email it was meant to protect.
Disclosure & reward
I reported the issue to the target.app security/contact channel. The company validated the finding and confirmed the issue — they rewarded me €75 for the report. I appreciate the vendor's quick verification and responsible handling.

Follow for more
If you want to read more findings, write-ups, and bug bounty guides, follow my Medium profile and turn on notifications — I post regular write-ups, technical walkthroughs, and practical mitigation tips. Thanks for reading!