Agentic AI testing exposed pre-auth sql injection in auth flows

At a glance

What this is: FireCompass found pre-auth SQL injection in both login and password-reset flows, caused by one shared query path that turned user input into database-executable SQL.

Why it matters: For IAM and application security teams, the lesson is that secondary authentication-adjacent flows can inherit the same exposure as primary login, so code review and testing scope must cover both.

Context

Authentication and account-recovery flows are high-value attack surfaces because they sit in front of trust establishment and often touch sensitive data paths before any session is created. When user input is concatenated into SQL, those public forms can become direct database query interfaces instead of controlled authentication checks. That risk applies to primary login and to secondary flows such as password reset when both share the same backend logic.

The identity connection is straightforward: pre-authentication flows determine who can reach downstream systems, and a flaw in those flows can expose the broader identity boundary rather than just one page. In practice, the control gap is not only injection resistance but also review coverage across all authentication-adjacent paths, which is where many teams are least consistent.

Key questions

Q: What breaks when login and password-reset flows share the same query logic?

A: A single input-handling defect can create multiple pre-authentication injection points, which means one vulnerable function can expose both login and recovery paths. That widens the attack surface because the attacker only needs one reachable form field to influence backend SQL. Shared logic without parameterization is a multiplier, not an efficiency gain.

Q: Why does pre-auth SQL injection in authentication flows create such high risk?

A: Because the attacker needs no account or session, the bug sits before identity is established and can expose query results, schema details, or table counts. That turns a trust-establishing control into a direct data access primitive.

Q: How do security teams know whether authentication-related injection testing is complete?

A: Coverage is complete only when login, reset, recovery, and any other public flow that shares backend logic have all been tested with the same injection cases. If one path was validated and another was only assumed to be equivalent, the review is incomplete.

Q: What should teams do when a public form can influence database errors before login?

A: Treat it as a client-facing disclosure issue as well as an injection issue, because verbose database errors can confirm exploitability and leak structural detail. The immediate goal is to remove error reflection, parameterize the query, and restrict database privileges.

Technical breakdown

How a shared query path turns two forms into one exploit surface

When login and password-reset flows reuse the same backend query-construction logic, a single unsafe string concatenation defect can affect both entry points. The attacker does not need a valid session because the vulnerable code executes before authentication completes. In SQL injection, the application treats user input as query syntax rather than data, so the database executes attacker-shaped statements. Shared code paths make the blast radius larger because patching one front-end form does nothing if the same backend function still serves another flow.

Practical implication: Treat shared authentication handlers as one control surface and test every pre-auth path that reaches the same SQL-building code.

Why error-based injection is useful for proving database reachability

Error-based SQL injection works when malformed input causes the database to return a verbose error that reveals evaluated expressions or schema details. That matters because the attacker can confirm control over the query structure without dumping records or needing privileged access. In this case, the ability to extract scalar values and a row count showed that the injection reached the database layer and could query sensitive tables. A safe proof of concept can demonstrate exposure while limiting harm, which is important for responsible testing.

Practical implication: Suppress detailed database errors at the client boundary and validate that no pre-auth path can return query-derived error content.

Why authentication flows need the same testing depth as the primary login page

Teams often spend the most attention on the obvious login form and less on reset, recovery, and other adjacent flows. That creates a governance blind spot: the application may appear hardened at the front door while a secondary path reuses the same vulnerable code. The technical issue is not the business function itself, but the common implementation pattern underneath it. If one shared backend routine powers multiple public forms, security testing has to treat each of them as equivalent from an attacker's perspective.

Practical implication: Extend secure code review, dynamic testing, and regression tests to every public flow that shares authentication logic.

Threat narrative

Attacker objective: To turn unauthenticated authentication traffic into controlled database read access and confirm reachability of sensitive tables.

1. Entry occurs through a public login or password-reset form that accepts attacker-controlled input before authentication.
2. The attacker manipulates the username parameter to influence the backend SQL query and trigger error-based feedback.
3. The database executes the shaped query and reveals scalar values or table counts, confirming read access to authentication-relevant data.
4. Impact is pre-authentication database exposure across more than one public flow because the same vulnerable code path is reused.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared auth logic is a control boundary, not an implementation detail: when login and password-reset flows share query construction, the security model collapses from two reviewed surfaces into one exploitable code path. That is why pre-auth testing has to track backend reuse, not just visible page labels. The governance conclusion is simple: a secondary flow can be the primary failure point if the same unsafe routine powers both. Practitioners should classify shared authentication code as a high-risk trust boundary.

Pre-authentication injection is a boundary failure, not just a coding bug: the dangerous property here is that the attacker does not need an account, a session, or any prior trust relationship. Once public input reaches SQL syntax, the application has already lost the separation between identity negotiation and data access. That means security reviews must verify that authentication inputs are parameterized end to end, including recovery and reset functions. Teams should measure whether any pre-auth path can influence query structure.

Authentication-adjacent flows deserve identity governance attention: the identity control problem is not limited to credentials and sessions. Password reset is part of the identity lifecycle, and if it reuses login logic unsafely, it can expose the same database estate that supports account verification and recovery. That widens the blast radius beyond the UI and into the backend system of record. Security leaders should treat account-recovery paths as part of the identity control plane.

Pre-auth SQL injection is a named pattern worth tracking as a distinct governance concept: it describes public flows that are expected to gate trust but instead expose database semantics before identity is established. That pattern creates false assurance because teams often overestimate the scrutiny applied to visible login paths and underestimate code reuse in adjacent flows. The practical takeaway is to govern shared query builders as critical authentication infrastructure, not ordinary application glue. Practitioners should make this pattern a recurring review item in application security programmes.

What this signals

Shared authentication code is where review gaps become exploit gaps: when public login and recovery paths reuse the same query builder, the control boundary is the backend function, not the page name. That means teams need design-level coverage of authentication logic, not isolated testing of the obvious sign-in form.

Pre-auth SQL injection belongs in the same governance conversation as identity lifecycle risk: password reset is part of account recovery and therefore part of the identity control plane. If recovery paths are implemented with the same unsafe data handling as login, the organisation has effectively expanded its attack surface while assuming it was adding resilience.

Teams should expect attacker testing to move beyond the primary login page and into every authentication-adjacent route that shares code. The practical response is to make shared query construction, database error handling, and privilege scope explicit review points in secure development and release gates.

For practitioners

• Parameterize every authentication query path Replace string concatenation with prepared statements or ORM parameter binding in login, password reset, and any other pre-auth flow that touches user input.
• Test shared backend logic across all public forms Run the same injection cases against secondary flows that reuse the login handler, not just the primary sign-in page, so shared defects are exposed before release.
• Suppress database error disclosure Return generic client-facing failures and keep detailed SQL and stack traces server-side only, because error reflection can become the confirmation channel for exploitation.
• Review pre-authentication data reachability Map which tables and database operations the unauthenticated code paths can reach, then remove any access that exceeds the minimum required for identity verification or recovery.
• Apply least-privilege database accounts Scope the application database account to the smallest possible table and operation set so a pre-auth injection cannot read beyond the intended authentication data.

Key takeaways

• A shared SQL query path can turn login and password-reset flows into two pre-authentication injection points.
• The key evidence is database reachability before authentication, which makes a public form a data exposure risk as well as a login risk.
• The most direct preventive control is parameterised query handling across every authentication-adjacent flow, backed by tight database privilege scope.

Key terms

• Pre-Auth SQL Injection: A vulnerability that lets an attacker influence a database query before any login or access check occurs. In exposed applications, this can reveal data, alter application behaviour, or create a path to code execution if the backend responds unsafely to manipulated input.
• Shared Query Path: A backend code route used by more than one feature to build and execute database queries. When shared logic handles both login and recovery flows, one unsafe implementation can create multiple attack points and magnify the impact of a single defect.
• Error-based Injection: An exploitation technique that relies on database error messages to confirm control over a query and reveal information. The attacker uses the application’s own error handling as a side channel to learn about data structures or extract limited values.
• Authentication-adjacent Flow: A public function that supports identity operations such as login, password reset, or account recovery. These flows often sit close to trust establishment and therefore need the same security review depth as the primary sign-in path.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect identity controls to broader application and platform risk.