When the login lets the requester pick where the OTP goes

A one-time passcode only proves identity if it lands somewhere the account already trusts. A newly published case study shows what happens when it doesn't. An automated testing agent, working in an authorized assessment, found that a large insurer's production login would send the sign-in code to any email address named in the request. That turned a second factor into a formality.

What happened

Reflectiz, the security vendor behind the case study, says its AI-driven testing agent was mapping the login flow of a major insurer's customer site. The insurer serves millions of users and is not named. While reviewing the site's JavaScript and the API calls behind it, the agent spotted two parameters in the OTP request: one set the delivery channel and the other set the destination address.

The code normally went by SMS to the phone number on file. When the agent changed the channel to email and pointed the address at an inbox it controlled, the server sent the code there. It never checked that the address belonged to the account. The code worked, the login succeeded, and the agent's guardrails stopped the test at that point. The vendor says it rated the issue critical and reported it to the insurer.

A few caveats matter here:

• The details come from the vendor's own account in sponsored content, and the insurer is anonymized.
• To abuse the flaw, an attacker would still need the customer identifiers the request required, such as an ID number and phone number.
• The insurer reportedly had a pentest about six months earlier. It is not clear when the weakness was introduced, so this doesn't show that the earlier test missed it.
• The case study does not say whether or when the flaw was fixed.

Why it matters

This is a classic broken-authentication bug, not an exotic one. OWASP's testing guidance asks directly whether OTPs are bound to the correct user account. When client-supplied fields decide where a secret is delivered, MFA effectively downgrades to "knows the customer's ID and phone number". That data is routinely exposed in breaches.

There is also a process lesson. Flaws like this tend to appear when a feature is added, such as "send my code by email instead". Point-in-time testing captures one snapshot of an application that keeps changing with every release.

What to do

• Bind OTP delivery server-side. Resolve the destination only from contact details already verified on the account. Never accept an address or phone number from the login request.
• Treat channel switching as sensitive. If users can choose SMS or email, offer only channels already registered and verified, and refer to them by an opaque ID rather than the raw address.
• Review the request schema. Check every authentication, recovery and step-up endpoint for fields like channel, sendTo, email or phone, and reject or ignore them where they shouldn't be client-controlled.
• Test the business logic, not just the scanner checklist. Add negative tests (OTP to an unregistered destination must fail) to CI, and include auth flows in recurring assessments.
• Monitor for abuse. Alert on OTPs sent to destinations that don't match the account profile, and rate-limit OTP requests per account and per identifier.
• Re-test after changes to login, recovery or MFA flows instead of waiting for the next annual pentest.

Credit: this article summarizes a sponsored case study by Reflectiz, published by The Hacker News on 14 October 2026.