LLM agent shipped first attributed zero-day

The advisory ran four paragraphs. A pre-authentication bypass in the TOTP verification path of a widely-deployed identity broker. CVSS v3 base 9.1. Network-reachable. No user interaction. Confirmed mass exploitation prior to patch. The detail that made the disclosure unusual was buried in the acknowledgements - the vulnerability and the working primitive were produced by an LLM agent running automated state-machine exploration against the broker’s authentication endpoints. The first publicly-attributed zero-day where discovery, primitive construction, and exploit packaging ran end-to-end through an AI pipeline before a human researcher touched the bug.

The bug class is cross-account state confusion in a multi-step authentication state machine. CWE-639, authorisation bypass through user-controlled key. The broker’s login flow is a three-step exchange. Step one submits username and password and returns an opaque session ticket. Step two submits the ticket and a TOTP code. Step three exchanges the verified ticket for a signed session cookie that downstream services treat as MFA-complete. The flaw lives between steps two and three.

The session ticket issued in step one is a server-side record keyed by an opaque identifier. The record holds the username, a credential-validated boolean, a creation timestamp, and a nonce. When the client submits a TOTP code at step two, the server retrieves the record by ticket ID, validates the code against the seed associated with the username in the record, and on success flips an mfa-validated boolean. So far the logic is correct.

The defect is in step three. The cookie-issuance handler accepts the ticket ID and a target username parameter. It checks that the ticket’s mfa-validated boolean is set. It does not check that the target username matches the username in the ticket. The signed cookie is issued for the target username, derived from a ticket that authenticated a completely different account. The cryptographic signature is valid. The session is treated as MFA-complete by every downstream service.

The exploit path is direct. Attacker controls account A - a low-value account they own, with a valid OTP seed. Attacker runs steps one and two against account A, producing a ticket with mfa-validated set. Attacker submits step three with their own ticket and the username of target account B. The broker returns a signed session cookie for account B. The cookie passes every downstream check because the signature is valid and the mfa-validated bit is set. The fact that the validation happened against a different account never surfaces in the issued artefact.

The exploitation surface is every account on the broker. The attack requires no knowledge of the target’s password, no access to their OTP seed, no phishing, no AiTM proxy. MITRE T1556, modify authentication process - sub-technique covering authentication bypass through logic flaws. Adjacent to T1078, valid accounts, but the access path is forgery rather than credential reuse. No T1557 AiTM infrastructure, no Evilginx-class reverse proxy, no Tycoon-style session capture. The cost per compromised account approaches the cost of one HTTP request.

The AI-discovery angle matters because of how the bug surfaced. Multi-step authentication state machines are a known soft target for state-confusion bugs. The combinatorics of valid transitions across multiple endpoints with overlapping parameter sets are exactly the space symbolic exploration handles well. An LLM agent given the broker’s published API surface and a fuzzing harness can enumerate sequences - submit step three before step two, submit step three with a ticket from a prior session, submit step three with mismatched parameters, submit step three with a target username that does not exist, submit step three with a username from a different tenant. Each combination produces a response. The bug is the response that should not have come back with a 200.

The agent’s contribution is not novel reasoning. The contribution is exhaustive enumeration without fatigue and without the bias a human researcher carries about which transitions are interesting. Human auditors triage. They skip combinations that look unproductive. An LLM agent driven by a reward signal tied to anomalous server responses does not triage. It runs every transition. The bug existed for an unconfirmed period - likely years, based on the code path’s age in the public repository. The agent found it in a measured run of hours.

Weaponisation followed a financially-motivated cluster running credential-stuffing operations who pivoted from low-value account takeover to high-value account takeover by abusing the bypass against accounts already enumerated in their target lists. The attacker workflow is mechanical. Stuff a low-value account they hold credentials for. Complete legitimate MFA against that account. Capture the post-step-two ticket. Issue step three calls iterating through the target username list. Each call produces a valid session cookie for a different account. The iteration loop runs as fast as the broker’s rate limiter permits, which in most deployments is several orders of magnitude above the volume needed to clear a target list.

Detection is hard. The bypass produces no malformed requests, no protocol violations, no signature-class IOCs. The signed cookies are cryptographically valid. The mfa-validated bit is set. Downstream applications see a normal authenticated session. SIEM correlation against the broker’s authentication logs is the only detection surface, and the signal lives in a relationship that most rule sets do not model - the username that completed step two does not match the username that received the cookie at step three. If the broker logs both events with their respective usernames and a shared correlation ID, the join is a single SPL or KQL statement. If the broker only logs the cookie issuance event with the final username, the signal is invisible.

In Okta-class deployments, the relevant events are user.authentication.auth_via_mfa for step two and user.session.start or user.authentication.sso for step three. The detection is a correlation on session or transaction ID where actor.alternateId differs between the two events within a short window. False positive rate is near zero in legitimate use because the username does not change mid-flow. In Azure AD audit logs, the equivalent is the relationship between the MFA-satisfied authentication context and the issued token’s upn claim. The Sign-in logs carry the authentication detail; the audit logs carry the token issuance. Joining them on correlationId surfaces the same anomaly. In Ping or ForgeRock deployments, the journey or authentication tree logs carry per-node usernames and the final session creation event carries the bound subject - the mismatch detection is the same pattern.

EDR is blind to this entirely. The exploitation happens at the IdP, not at the endpoint. No process creation, no LSASS access, no Sysmon Event ID 10, no anomalous DLL loads, no token manipulation visible to ETW. Network telemetry shows nothing actionable. The TLS-terminated HTTP exchange to the broker looks like normal authentication traffic. Volume anomalies are possible if a single source IP issues thousands of step-three requests for different usernames in a short window, but rate limiting at the IdP is the control that catches that, not network IDS. The bypass against a single high-value account from a residential proxy looks like a successful login from that residential proxy.

The second-order detection is on the downstream service. A session cookie that authenticates as account B but originated from a session whose initial credential exchange targeted account A will, if any device or risk signals were captured during step one, carry artefacts that do not match account B’s normal profile. Device fingerprint, source IP geolocation, user agent - these were captured during account A’s flow and bound, in some implementations, to the issued cookie. Risk-based authentication rules that compare the cookie’s bound device against the target user’s known devices will flag the session. Deployments without risk-based session evaluation will not.

Patch boundary is the broker version that adds the cross-field validation in the step-three handler - the check that the ticket’s username matches the target username, with hard failure on mismatch. The fix is a single conditional. The residual exposure is every account that authenticated against the broker between the bug’s introduction and patch deployment, because any session cookie issued in that window cannot be retroactively verified as legitimate. Forced re-authentication of all active sessions and revocation of all refresh tokens are the only controls that close the window. Most deployments will not do this because of the operational cost. The bypass cookies have lifetimes measured in hours to days depending on configuration.

The longer residual issue is the discovery model. The bug class is old - cross-field validation gaps in multi-step authentication state machines have produced CVEs against IdPs, SSO providers, and OAuth implementations for over a decade. The discovery economics are new. Every multi-step authentication state machine in every broker is now a candidate for the same enumeration, and the cost of running the enumeration is bounded by inference compute rather than researcher hours. Deployments that treat their authentication flow as audited because it has been in production for a decade are working from an outdated assumption. The audit was performed against a threat model where discovery cost was high. That threat model no longer holds.