Read the researcher's report on HackerOne
A profile-edit flow accepted a four-digit SMS verification code without limiting failed guesses or expiring the code. A researcher used the app’s session and automated guesses to recover the valid code, potentially enabling changes to a victim’s account profile and contact details.
How it was found
- Proxied the Android app’s traffic and identified the profile-edit verification endpoint.
- Observed that an incorrect code returned an error while a correct code produced a successful response.
- Automated attempts across the four-digit code space using an app session.
- Confirmed the discovered code matched the SMS code and enabled the profile change.
- Access needed
- A user account · an account
- User interaction
- Needed
- Whose object
- Another user's
- Boundary crossed
- The attacker used a victim’s SMS verification flow to authorize changes to that victim’s account profile.
- Root cause
- The verification endpoint lacked rate limiting and code expiration after failed attempts.
- Impact
- An attacker with the required app session could brute-force the SMS code and alter victim account details, creating an account-takeover risk.
- Fix
- The report recommends rate limiting and/or expiring the code after a small number of incorrect attempts; it does not state which fix was implemented.
- Payload class
- Automated brute-force of a four-digit SMS verification code
- Components
- Android app, profile-edit endpoint, SMS verification flow
- Confidence
- high
2FA bypassMissing rate limitAccount takeover chainBusiness logic flaw
This analysis is CyberSIXT's own summary of the public report, written by a model and checked automatically. It may be wrong: the researcher's report is the source. Written 2026-11-15. Ask for a correction or removal.
| Report | Access | Whose object | Boundary crossed |
|---|---|---|---|
| Bypass two-factor authentication | A user account | Another user's | The password-reset flow potentially allowed an attacker to bypass the victim’s two-factor check and take over the account. |
| Rate-limit bypass | A user account | Another user's | Repeated second-factor guesses crossed the authentication boundary into the targeted account. |
| Ability to DOS any organization's SSO and open up the door to account takeovers | A user account | Another tenant's | SSO authentication for one organization resulted in user provisioning into an attacker-controlled organization. |
| Web Authentication Endpoint Credentials Brute-Force Vulnerability | No account | Another user's | An unauthenticated attacker crossed the login boundary by guessing a test account's password and authenticating. |
| Absence of Token expiry leads to Unauthorized login Access | No account | Another user's | An unauthenticated login challenge was used to authenticate as another user's account. |
| Account Takeover via SMS Authentication Flow | No account | Another user's | A victim's SMS verification authenticated a token already obtained by the attacker. |
| Authorization bypass using login by phone option+horizontal escalation possible on Grab Android App | No account | Another user's | Unauthenticated access to another user's account by repeatedly guessing phone-login OTPs. |
| Bypass Password Authentication to Update the Password | A user account | Another user's | A hijacked authenticated session could change another user's password by guessing its current value. |
| No Rate Limiting On Phone Number Login Leads to Login Bypass | No account | Another user's | Unauthenticated access to a victim’s account by guessing the phone-login OTP. |
| bypass two-factor authentication. | No account | Another user's | The account-merging flow granted access to another user's account without two-factor verification. |
| Signup with any Email and Enable 2-FA without verifying Email | No account | Another user's | An unverified account could configure two-factor authentication using another person's email address. |
| Bypass Password Authentication to Update the Password | A user account | Another user's | A hijacked logged-in session could change another user's account password after guessing its current password. |