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

At a glance

What this is: FireCompass describes how its AI agent found SQL injection in both a login flow and a password-reset flow that shared the same unparameterized query path.

Why it matters: For IAM and application security teams, the key risk is that authentication-adjacent flows often inherit the same weak input handling and database privilege exposure as the primary login path.

👉 Read FireCompass's analysis of critical SQL injection in login and password reset flows

Context

Authentication and account-recovery flows are often treated as high-scrutiny surfaces, yet they still fail when code reuse makes one defect reachable through multiple entry points. In this case, the core problem is not a novel attack technique, but the persistence of unparameterized queries in pre-authentication paths that should have been tightly controlled from the start.

That creates a direct governance intersection with identity security because login and password reset are part of the trust boundary around human identity, credential validation, and session establishment. When those flows share backend logic, security review must cover the full authentication surface, not just the primary form or the most obvious path.

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 do unparameterized queries in authentication flows create such high risk?

A: Because authentication inputs are reachable before trust has been established. If the application concatenates those inputs into SQL, an attacker can influence database execution without a valid account, and the database account’s privileges define how far the attack can go. The risk is highest when credential or recovery tables are reachable from the same query path.

Q: How can security teams tell whether an auth flow is vulnerable to SQL injection?

A: Look for reflected database errors, inconsistent response behaviour after small input changes, and any code path that builds SQL from user-supplied strings. If login and password reset produce similar backend queries, test both paths with the same negative cases. A single error response is not proof of compromise, but it is a strong indicator of unsafe query construction.

Q: How should teams test password reset and recovery paths during application security reviews?

A: Test them as first-class authentication surfaces, not secondary features. Use the same negative testing, role assumptions, and database access checks that you apply to login, because recovery flows often reuse the same lookup logic and error handling. If the reset path reaches different data or returns different errors, that divergence deserves investigation.

Technical breakdown

How shared query paths create multiple injection points

SQL injection happens when an application concatenates user input into a query string instead of binding parameters separately. If a login form and a password-reset form reuse the same backend query-construction code, one defect can expose two distinct pre-authentication entry points. That matters because the attacker does not need a valid account, only a reachable input field and a database account with enough privilege to execute the resulting query. Parameterization breaks this chain by ensuring user input is treated as data, not executable SQL.

Practical implication: review shared authentication code paths together, not as isolated features, and eliminate string concatenation in every query builder that touches identity input.

Why error-based validation increases exploit confidence

In many injection cases, attackers start with behavior testing, then use database error responses to prove they can influence query execution. Error-based validation is useful because it confirms more than malformed input handling: it shows the backend is parsing attacker-controlled SQL fragments. Once that is established, the attacker can often infer database type, query structure, and available functions. Even when the test is non-destructive, the signal is strong enough to justify immediate remediation, because the same condition can support data extraction or authentication bypass attempts.

Practical implication: suppress verbose database errors at the client boundary and treat any reflected database error in authentication flows as a security defect, not a usability issue.

Why secondary auth flows are part of the same attack surface

Password-reset and account-recovery features are frequently built later, tested less often, and wired to the same user lookup logic as login. That makes them attractive to attackers because they inherit trust assumptions from the primary authentication flow while often receiving weaker review. From a control perspective, the risk is architectural, not cosmetic: if the secondary flow shares query logic, privilege scope, and error handling, it inherits the same exposure profile. Secure design requires the same standard of input validation, database scoping, and review rigor across both paths.

Practical implication: include password reset, recovery, and other identity-adjacent flows in the same test plan as login, with explicit coverage for shared code, error handling, and database permissions.

Threat narrative

Attacker objective: The attacker aims to turn pre-authentication input into arbitrary database read access through the authentication surface.

1. Entry occurred through a public login or password-reset form that accepted attacker-controlled input before authentication.
2. Escalation came from shared query construction that let the attacker influence backend SQL and validate exploitability through database error responses.
3. Impact was limited in the proof of concept to safe schema confirmation, but the same pattern could expose sensitive tables reachable by the application database account.

NHI Mgmt Group analysis

Pre-authentication identity flows are still one of the weakest governance boundaries in application security. Login and password-reset features sit directly on the trust boundary for human identity, yet teams often review them as separate features rather than a shared access-control surface. When one code path serves both, a single input-handling defect can undermine multiple identity controls at once. Practitioners should treat authentication-adjacent flows as a single governed surface.

Shared query logic is a named control gap, not just a coding mistake. This article illustrates what happens when two identity journeys inherit the same backend data-access pattern without independent verification. The failure is not merely SQL injection, but reuse without isolation, meaning one defect expands across multiple account-access paths. That is a classic example of how application logic can create identity risk even before an account exists.

Least privilege on the database side matters because injection turns application trust into data reach. If the application database account can read credential tables, schema metadata, or other authentication-relevant records, an injection flaw becomes a data exposure event. NIST CSF, NIST 800-53, and OWASP-style secure development guidance all point to reducing blast radius, but the real issue is whether the application can reach more data than the flow requires. Practitioners should narrow that reach now.

Authentication testing needs to extend beyond the login page to the full recovery path. Security programmes that only test the primary form leave a governance blind spot in the very flows attackers target for account takeover and pre-auth exploitation. The right concept here is authentication surface parity, meaning recovery, reset, and login paths receive the same review depth, threat modelling, and negative testing. Teams should make that parity explicit in application security standards.

Autonomous testing changes the economics of finding long-lived bugs, but it does not change the underlying weakness. The value here is coverage across the whole input surface, not magical detection. If a vulnerable code path is shared, a tool that systematically tests multiple entry points will find it faster than a one-time review. Practitioners should use that capability to compress exposure windows, not to excuse weak design.

What this signals

Authentication surface parity is the governance idea this article makes unavoidable. Login, password reset, and recovery paths need the same negative testing, code review depth, and database privilege controls, because attackers do not respect product boundaries. The next step for practitioners is to formalise that parity in secure development standards and tie it to review gates.

For identity programmes, this also reinforces that application security and IAM cannot operate as separate silos. When a web flow can be turned into a database read primitive before authentication, the issue is not only code quality but the trust model around human identity assertions and credential recovery. Teams should align secure coding checks with access-scoping controls and review them together.

For practitioners

• Audit shared authentication code paths Trace every login, password-reset, account-recovery, and username lookup flow back to the exact query builder or ORM method it uses. Look for reused functions that accept user-controlled input and verify that each path uses parameter binding, not string concatenation.
• Remove direct SQL construction from identity flows Replace any query string concatenation in identity-adjacent code with prepared statements or bound parameters, including helper methods that are reused across features. Do not assume the reset flow is safe because the login form was already reviewed.
• Reduce database blast radius Scope the application database account so it can access only the tables and operations each specific identity flow requires. Separate credential, profile, and recovery data where possible so a single injected query cannot reach unrelated authentication records.
• Treat verbose database errors as a defect Return generic client-side errors in authentication paths and move detailed database diagnostics to server-side logs only. Then test whether any error-based response still leaks database type, query structure, or execution details.
• Extend negative testing to recovery paths Run the same injection and boundary tests against password reset and account recovery that you already run against login. Include fuzzing for shared fields, error conditions, and alternate entry points that reuse identity lookup logic.

Key takeaways

• One shared unparameterized query can expose both login and password-reset flows to pre-authentication SQL injection.
• The proof point is not just exploitability, but how quickly database error handling can turn input testing into execution confirmation.
• Reducing blast radius, removing string concatenation, and reviewing recovery paths with login-level scrutiny are the controls that matter most.

Key terms

• SQL Injection: SQL injection is a flaw where untrusted input is interpreted as part of a database query. In practice, it lets an attacker read, change, or delete data by manipulating the application’s request handling rather than by logging in with valid credentials.
• Parameterized Query: A parameterized query separates SQL code from user-supplied values so the database can bind data without treating it as executable logic. This is the primary technical control that prevents input from changing query structure in vulnerable application paths.
• Authentication Surface: The total set of paths, factors, exceptions, and recovery steps that can be used to prove identity. In a passwordless programme, the surface should shrink, but it can expand again if legacy applications, help desk workflows, or exception handling still rely on reusable secrets.
• Data Blast Radius: Data blast radius is the spread of impact that occurs when sensitive information is copied, shared, or restored across too many systems. The wider the blast radius, the harder it is to determine what was exposed, what is authoritative, and what should be recovered first.

What's in the full article

FireCompass's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step reproduction of the login and password-reset injection path, including how the shared query was validated safely.
• The five-phase autonomous testing workflow used to map the authentication surface and confirm exploitability without data exfiltration.
• The remediation table showing why parameterized queries, least-privilege database access, and verbose error suppression each close a different part of the chain.
• Context on how continuous agentic testing differs from a one-time scan when secondary identity flows are easy to miss.

👉 FireCompass's full post covers the shared query path, exploit validation, and remediation guidance in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and identity lifecycle controls. It helps practitioners connect identity risk to the controls that reduce exposure across authentication and recovery paths.