- Reflectiz reports that its AI agent found an authentication bypass on a major insurer's live site. The login request let the user pick where the one-time code was sent.
- The insurer had run a penetration test about six months earlier. Reflectiz could not say when the flaw first appeared.
- Ask any testing provider, human or automated, for a coverage record: which tests ran, what they found, and what was left out.
A test result tells you what broke. It does not tell you what was checked. That gap matters more as websites change weekly and attackers use AI to probe them. A new account from Reflectiz, a web security company, shows why.
What Reflectiz says happened
Reflectiz says it pointed an AI agent at the live website of a large insurer, which has millions of users. This was an authorized assessment. The agent was exploring how sign-in works.
At one step the agent asked the site to issue a one-time code. It named an inbox it owned as the place to deliver it. The code landed there, and the agent was signed in.
Built-in limits then ended the test. Reflectiz classed the result as a critical-severity authentication bypass and reported it to the insurer. This is the vendor's own account. The insurer is not named, and no CVE ID is cited.
How the flaw works
A one-time passcode (OTP) is a short code sent to prove who you are. It only works as proof if it goes to a phone or inbox already linked to the account.
Here, the login request carried two fields: the delivery channel and the address. In ordinary use, a text message carried the code to the registered mobile number. But the request could switch delivery to email. After that switch, the site simply used whatever address the request contained.
At no point did the site confirm that the address was one the account holder had registered. OWASP's testing guide frames the core check as whether codes are "tied to the correct user account." Reflectiz adds that someone holding the right customer identifiers might be able to take over that customer's access.
The lesson is about trust. The server let the visitor's request decide something only the server should decide: where a secret is delivered. Any form that lets the user steer a security step deserves this same question.
How the agent got from hunch to proof
Its first step was reconnaissance. It studied the page scripts and the background API calls the site makes. That turned up the code request and a pair of values that looked like they governed delivery.
Reflectiz stresses that such values are a hypothesis, not a finding. The server might reject the change or block it later in the login.
The agent then wrote a test aimed at those two values and ran it against the real sign-in sequence. The login succeeded, which turned the hunch into a confirmed bypass. Reflectiz says the hard part is reaching such flows at all, because much of what matters sits behind a login.
Why a calendar is a weak test schedule
The insurer told Reflectiz it had run a penetration test about six months earlier. That is a hired, scheduled attack simulation. This assessment still found an exploitable login flaw.
Reflectiz could not say when the weakness first appeared. The flaw may have been missed, or it may have arrived in a later release. Reflectiz does not blame the earlier testers and notes a skilled human could have found it too.
The point is structural. Websites change with every release, while test windows stay fixed. Reflectiz argues that attackers using AI will not wait for the next window.
The real purchase is the coverage record
Alongside free-form exploration like the OTP hunt, Reflectiz runs a fixed checklist. Each endpoint the agent finds is tried against each attack type that fits it. Before anything is reported, a second agent repeats the suspected flaw using identical input and context to confirm it.
The result is a record of the tests performed, what each one returned, and anything skipped. This is the idea worth taking from the story. A clean report from any tester, human or machine, is only as reassuring as the record of what it covered.
Reflectiz says this figure measures testing volume, not a promise of ten times more vulnerabilities found. It is a vendor claim and is not independently verified.
What to ask your team and your testers
Treat this account with the care due to a vendor's own write-up. It is one case, described by the company that sells the tool. It does show a useful set of questions.
First, ask which workflows your last test actually reached. Login, account recovery, checkout and customer portals are the usual candidates. Second, ask whether any form lets the user choose where a code, link or message is sent. Third, ask how soon after a release your critical flows get retested.
Finally, ask every provider for the coverage record. Ask what was excluded and why. If the provider is an AI agent, also ask who set its boundaries and who reviews its evidence.
A bug can take one request to exploit. Knowing your tests would have caught it takes a record of what was checked.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: The Hacker News.
