As reported by The Hacker News, an AI-powered pentesting agent from Reflectiz autonomously discovered a critical authentication bypass on a major insurer's production website — a flaw that allowed the one-time passcode (OTP) delivery channel and destination address to be controlled by the login request itself, rather than being bound to the account's registered contact information.

Security Impact: This finding is significant not because the vulnerability is novel — it isn't — but because it underscores how a foundational authentication design error persists in production at scale, at a major financial services organization, in 2026.

This finding is significant not because the vulnerability is novel — it isn't — but because it underscores how a foundational authentication design error persists in production at scale, at a major financial services organization, in 2026. The OWASP testing guide has explicitly called out this exact failure pattern for years: OTPs must be tied to the correct user account and delivered through a pre-registered, verified channel. When the server trusts client-supplied delivery parameters, the entire second factor collapses into theater.

Why This Matters

The vulnerability class here is straightforward: the OTP request accepted two attacker-controllable fields — delivery channel (SMS vs. email) and destination address. The server failed to validate that the destination belonged to the account being authenticated. An attacker who knew or could enumerate customer identifiers could redirect the OTP to their own inbox, complete the login flow, and gain full account access.

The core issue is not an exotic logic flaw. It is the absence of server-side binding between the OTP, the account, and the registered delivery endpoint. This is Authentication 101.

What makes this story notable is the detection method. Traditional DAST scanners routinely stop at authentication boundaries. They cannot meaningfully test behind login because they lack the web context — session state, JavaScript-driven API flows, multi-step workflows — needed to interact with authenticated functionality. An AI agent that can map JavaScript, follow API call chains, hypothesize about parameter behavior, and construct targeted tests against live flows represents a meaningful shift in automated security testing capability.

Who Is at Risk

Why This Matters
Financial services and insurance platforms handling high-value accounts via OTP-based authentication
Any application where OTP delivery channel or destination is client-configurable rather than server-enforced
Legacy authentication systems that were built before modern OTP standards and never refactored
APIs backing mobile or web frontends where the client selects delivery parameters and the server fails to override them

Broader Implications

The fact that this class of bug still reaches production at an enterprise with millions of users tells us that pre-deployment security review is not catching basic authentication design flaws. Code review, threat modeling, and automated testing all missed this. The insurance sector, subject to regulatory frameworks like NAIC model laws and state-level cybersecurity requirements, should be held to a higher standard for authentication architecture.

The AI pentesting angle is secondary but worth watching. The agent's guardrails correctly halted after confirming the bypass — it did not proceed further into the authenticated session. That restraint matters for authorized testing on production systems. Organizations evaluating AI-driven security tools should scrutinize not just detection capability but also the guardrail architecture governing test scope and execution boundaries.

Shield53 Recommendations

  • Audit OTP flows immediately: Review all authentication endpoints that issue one-time codes. Confirm the server enforces delivery to the account's registered, verified contact method. Client-supplied channel or address fields must be ignored or validated against account records — never trusted.
  • Implement server-side binding: The OTP generation request must reference the account's pre-registered delivery endpoint. The delivery channel and address should be resolved server-side from the account record, not accepted from the request body.
  • Test behind authentication: Traditional DAST is insufficient. Augment with authenticated testing — manual or AI-assisted — that can follow multi-step login flows and manipulate parameters in context.
  • Add runtime detection: Deploy application-layer monitoring that flags OTP requests where the delivery address deviates from the registered contact on file. Alert on channel-switching behavior within a single session.
  • Review API parameter trust boundaries: Map every authentication-related API endpoint and identify any parameter that influences security-relevant behavior. Ensure the server is the authoritative source for all such values.
  • Enforce rate limiting on OTP issuance: Limit OTP generation frequency per account and per destination address to slow enumeration and redirect attacks.
This is not a sophisticated attack. It is a basic design failure that should never survive code review. The lesson is not about AI finding bugs — it is about basic server-side validation still being missing in production at organizations that should know better.