Full Report
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
Analysis Summary
# Vulnerability: Critical Authentication Bypass via OTP Destination Manipulation
## CVE Details
- **CVE ID**: Not assigned (Proprietary/Internal finding during authorized assessment)
- **CVSS Score**: Estimated 9.8 (Critical)
- **CWE**: CWE-288: Authentication Bypass Using an Alternate Path or Channel; CWE-604: Use of Untrusted Inputs in a Security Decision
## Affected Systems
- **Products**: Web-based customer portal of a major insurer.
- **Versions**: Production environment active as of October 2026.
- **Configurations**: Systems utilizing Multi-Factor Authentication (MFA) where the delivery channel and address are defined by client-side request parameters.
## Vulnerability Description
The vulnerability is a fundamental breakdown in the binding between a user account and its registered One-Time Passcode (OTP) delivery methods. During the login flow, the application issued an API request to generate a verification code. This request contained two mutable fields: `channel` (e.g., SMS, Email) and `address` (e.g., phone number or email string).
The server-side logic failed to validate if the provided `address` was associated with the authenticating user's profile. Consequently, an attacker could intercept the login request and modify these parameters to redirect the OTP to an attacker-controlled email address or phone number, successfully bypassing the MFA requirement.
## Exploitation
- **Status**: PoC available (Validated by Reflectiz AI pentesting agent in a production environment).
- **Complexity**: Low (Requires only the modification of clear-text API request parameters).
- **Attack Vector**: Network (Remote).
## Impact
- **Confidentiality**: High (Full access to insurance accounts and sensitive personal data).
- **Integrity**: High (Potential to modify account details, beneficiaries, or coverage).
- **Availability**: Low (Account lockout remains a possibility, but primary impact is unauthorized access).
## Remediation
### Patches
- The specific insurer has reportedly addressed the flaw following the assessment, though specific version numbers are not public as it involves a proprietary web platform.
- General remediation involves implementing server-side validation to ensure OTPs are only sent to verified contact methods stored in the user's database record.
### Workarounds
- Disable the ability for users to specify delivery addresses within the authentication request; the server should retrieve the registered address based on the `UserID` or `SessionID`.
## Detection
- **Indicators of Compromise**: Multiple login attempts where the OTP delivery address does not match the historical data for the specific user account.
- **Detection Methods**:
- Log analysis for API calls to `/request-otp` (or similar endpoints) where the `address` parameter differs from the `account_email` on file.
- Implementing DAST (Dynamic Application Security Testing) that specifically checks for parameter pollution or manipulation in authentication headers.
## References
- The Hacker News: hxxps[://]thehackernews[.]com/2026/10/an-ai-agent-found-critical-otp-bypass[.]html
- Reflectiz Research Case Study: hxxps[://]www[.]reflectiz[.]com/lp/agentic-pentesting/
- OWASP Testing Guide (Authentication Testing): hxxps[://]cheatsheetseries[.]owasp[.]org/cheatsheets/Multifactor_Authentication_Checklist[.]html