The Code Went Where It Was Told

An AI pentesting agent logged into a big insurer's production website by asking the site to email it a one-time login code. The site did.

Reflectiz published the case study this week through The Hacker News. It's sponsored content, so read it as a vendor talking about their product. The insurer isn't named and nobody independent has checked the details. I still think it's worth talking about, because I've seen this bug before. More than once.

What happened

The agent was mapping the login flow during an authorized test. The OTP request had two fields in it: how to send the code, and where to send it. Normally it went by SMS to the phone number on the account. Change the method to email, put in any address you like, and the server sent a valid code there. It never checked whether that address had anything to do with the account.

So the agent sent the code to its own inbox, logged in, and stopped. Critical auth bypass on a site with millions of customers, and no human driving.

The insurer had been pentested about six months before.

It's an old mistake

The whole point of a one-time code is that it goes somewhere you've already proven you own. If the request gets to pick the destination, the code doesn't prove anything.

I've run into versions of this for years. Password resets that send the link to whatever email is in the form. Recovery flows that trust a hidden field. MFA setups that let you change the phone number before you've verified the old one. OWASP has it on the testing checklist. It still ended up in production at a company holding insurance data on millions of people.

About that pentest

This is the part I'd want a board to hear.

Nobody knows when the flaw went in. Maybe the last tester missed it. Maybe it shipped a few weeks ago. Either way, the company had a report that said tested and a login anyone could walk through.

I don't blame the testers. A decent one finds this in an afternoon if you point them at the login and give them the time. The problem is testing an app once a year when it changes every couple of weeks. The report tells you what the app looked like on test day, and nothing after.

Attackers have these too

The same week, THN reported an AI pentesting tool being used to steal data from financial firms in South Korea.

The agent in the insurer story had permission, a scope, and a rule to stop once the login worked. The attacker's version doesn't stop. It goes through the account, then moves on to the next insurer, and it runs against hundreds of them at once.

Finding boring auth bugs used to take patience. Now it costs next to nothing. If your login or recovery flow has a mistake like this, something automated is going to find it. I'd rather it was yours.

What I'd do about it

If you run an app with a login, list every place it sends a code or a link. Login, password reset, account recovery, MFA enrollment, email or phone changes, payment step-up. For each one, check that the destination comes from the account record on the server and not from the request. Test it by tampering with the request, not by reading the design doc.

Set up an alert for codes or reset links going to an address or number the account has never used before. It's cheap and it catches this whole class of problem.

Any change to an auth flow should get retested when it ships. Don't wait for next year's pentest.

If you're buying testing, ask what was covered, not just what was found. Which endpoints, which kinds of attacks, what got left out. A clean report doesn't mean much if you can't see what they looked at. And test as often as you release, at least for login, recovery and payments.

If you're going to run an AI agent against production, get the authorization in writing, keep the scope tight, and decide ahead of time where it stops. Also figure out where the codes and session tokens it collects end up, because now it's holding customer access.

If you're on a board, "we got pentested" isn't an answer anymore. Ask when, what was in scope, and what's been released since.

One more thing

I've worked over 600 incident-response engagements. Hardly any of the account takeovers started with something clever. Usually it was a flow that trusted the wrong thing and someone who took the time to poke at it. That time used to be what slowed attackers down. It doesn't anymore.

Source: The Hacker News, October 14, 2026. Sponsored content from Reflectiz.

Somebody is going to poke at your login flow. Make sure it's you first.