AI Pentest Agent Found an OTP Bypass a Human Test Missed

An AI pentesting agent, running on its own against a major insurer's production website, found a critical authentication bypass that a human penetration test had missed about six months earlier. The flaw was almost embarrassingly simple: the login flow let the request decide where the one-time passcode (OTP) was delivered. The hard part — the part that makes this a real engineering story and not a demo — was proving the bypass worked on a live site serving millions of customers without touching a single real account.

Developing story — first published 17:35 CEST (15:35 UTC), October 14, 2026. Updated as more technical detail is published.

The account comes from Reflectiz, whose co-founder and CTO Ysrael Gurt described the finding in a contributed write-up on The Hacker News on October 14. Treat the specifics as the vendor's own account of an authorized engagement — but the mechanism is a textbook one, and the lesson underneath it is the part worth keeping.

What the AI pentest agent actually found

According to Reflectiz, the agent started with reconnaissance: it read the site's client-side JavaScript and mapped the API calls behind the login pages. That surfaced the OTP request — and, inside it, two values that controlled delivery. One selected the channel; one carried the destination address.

In normal use, the code was texted to the phone number on the account. But the request could switch the channel to email and send the code to any address it named. The server never checked that the address belonged to the account. An attacker who already held the right customer identifiers could point the victim's login code at an inbox they controlled, read it, and finish the login as that user.

That is a classic broken-authentication failure — the OTP was treated as a secret in transit but the destination of the secret was attacker-controllable. OWASP's Web Security Testing Guide has long told testers to confirm exactly this: that a second factor is bound to the correct account and cannot be rerouted. It is the kind of check a thorough human tester is supposed to make — and, on this site, apparently did not, or did and moved on.

"The attack was the easy part" is the real lesson

The agent did not just flag a suspicious parameter and write a ticket. Per Reflectiz, it treated the two delivery values as a hypothesis, built a targeted test, and ran it through the live login flow: it requested a code, directed it to an inbox it controlled, and logged in. A guardrail then halted execution the moment the login succeeded — far enough to prove the bypass, not one step further.

That sequence is harder than it sounds, and it is where most "autonomous pentest" demos quietly stop:

• The login is a multi-step authenticated flow, not a single request you can fuzz.
• Proving the bypass means actually receiving and handling a real verification code mid-flow.
• Doing it on production means doing it without compromising, locking, or spamming real customer accounts.

"A scanner can tell you a parameter looks interesting. It cannot tell you whether, on this build, a stranger can log in as you. The only way to know is to run the chain — and stop at exactly the right line."

Reflectiz says a separate validator agent then reproduced the finding with the same payload and context before it was reported, and the engagement produced a coverage record of what was tested, what the outcome was, and what was deliberately excluded. That reproduce-before-you-report discipline is the difference between a finding an engineer can act on and a false positive that burns a security team's trust.

Why this lands now

OTP-based login at insurers is under live attack, not hypothetical pressure. In July 2026, CTM360 documented a phishing-as-a-service kit — "InsureOTP" — that relays victims' one-time passcodes in real time against real insurance portals, concentrated in Saudi Arabia with activity in Europe, the US and India. Attackers are already industrializing the theft of OTPs. A login flow that will mail the code to whoever asks is a gift to exactly that ecosystem — no phishing page required.

Remediation

If your own authentication flow lets the client influence where a code goes, you have this bug. The fix is specific.

Am I affected? Inspect every OTP/MFA send endpoint. Can the request body specify the delivery channel or the destination address? Does the server re-derive the destination from the authenticated account record, or does it trust a client-supplied field? If the destination comes from the request, you are exposed.

Fix. Never accept a client-supplied OTP destination at authentication time. Derive the channel and address server-side from the account's verified, on-file contact. Treat changing a delivery channel or address as a sensitive operation that requires re-authentication and step-up — never as a side effect of a login request.

Compensating controls while you fix it. Move high-value accounts to phishing-resistant, origin-bound MFA (FIDO2/passkeys), which defeats both this reroute and the InsureOTP-style relay, because a code entered on the wrong origin is useless. Rate-limit OTP sends and alert when a requested destination differs from the on-file contact.

Hunt for abuse. Review OTP-send logs for requests whose destination does not match the account's on-file contact, and for successful logins preceded by a code sent to a mismatched address. Map to MITRE ATT&CK T1621 (Multi-Factor Authentication Request Generation), T1556 (Modify Authentication Process) and T1078 (Valid Accounts).

Verify. Re-test the repaired flow with the same payload that proved the bug. A fix is confirmed only when the code can reach only the server-derived destination, no matter what the request asks for.

What is not known yet

The insurer is unnamed and the finding is reported through the vendor's own account; the affected request parameters were not published, there is no CVE and no independent confirmation of scope or remediation status. Whether the flaw has been fully fixed, and whether it was ever abused in the wild, is not public.

Run the same offense first

The uncomfortable part of this story is not that an AI found the bug. It is that a human pentest six months earlier did not — and that one annual or quarterly test is the entire assurance most production login flows ever get. An autonomous agent that can safely re-run the attacker's own playbook, continuously, is the thing that closes that gap.

That is the problem Zero Hunt's autonomous AI red team is built for. Its 10-agent swarm runs recon, finds the input-reachable weakness, and — through a sealed coding agent — iterates a proof-of-concept until it demonstrably works, the same reproduce-before-you-report discipline that makes a finding trustworthy. Every PoC runs inside an ephemeral container with optional gVisor hardening, so proving a bypass never endangers the host or real users; every action that crosses a line waits on a human-in-the-loop gate; every finding is signed at write time (Ed25519, hash-chained) so the evidence holds up afterward. Authenticated, multi-step flows like this insurer's login are gray-box territory — real credentials, real login sequences — while the engine runs black-box by default. It all runs on the on-premise appliance on private models, so the authenticated traffic and the customer identifiers it handles never leave the box, and there is no external party that can throttle or switch the capability off. That is how automated penetration testing stops being a once-a-year snapshot and becomes something that would have caught this in week one. If your login flow decides where the code goes, let us prove what an attacker could do with it — safely.