The bug was simple: the login let you choose where your sign-in code went. Proving it on a live website was the hard part.
TL;DR
- During an authorized assessment, an AI pentesting agent found a critical authentication bypass on a major insurer's production website, on its own.
- One login request let the user choose where the one-time passcode went.
- The attack was the easy part. Proving it on a live site took web context built over a decade.
The Login Worked. Then the Agent Stopped.
Reflectiz's AI pentesting agent was mapping the login flow of a major insurer's production website, which has millions of users.
The agent requested a login code and directed it to an email inbox it controlled. The code arrived. The login went through. Its guardrails halted the test after the login succeeded.
The agent had discovered a critical-severity authentication bypass on its own. Reflectiz reported it to the insurer.
The Flaw: The Request Chose Where the Code Went
A one-time passcode (OTP) only proves who you are if it goes somewhere already linked to the account. Here, that link was broken.
The login request carried two fields that decided delivery: the channel and the address. Normally, the code went by text to the phone number on the account. But the request could change the channel. Switch it to email, and the server sent the code to whatever address the request named, not the address registered to the account.
Simplified, the request looked like this:
The server never checked that the address belonged to the account.
Binding a code to its account is one of the most basic checks in authentication. OWASP's testing guide asks this in plain words: "Are the OTPs tied to the correct user account...?"
An attacker with the required customer identifiers could potentially use the flaw to access that customer's account.
From a Suspicious Field to a Proven Bypass
The agent began with reconnaissance, looking at the site's JavaScript and the API calls behind its pages. That analysis surfaced the OTP request and two values that appeared to control how and where the code was sent. Values like those can suggest a hypothesis, but they’re not a finding, since the server might reject the changes or block them later in the login. So the agent built a targeted test around both values and ran it through the live login flow, which confirmed the bypass.
 |
| Illustration of the authenticated state the agent reached before stopping. Recreated and anonymized. |
Want to see how that testing process works? Book a technical demo to examine how Reflectiz investigates website workflows, validates findings, and controls execution.
Web Context Is the Hard Part
Plenty of automated testing stops at the login gate, but much of what matters sits behind it. A testing system that cannot reach a workflow cannot assess what happens inside it.
Reflectiz solved that problem long before the agent existed. The company has spent more than a decade scanning thousands of production websites, which meant logging in, receiving verification codes, and navigating multi-step flows. So, on sites the company already monitors, the agent starts with that context instead of a blank URL.
Reflectiz's agentic pentesting puts that web context to work. It drives a real browser through the flows a customer follows, including one-time passcodes and 2FA.
Reflectiz CTO and co-founder Ysrael Gurt, a longtime ethical hacker, built the agent on that foundation.
One Finding Is Not a Coverage Report
A confirmed vulnerability may show what failed, but it doesn’t show how much of the application was tested.
The OTP test ran alongside other attack plans on the same site. Reflectiz's agentic pentesting pairs that open-ended investigation with a structured plan: test every discovered endpoint against every applicable attack category. A separate validator agent reproduces each suspected finding with the same payload and context before it is reported.
The output is a coverage record of which tests ran, their recorded outcomes, and any exclusions.
Pentested Is Not the Same as Secure
The insurer said it had pentested the site about six months earlier. This assessment found an exploitable login flaw, though it is unclear when the weakness was introduced.
That is not a reflection on human testers, because a skilled tester could have found this flaw too. It’s more a reflection on the nature of point-in-time testing. It has its place, but how often can anyone afford to look?
Websites change with every release, but pentest schedules don't. They’re rigid, which isn’t much use against attackers who now use AI to find flaws fast and won’t wait for the next test window.
Agentic testing keeps pace. It can repeat focused tests as often as the site changes, provided the agent has the right access and clear boundaries, and produces evidence a reviewer can verify.
Reflectiz reports up to 10x the testing capacity at the same operational cost as traditional manual pentesting. The comparison concerns testing volume, rather than a guarantee of 10x more vulnerabilities found. In the demo, ask how scope, testing depth, and frequency affect capacity and cost for your applications.
Bring Your Toughest Website Workflow to the Demo
Book a 30-minute technical demo with a Reflectiz web security specialist. Before the demo, think about a workflow that matters to your business. It could be login, account recovery, checkout, or a customer portal.
During the demo you can then review:
- How the agent navigates authenticated, multi-step workflows
- What evidence it finds to support a validated finding
- How scope, guardrails, and coverage are documented
Discuss your application's requirements and what a first assessment would involve. No commitment is required, and there’s no need to test your website during the walkthrough.
Book your agentic pentesting demo
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.