Home
As organizations continue to expose authentication and account-recovery flows directly to the public internet, these flows remain some of the highest-value, least-forgiving attack surfaces on the web. A single unparameterized query can turn a login form into a full database read primitive.
During a recent bug bounty assessment, this finding was surfaced by FireCompass’s Agentic AI Penetration Testing for Web Apps and APIs, the autonomous engagement capability behind FireCompass AI Agent. The agent identified a login and password-reset flow that concatenated user-supplied input directly into a backend SQL query, and validated full exploitability using a safe, non-destructive proof of concept.
The finding included:
- SQL Injection in the primary login flow, through a username parameter passed directly into a backend query.
- SQL Injection in the password-reset flow, through the same shared, unparameterized query-construction code path.
To protect the affected organization, all identifying information, including domains, endpoints, request values, credentials, and screenshots, has been redacted throughout this article.
The Security Assumption That Failed
Authentication flows are usually the most heavily tested part of an application, precisely because they’re the most exposed. That assumption breaks down when a secondary flow, password reset in this case, reuses the same input-handling code path as the primary login form, but wasn’t covered by the same review.
The intended data flow looked like this:
The Shared Query Path Behind Two Features
How one unparameterized query reached two entry points
How FireCompass AI Agent Identified the Issue
The finding did not come from a single scan or signature match. FireCompass AI Agent worked through it in stages, each building on evidence gathered in the last.
Phase 1: API and Authentication Surface Mapping
FireCompass AI Agent’s automated discovery pass mapped the target’s authentication surface, including a secondary asset closely related to the program’s primary scope but not explicitly enumerated in it. Rather than skip it, the agent flagged the ambiguity transparently in its eventual report and proceeded with good-faith testing.
Phase 2: Baseline Behavior
A baseline login request with an ordinary username value returned a normal authentication failure response, establishing what “expected” behavior looked like before any anomalous input was introduced.
Phase 3: Anomaly Detection via Input Fuzzing
The agent then systematically varied the username parameter with characters and structures commonly associated with injection classes. One variant triggered a database error response that reflected attacker-influenced content back to the client, a strong signal of unsanitized query construction rather than a generic validation error.
Phase 4: Confirmed Exploitation
Using a function capable of forcing a descriptive database error (one that embeds the result of an attacker-chosen expression into its own error message), the agent confirmed it could extract arbitrary scalar values from the database, the current database user and version string, purely through the shape of the error response, with no valid authentication required.
The agent then reproduced the same injection point on the password-reset flow, confirming that the vulnerable code path was shared across both features rather than isolated to one.
Phase 5: Impact Validation Without Data Exfiltration
To demonstrate schema-level impact without touching real user records, the agent extracted only a row count from a sensitive table, enough to prove the injection could reach authentication-relevant data, without ever reading or exposing an actual row.
Why This Matters
Credential and Data Exposure: Any table reachable by the database account becomes readable, including tables holding credential material, if authentication data shares a schema with the injectable query.
Pre-Authentication Attack Surface: The vulnerable code path is reachable by anyone, before any authentication step. Every visitor to the login or reset form is a potential attacker vector, not just authenticated users.
Schema and Configuration Disclosure: Database version and structure disclosure gives an attacker the information needed to tailor further, more damaging queries.
Root Cause
The application built its SQL queries by directly concatenating the username parameter into the query string, rather than using parameterized queries or an ORM layer that separates code from data. Because the password-reset flow reused the same query-construction logic as login, the vulnerability existed in two places from a single underlying code defect.
Detection at a Glance: FireCompass’s Agentic AI Penetration Testing for Web Apps and APIs
The five phases above are not a one-off script written for this target. They are the standard, autonomous workflow that FireCompass’s Agentic AI Penetration Testing for Web Apps and APIs runs against every discovered endpoint, authenticated or not, reasoning about behavior rather than matching signatures:
Because the same workflow runs continuously and without a fixed target list, it caught this vulnerability on both the primary login form and the secondary password-reset flow, the two entry points a purely scope-driven, one-time scan would have been least likely to test with equal rigor.
Remediation and Key Lessons for Organizations
| Action | Why it closes this class of bug |
|---|---|
| Use parameterized queries | Replace string concatenation with prepared statements or an ORM’s parameter binding for every code path that touches user input, including secondary and rarely-tested flows like password reset. |
| Apply least privilege to database accounts | Scope the application’s database credentials to only the tables and operations that specific service actually needs. |
| Suppress verbose database errors | Return generic error messages to clients; log detailed database errors server-side only, so error-based extraction channels don’t exist in the first place. |
| Extend security review to secondary flows | Password reset, account recovery, and other less-visited authentication-adjacent features deserve the same scrutiny as the primary login form, since they frequently share the same underlying code. |
Lessons Learned
This is a well-understood vulnerability class, and that’s exactly the point: decades-old bug classes still reach production when secondary code paths don’t get the same scrutiny as primary ones. The agent’s restraint, proving impact via a row count rather than exfiltrating real data, also reflects a broader principle: demonstrating exploitability doesn’t require maximizing damage.
It also illustrates why this bug class is well suited to an always-on, agentic testing capability rather than a one-time audit: catching it depends on systematically testing every code path that touches user input, not just the ones assumed to be primary.
Conclusion
This assessment shows how autonomous testing can catch classic, high-severity bug classes that persist specifically because they hide in secondary, less-reviewed code paths. Treating every authentication-adjacent flow, not just the primary login form, as security-critical remains one of the highest-leverage fixes an organization can make.
It is also a direct demonstration of what FireCompass’s Agentic AI Penetration Testing for Web Apps and APIs is built to do: reason across a target’s full authentication surface autonomously, rather than testing a single documented entry point in isolation.
Related reading: how FireCompass AI discovered an unauthenticated LLM proxy and system prompt disclosure vulnerability, how to know if your organization is ready for a red team assessment, and the infosec color wheel and the difference between red and blue teams.
