Reflectiz's AI pentest agent redirected an insurer's login code to its own inbox
Reflectiz's AI pentest agent logged into a major insurer's production site by sending its one-time code to an inbox it controlled. The server never checked the address against the account, so the code proved nothing about who held it.
The Watch · Security desk
With the channel set to email, the server sent the code to any address the request named. Per Reflectiz, its agent sent one to its own inbox and logged in. An attacker with a customer's identifiers could potentially access the account. The insurer said it pentested about six months earlier.
- What it limits constraint Insurer's login server Switching the channel field to email sent the code to whatever address the request named, claim 1
- What's now possible capability Reflectiz's AI pentest agent Per Reflectiz, directed a login code to an inbox it controlled; the code arrived and login went through, claim 14
- Who's exposed exposure Insurer's customers An attacker with the required customer identifiers could potentially access that customer's account, claim 3
- What it sets up precedent Insurer Said it pentested the site about six months earlier; when the weakness was introduced is unclear, claim 7
| Who | How | Kind | Claim |
|---|---|---|---|
| Insurer's login server | Switching the channel field to email sent the code to whatever address the request named | constraint | 1 |
| Reflectiz's AI pentest agent | Per Reflectiz, directed a login code to an inbox it controlled; the code arrived and login went through | capability | 14 |
| Insurer's customers | An attacker with the required customer identifiers could potentially access that customer's account | exposure | 3 |
| Insurer | Said it pentested the site about six months earlier; when the weakness was introduced is unclear | precedent | 7 |
What happened
- The agent mapped the login flow through the site's JavaScript and API calls, found two values that seemed to control OTP delivery, and tested both against the live login.
- By default the code went by text to the phone on the account, but switching the channel to email sent it to any address the request named.
- The agent's guardrails halted the test once the login succeeded, so it went no further into the account.
- Reflectiz reported the bypass to the insurer and rated it critical.
Why it matters
- Who's exposed exposure The weak point is the identifiers. An attacker holding a customer's required identifiers could take over that account, per Reflectiz.
- Who has to decide decision Teams running OTP flows have to decide whether any client-supplied channel or address field stays. The destination should come from the account record.
- What it limits constraint The insurer's pentest about six months earlier did not catch it, and the date the flaw arrived is unknown, so a clean report that old says little about it.
- What's now possible capability According to Reflectiz, an agent that drives a real browser through OTP and 2FA flows can test behind the login gate, where much automated testing stops.
Reflectiz's write-up says a one-time passcode proves identity only if it goes somewhere already linked to the account [8]. OWASP's testing guide asks the control question in plain words: "Are the OTPs tied to the correct user account...?" [4] The insurer's server skipped that check [2].
Reflectiz calls the bug simple [9]. The exploit is an edited channel and address pair in one login request [1]. The precondition sets the real risk, because the attacker needs the customer's identifiers first [3]. Reflectiz's account does not name the insurer, say which identifiers the request required, say whether the flaw is fixed, or link it to any attacker. We'd treat it as a one-off logic error on one site.
The finding rests on Reflectiz's description of its own tool, and the source text includes an offer to book a technical demo [12]. The values the agent spotted in the site's JavaScript were only a hypothesis until a targeted test ran through the live login flow [5]. And Reflectiz says a skilled human tester could have found this flaw too [11]. It also says a separate validator agent reproduces each suspected finding with the same payload and context before anything is reported [6]. Reflectiz did not publish the validator's results for this case.
In our view the fix is a server-side lookup. The request may pick among channels already registered to the account, and the address comes from the account record. Changing a registered address is its own event and needs its own verification.
Any team can test its exposure with one request: does the OTP call accept a channel or address from the client? If it does not, this finding does not apply.
What to watch
- Whether Reflectiz or the insurer confirms the flaw is fixed and says which customer identifiers the request needed.
- Whether anyone independent reproduces the finding or reports another site that takes its OTP destination from the request.
- Whether Reflectiz publishes the coverage record it says each assessment produces, showing which tests ran on this site.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence45
- Adoption
- Not scored
- Hype gap+30
- Incentives85
- Confidence50
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The login request carried two fields, channel and address, that decided delivery. Normally the code went by text to the phone number on the account, but switching the channel to email made the server send the code to whatever address the request named, not the address registered to the account.
- [2]
The server never checked that the address belonged to the account.
- [3]
An attacker with the required customer identifiers could potentially use the flaw to access that customer's account.
- [4]
OWASP's testing guide asks: "Are the OTPs tied to the correct user account...?"
- [5]
The agent began with reconnaissance of the site's JavaScript and API calls, which surfaced the OTP request and two values that appeared to control how and where the code was sent. Those values were a hypothesis, not a finding, so the agent built a targeted test around both and ran it through the live login flow, which confirmed the bypass.
- [6]
A separate validator agent reproduces each suspected finding with the same payload and context before it is reported.
- [7]
The insurer said it had pentested the site about six months earlier; it is unclear when the weakness was introduced.
- [8]
A one-time passcode only proves who you are if it goes somewhere already linked to the account.
- [9]
Reflectiz describes the bug as simple: the login let you choose where your sign-in code went.
- [10]
Reflectiz says its agentic pentesting drives a real browser through the flows a customer follows, including one-time passcodes and 2FA, and that plenty of automated testing stops at the login gate.
- [11]
Reflectiz says a skilled human tester could have found this flaw too.
- [12]
The source text includes an offer to book a technical demo of how Reflectiz investigates website workflows, validates findings and controls execution.
- [13]
During an authorized assessment, Reflectiz's AI pentesting agent found a critical-severity authentication bypass on a major insurer's production website, which has millions of users.
- [14]
The agent requested a login code and directed it to an email inbox it controlled; the code arrived and the login went through.
- [15]
The agent's guardrails halted the test after the login succeeded.
- [16]
Reflectiz reported the finding to the insurer.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- thehackernews.comAn AI Agent Found a Critical OTP Bypass in Production. The Attack Was the Easy Part.
1 article · October 14, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Authentication securityFollow
- AI penetration testingFollow
- Web Application SecurityFollow