August 23, 2026

From a Password Reset Form to Unauthenticated Database Access

How a simple password-reset endpoint became a confirmed SQL injection — and what the investigation taught me about methodology, WAFs, and…

By redhunter01

13 min read

How a simple password-reset endpoint became a confirmed SQL injection — and what the investigation taught me about methodology, WAFs, and proving impact

There is a big difference between finding a suspicious SQL injection payload and proving that an application actually executes attacker-controlled SQL.

Finding:

'

isn't enough.

Finding:

' AND 1=1--

isn't necessarily enough either.

A strong SQL injection finding should answer several questions:

  • Is the input actually reaching a SQL query?
  • Can I reliably distinguish TRUE from FALSE?
  • Is the response difference caused by the database?
  • Can I extract a real database-backed value?
  • Is authentication required?
  • What is the actual impact?
  • Can I demonstrate that impact without unnecessarily damaging or accessing sensitive data?
  • Is the asset actually in scope?

This investigation started with a password-reset form and eventually demonstrated unauthenticated database read access against a production Joomla installation.

The most interesting part, however, wasn't the payload.

It was the methodology used to prove what was happening.

1. The Initial Attack Surface

The target was a Joomla-based application running the ChronoForms V4 component.

The interesting endpoint was:

POST /index.php?option=com_chronoforms&chronoform=reset_password&event=submit

The vulnerable parameter was:

email

The endpoint was designed to perform a password-reset lookup based on an email address.

From a security researcher's perspective, password-reset functionality is interesting because it commonly contains database queries involving attacker-controlled identifiers:

email
username
account ID
token

That makes these endpoints worth testing for:

  • SQL injection
  • account enumeration
  • user enumeration
  • authentication bypass
  • parameter pollution
  • rate-limit issues
  • CSRF problems
  • logic flaws

The application required no authentication for the password-reset workflow.

That immediately made any backend injection significantly more interesting.

2. Start With the Data Flow

Before thinking about payloads, I wanted to understand the application's data flow.

Conceptually, the endpoint appeared to perform something similar to:

POST email
     ↓
ChronoForms
     ↓
Password reset handler
     ↓
Database query
     ↓
WHERE email = '<input>'
     ↓
Result

The dangerous pattern is:

"WHERE email = '" + user_input + "'"

instead of:

"WHERE email = ?"

with a bound parameter.

This distinction is fundamental.

If user input is concatenated directly into a SQL statement, the database — not the application — ultimately interprets portions of that input as SQL syntax.

The source report identified the vulnerable flow as the email parameter being incorporated into a WHERE email='<input>' condition.

3. The First Question: Is This Actually SQL Injection?

A common mistake is to immediately jump into complex extraction.

I prefer a progression:

Input reflection
      ↓
Syntax manipulation
      ↓
Boolean behavior
      ↓
Error behavior
      ↓
Database fingerprint
      ↓
Data extraction

Each step increases confidence.

The goal isn't to prove everything at once.

The goal is to eliminate alternative explanations.

4. Building a Boolean Oracle

The most important discovery was a reliable difference between two conditions.

Conceptually, the injected query created a conditional expression:

IF condition is TRUE
    → valid scalar result
    → normal application response
IF condition is FALSE
    → deliberately invalid scalar behavior
    → database error
    → different application response

This gives us a binary oracle:

TRUE  → Response A
FALSE → Response B

That is enough to extract information one bit/character at a time.

The original test established:

Condition     Result
TRUE          HTTP 200
FALSE         HTTP 302

The TRUE response contained the normal "not in the system" behavior, while the FALSE branch produced a redirect caused by the database error.

This was the turning point.

At this point, I no longer had merely a suspicious parameter.

I had a working SQL execution oracle.

5. Why the Oracle Matters

Imagine the database contains:

secret = "8.4.8"

You cannot directly see the value.

But you can ask:

Is the first character "8"?

If:

TRUE → HTTP 200
FALSE → HTTP 302

then the application becomes a communication channel.

You can repeat:

Is character 1 = A?
Is character 1 = B?
Is character 1 = C?
...

Then:

Is character 2 = A?
Is character 2 = B?
...

Eventually:

8.4.8

can be reconstructed.

This is the essence of blind SQL injection.

The application does not directly return the database value.

Instead, it returns a signal that tells us whether our question was true or false.

6. Proving It Was the Database

One of the strongest parts of this investigation was avoiding a premature conclusion.

There was a WAF in front of the application.

That raises an important question:

Could the different responses simply be caused by the WAF?

A weak report might say:

"Payload A gives 200 and payload B gives 302, therefore SQL injection."

A stronger investigation asks:

"What component is actually generating the difference?"

That distinction matters.

7. Separating WAF Behavior From SQL Behavior

The investigation compared two different situations.

A UNION SELECT appearing inside a SQL comment passed through the WAF.

Meanwhile, a live SQL expression containing the same general SQL constructs produced the different application response.

The important observation was that the response differential tracked whether the SQL expression was actually executed — not simply whether certain keywords appeared in the HTTP request.

This provides a useful general methodology:

Request
                │
                ▼
              WAF
                │
                ▼
          Web application
                │
                ▼
            Database

When debugging a suspected injection, determine which layer produced the observable difference.

Possible sources include:

WAF
Reverse proxy
Application validation
Framework exception
Database error
Application redirect

Don't confuse them.

8. Fingerprinting the Database

Once the boolean oracle was stable, the next objective was to extract a harmless piece of information.

A database version is ideal for this purpose.

Why?

Because it proves:

1. SQL is executing
2. attacker-controlled expressions are evaluated
3. database functions can be invoked
4. information can be extracted

without immediately dumping application data.

The investigation tested the first character of the database version.

The result established:

MySQL 8.x

through the SQL injection itself.

This is much stronger evidence than simply identifying MySQL from headers or technology fingerprints.

It is database-backed proof.

9. Why Database Fingerprinting Is Useful

Database fingerprinting helps determine which syntax and functions are available.

Different database engines have different:

  • functions
  • error behavior
  • comments
  • string functions
  • metadata structures
  • syntax
  • conditional expressions

For example:

MySQL
PostgreSQL
SQL Server
Oracle
SQLite

all behave differently.

If your oracle can distinguish:

SUBSTRING(...)

conditions against a database variable, you've moved beyond generic application behavior into actual database interaction.

10. The CSRF Token Was Not a Security Boundary

The endpoint expected a Joomla token.

At first glance, that might appear to prevent arbitrary requests.

But the testing demonstrated that the application accepted a token value without actually enforcing the session-bound CSRF relationship expected from a secure implementation.

This is an important lesson:

The presence of a CSRF token parameter does not mean CSRF protection exists.

A proper CSRF mechanism should validate that the token:

belongs to the expected session
+
is valid
+
has not expired
+
is associated with the intended request

Simply accepting a correctly formatted token is not meaningful protection.

11. Keep the Test Non-Destructive

Another important part of the methodology was avoiding unnecessary side effects.

This was a password-reset endpoint.

A careless test could potentially trigger:

password reset email

for a real user.

That would be undesirable.

Instead, the testing used random non-matching email addresses so that no actual account matched and no password-reset message was dispatched.

This is an excellent general rule:

When testing a vulnerability, choose inputs that prove the vulnerability while minimizing real-world side effects.

For SQL injection, that means preferring:

database version
controlled boolean
harmless metadata

before:

massive data dumps
destructive queries
account modifications

12. From Boolean Oracle to Arbitrary Reads

Once the database version had been extracted character-by-character, the capabilities of the oracle became clear.

The same mechanism could theoretically ask arbitrary questions of reachable database data:

Does this table exist?
Does this row exist?
Is this character "A"?
Is this value longer than 20 characters?
Does this user have administrative privileges?

The database effectively becomes an oracle.

The attacker controls the question.

The HTTP response provides the answer.

Conceptually:

Attacker
   │
   │ "Is condition X true?"
   ▼
Application
   │
   ▼
Database
   │
   │ TRUE / FALSE
   ▼
Application response
   │
   ▼
Attacker

That is why a reliable boolean SQL injection should not be underestimated.

13. Escalating the Proof Carefully

The next stage was to determine whether application-level data could also be reached.

The investigation eventually confirmed that a Joomla administrator credential record could be located and extracted through the SQL oracle.

For a public writeup, I would stop at the fact that:

A Joomla Super User credential record
was successfully extracted from the database.

I would not publish the actual username or password hash.

The original evidence established that the extracted password material was a bcrypt hash and that a privileged Joomla account existed.

That is sufficient to demonstrate a major escalation path without exposing credential material.

14. The Impact Chain

At this point the attack chain looked like:

Unauthenticated attacker
        │
        ▼
Password reset endpoint
        │
        ▼
SQL injection in email parameter
        │
        ▼
Boolean/error oracle
        │
        ▼
Database fingerprinting
        │
        ▼
Character-by-character extraction
        │
        ▼
Application database access
        │
        ▼
Privileged Joomla credential record
        │
        ▼
Potential administrative compromise

The important distinction is between demonstrated impact and theoretical impact.

Demonstrated

Unauthenticated SQL execution
Boolean/error oracle
Database-backed extraction
MySQL version extraction
Joomla credential record extraction

Potential escalation

Recover credential
       ↓
Authenticate as privileged user
       ↓
Access Joomla administrator interface
       ↓
Modify application-controlled content/code
       ↓
Potential server-side compromise

A strong report should clearly label the second category as an escalation path rather than pretending every step was performed.

15. Why the Finding Was High Severity

The core vulnerability was:

Unauthenticated SQL Injection

with:

Database read capability

The source report characterized the immediate impact as unauthenticated boolean/error-based database reads and the possible escalation as administrative compromise.

The key severity factors were:

No authentication

An attacker did not need:

account
session
role
invitation

Production application

The affected endpoint belonged to a live application.

Database access

The vulnerability was not merely a local validation issue.

The attacker could interact with the backend database.

Sensitive application data

The database contained authentication-related records.

Privileged account exposure

A Joomla Super User credential record was successfully recovered.

16. The WAF Lesson

One of my biggest takeaways from this research was:

Never assume that a WAF response means SQL injection is impossible.

A WAF is an additional layer.

It should not be the application's primary defense against injection.

The actual security boundary should be:

Application
      ↓
Parameterized query
      ↓
Database

not:

Application
      ↓
Hope the WAF catches SQL keywords
      ↓
Database

The source investigation specifically demonstrated that the WAF and database-generated behavior could be distinguished.

17. WAF Evasion Is Not the Same as SQL Injection

This is an important distinction.

A researcher might find:

SQL keyword bypasses WAF

and assume:

SQL injection confirmed

That's backwards.

The correct order is:

Can I influence SQL?
        ↓
Can I prove SQL execution?
        ↓
Can I extract a database-backed fact?
        ↓
Does the WAF interfere?

A WAF bypass by itself is usually just a filtering observation.

A working SQL injection is a backend security vulnerability.

18. The Root Cause

The fundamental root cause was unsafe construction of the SQL query.

Conceptually:

WHERE email = '<attacker-controlled input>'

was constructed using string concatenation.

The secure implementation should instead use parameterized queries:

WHERE email = ?

with the email supplied separately as a bound parameter.

The report explicitly identified parameterization as the primary remediation.

19. Why Escaping Alone Isn't the Best Fix

A common reaction to SQL injection is:

"Let's escape the quote."

That's not the ideal solution.

The correct architectural fix is:

Parameterized query
+
Bound parameters

This changes how the database interprets the input.

Instead of:

SQL + user input

the database receives:

SQL statement
+
separate data parameter

The application should never depend on:

blacklists
regexes
keyword filtering
WAF signatures
manual quote escaping

as its primary SQL injection defense.

20. Legacy Components Are High-Value Attack Surfaces

The affected application was using:

Joomla 3.x
ChronoForms V4

and the report identified ChronoForms V4 as end-of-life.

This is another useful bug bounty lesson.

When you fingerprint an application and find:

old CMS
old plugin
old component
EOL framework
abandoned library

don't immediately assume it is vulnerable.

Instead, increase its testing priority.

A useful workflow is:

Technology fingerprint
        ↓
Version identification
        ↓
Known attack surface
        ↓
Interesting endpoints
        ↓
Manual validation

The important word is validation.

Version alone is not a vulnerability.

21. A Repeatable SQL Injection Hunting Methodology

Here's the process I would use when testing a similar endpoint.

Step 1 — Find database-backed parameters

Prioritize parameters such as:

email
username
id
search
sort
filter
order
category
token

Step 2 — Establish a baseline

Record:

HTTP status
response length
response body
redirect location
timing
headers

before injecting anything.

Without a baseline, response differences are difficult to interpret.

Step 3 — Test harmless syntax changes

Look for differences caused by:

quotes
parentheses
boolean expressions

The goal is to understand the parser.

Step 4 — Build TRUE/FALSE controls

You want:

TRUE → predictable response
FALSE → predictable response

Don't move forward until the distinction is reliable.

Step 5 — Repeat the controls

Run the same test multiple times.

Why?

Because response differences can come from:

network instability
rate limiting
load balancing
application randomness
WAF behavior
caching

A real oracle should be repeatable.

22. Step 6 — Determine the Layer Producing the Signal

Ask:

Is the difference generated by:
WAF?
Proxy?
Application?
Framework?
Database?

This is particularly important when a WAF is present.

23. Step 7 — Fingerprint the Database

Use a harmless database fact.

For example:

version

This gives you strong evidence that the SQL engine is evaluating your expression.

24. Step 8 — Extract Minimal Proof

Don't immediately dump:

users
payments
passwords
tokens

Instead prove progressively:

DB version
       ↓
Current database context
       ↓
Known table existence
       ↓
One controlled record

Once impact is established, stop.

25. Step 9 — Map the Impact

Ask:

What database is accessible?
What tables are reachable?
Are credentials present?
Are secrets present?
Are privileged accounts present?
Can data be modified?

But remain within the authorization boundaries of the program.

26. Step 10 — Check Scope Before Investing Too Deeply

This investigation also produced an important lesson that has nothing to do with SQL syntax.

The asset was ultimately determined to be outside the formally defined program scope.

The report was initially closed as Not Applicable for that reason.

Later, the team acknowledged that the finding was valid and reopened/triaged it because the issue was something they wanted investigated.

But there was another complication.

A different report had already triggered remediation that happened to fix this vulnerability as well.

Ultimately, no bounty was awarded, although the report received reputation credit.

That is an extremely valuable bug bounty lesson.

27. Scope Is Part of the Vulnerability-Research Workflow

Before spending hours exploiting a target, verify:

Is the hostname in scope?
Is the exact asset in scope?
Is the endpoint in scope?
Is the third-party infrastructure covered?
Are there special exclusions?

A technically critical vulnerability can still be:

$0 bounty

if the target is outside the program's rules.

This isn't a technical failure.

It's a program-selection failure.

And experienced hunters need to treat scope verification as part of reconnaissance.

28. Another Important Lesson: Valid ≠ Rewarded

This case demonstrates something every bug bounty hunter eventually learns.

There are several independent dimensions:

Technical validity
        ≠
Program eligibility
        ≠
Bounty eligibility
        ≠
Duplicate status
        ≠
Remediation timing

You can have:

Real vulnerability
+
excellent PoC
+
confirmed remediation

and still receive:

$0

because of program rules or prior remediation.

In this case, the program explicitly stated that the issue had been resolved by a different report describing a different vulnerability but triggering the same remediation.

29. The Timing Problem

The report also demonstrates an unfortunate reality of security research.

The researcher reported the SQL injection while remediation from another issue was already underway.

The team later explained that the earlier report had been submitted roughly a month before and that its remediation happened to eliminate this vulnerability too.

The result was essentially:

Friday:
SQLi works
Monday:
SQLi no longer works

This is why researchers should always preserve:

request
response
timestamp
PoC
screenshots
reproduction steps
evidence

when a vulnerability is live.

A vulnerability that disappears before triage can otherwise become difficult to prove.

30. What Made the Report Strong

Even though the bounty outcome was disappointing, the technical report had several strong characteristics.

Clear vulnerable endpoint

POST /index.php?option=com_chronoforms&chronoform=reset_password&event=submit

Clear vulnerable parameter

email

No authentication required

Clearly documented.

Reliable oracle

TRUE → 200
FALSE → 302

Database-backed proof

MySQL version extracted through the injection.

WAF distinction

The investigation demonstrated that the response difference came from SQL execution rather than simply a WAF keyword block.

Non-destructive testing

Random non-matching email addresses prevented unwanted password-reset emails.

Escalation evidence

A privileged Joomla credential record was confirmed without publishing the credential itself in the writeup.

Remediation guidance

The report identified parameterization as the root fix and recommended additional defense-in-depth controls.

31. What I Would Do Differently

There is also a lesson for improving future research.

Check scope earlier

Before deep exploitation:

Asset discovery
      ↓
Scope verification
      ↓
Technology fingerprint
      ↓
Vulnerability research

That saves time and reduces the chance of producing a technically excellent but financially ineligible report.

Preserve evidence immediately

Once a reliable oracle is discovered, capture:

TRUE request/response
FALSE request/response
database extraction proof
timestamps
affected endpoint

Don't wait until after escalation.

Don't over-exploit

Once you have:

Unauthenticated SQLi
+
database read
+
privileged credential record

you have enough to establish serious impact.

There's rarely a need to continue toward:

RCE
data destruction
mass credential dumping

unless the program explicitly permits it and the additional step is necessary.

32. The Mental Model I Recommend

When hunting SQL injection, think in terms of questions, not payloads.

Instead of:

"Which SQLi payload should I try?"

think:

Can my input alter SQL syntax?
        ↓
Can I create a TRUE/FALSE distinction?
        ↓
Can I repeat that distinction reliably?
        ↓
Can I prove the database is answering?
        ↓
Can I extract a harmless database fact?
        ↓
Can I determine the reachable data?
        ↓
What is the minimum evidence needed to prove impact?

That mindset scales much better than memorizing payload lists.

33. The Complete Investigation in One Diagram

┌──────────────────────┐
                    │ Unauthenticated user │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │ Password reset form  │
                    └──────────┬───────────┘
                               │
                               │ email parameter
                               ▼
                    ┌──────────────────────┐
                    │ Unsafe SQL query      │
                    │ string construction   │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │ Boolean/error oracle  │
                    └──────────┬───────────┘
                               │
                    ┌──────────┴───────────┐
                    │                      │
                  TRUE                   FALSE
                    │                      │
                  200                    302
                    │                      │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │ Database confirmed   │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │ MySQL version        │
                    │ extracted            │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │ Database enumeration │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │ Joomla credential    │
                    │ record confirmed     │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │ Potential admin      │
                    │ compromise           │
                    └──────────────────────┘

34. Final Takeaways

The biggest lesson from this vulnerability wasn't a particular SQL payload.

It was the process.

1. Start with the data flow

Understand where the parameter goes.

2. Build a reliable oracle

A repeatable TRUE/FALSE difference can turn a blind injection into a powerful information channel.

3. Identify the source of the response

Don't confuse WAF behavior with database behavior.

4. Prove database execution

Extracting a harmless fact such as the database version is powerful evidence.

5. Escalate progressively

Move from:

SQL execution
→ database fact
→ table existence
→ controlled record
→ impact

rather than immediately dumping everything.

6. Minimize side effects

The best PoC is often the one that proves the most while changing the least.

7. Separate demonstrated impact from theoretical impact

Be precise about what you actually proved.

8. Scope matters

A critical vulnerability on an out-of-scope asset may produce no bounty.

9. Preserve evidence

A vulnerability can disappear during triage. Your evidence needs to survive the fix.

10. Think in questions, not payloads

The best hunters aren't necessarily the people who know the most payloads.

They're the people who know what question to ask the application next.

Final Outcome

The SQL injection was confirmed as a valid, unauthenticated database-access vulnerability and was eventually remediated. The program acknowledged that the research and proof of concept were valid, but the asset was outside the formal scope and the vulnerability was independently fixed through remediation associated with another report. The report therefore received reputation credit but was not eligible for a bounty. Program: NBA Public Bug Bounty

Bounty: $0 — reputation credit awarded.