SQL Injection in 2026? Yes. And It Took One Apostrophe.

Hi guys, it’s been a while since my last write-up.

Today I wanted to share a simple yet interesting finding something everyone knows about, but somehow not everyone and definitely not every time manages to spot. Funny how that works.

You don’t need a dark room.
You don’t need three monitors.

Sometimes, all you need is this:

'

One tiny apostrophe.

Let me show you how I found a Critical SQL Injection in a staging environment using basic testing logic and two tools that practically do the heavy lifting for you.

Target:

https://redacted.com/

Grab your coffee. Or protein shake. Whatever fuels your chaos.

Step 1: Identify Interesting Endpoints

While browsing the application as an User, I found this endpoint:

/deleteCompanyModules

The request contained this parameter:

companyID=

Now, any time I see:

• userId
• companyID=
• id
• accountId

My brain immediately whispers:
“Database interaction happening here.”

And where there’s database interaction… there might be SQL injection.

Step 2: Intercept the Request

I intercepted the request using Burp Suite.

Right-click → Send to Repeater.

I focused on the companyID= parameter because anything that references a user record usually talks directly to the database.

Originally it looked like this:

companyID="Default-GP"

modified it to:

companyID=Test'

Just add an apostrophe.

Step 3: Watch the Application Panic

If the application had been secure, nothing unusual would have happened.

Instead, it broke.

The server returned a detailed SQL error message.

At that moment, I knew three things:

• The input was not sanitized
• The query was being constructed dynamically
• Database errors were exposed to the user

When an application throws raw SQL errors back at me, it’s basically confirming that my input is being injected directly into a query.

That’s not just a bug.
That’s an opening.

Step 4: Confirm with SQLMap

Manual testing gave me confidence, but I needed proof.

1. Saving the Request

I copied the vulnerable HTTP request into a file named:

sql.txt

Then I marked the injection point using *:

companyID=*

SQLMap uses * to identify exactly where it should inject payloads.

2. Enumerate Databases

sqlmap -l sql.txt --level=5 --risk=3 --dbs --batch

The databases were successfully enumerated.

That confirmed the injection.

3. Enumerate Tables

sqlmap -l sql.txt --level=5 --risk=3 -D accordiqclientdb --tables --batch

Now I could see the tables inside the database.

At this stage, the vulnerability was clearly exploitable.

4. Dumping Data

sqlmap -l sql.txt --level=5 --risk=3 -D accordiqclientdb -T groups --dump-all --batch

Data extraction worked.

At that point, it was complete compromise.

No bypass tricks. No complex chaining. Just improper input handling.

Game over.

Bonus: It Wasn’t Alone

The same SQL injection existed in:

/addCompanyPermissions   → fundId
/deleteUser              → userId

When one endpoint is injectable, there are usually friends.

SQL injection travels in packs.

How This Could Have Been Prevented

This vulnerability could have been avoided with basic secure coding practices:

• Use parameterized queries (Prepared Statements)
• Validate and whitelist input
• Disable verbose SQL error messages
• Never concatenate user input directly into SQL queries

SQL injection has existed for decades.

If a single apostrophe can still break an application in 2026, the attacker isn’t sophisticated.

The input handling is simply careless.

And that’s how I confirmed a Critical SQL Injection vulnerability using nothing more than logic, patience, and one character.