Post cover image

June 11, 2026

Everything Looked Normal Until I Decoded It — A Hidden SQL Injection

Hello everyone,

Unvalidor

5 min read

My name is Matin, also known as unvalidor.

For the past three years, I have been actively studying and working in penetration testing and bug bounty hunting. Like many of you, I've spent countless hours staring at HTTP requests, enumerating subdomains, reading writeups, and searching for things that were never meant to be found.

Today, I'd like to share the story of a SQL Injection vulnerability I recently discovered. Not because it was the most sophisticated SQL Injection ever found. Not because it led to Remote Code Execution. And not because it required chaining multiple vulnerabilities together. In fact, it was quite the opposite. This was probably one of the simplest SQL Injection vulnerabilities I've ever found. The kind of bug that makes you stare at your screen for a few minutes and ask yourself: "Was it really that easy?"

What is SQL Injection?

Before diving into the story, let's briefly review what SQL Injection actually is.

SQL Injection is one of the oldest and most dangerous web vulnerabilities. It occurs when user-controlled input is inserted into a database query without proper validation or parameterization.

For example, imagine an application executes the following query:

SELECT * FROM doctors WHERE doctor_id = '$id';

If the value of $id comes directly from user input, an attacker may be able to manipulate the structure of the query and alter its intended behavior.

This can lead to unauthorized data access, authentication bypasses, and in some cases complete compromise of the application's database.

The Beginning

Like many other bug bounty sessions, this one started with me testing the primary domain of the target.

Several hours had already passed.

I had reviewed the login pages, various application panels, and APIs — the usual attack surface that most researchers start with.

Yet nothing stood out.

No interesting errors. No obvious misconfigurations. No suspicious endpoints.

Everything looked surprisingly clean.

And experience has taught me that whenever everything looks too clean, I'm probably not looking in the right place yet.

Changing Direction

Whenever I stop making progress in one area of an application, I usually switch my focus.

Not because I'm tired.

But because sometimes your mind gets locked into a specific path and starts missing obvious things.

So I decided to move on to subdomain enumeration.

I started by gathering subdomains using:

subfinder -d target.com -all | httpx -sc -cl -title

As expected, the command returned a large list of subdomains.

Some were offline.

Some redirected elsewhere.

Others hosted simple pages with little functionality.

I started reviewing them one by one.

Probably one of the most boring parts of bug bounty hunting.

(Although tools such as Gowitness, Aquatone, and screenshot-based workflows can significantly speed up this process.)

Ironically, many great findings come from exactly this stage.

A Suspicious URL

While browsing one of the subdomains through Burp Suite, I opened the Target tab and started reviewing the sitemap.

None

That's when a particular URL caught my attention:

https://sub.target.com/main/X/SzAxODQ5Ndkjeweg==

At first glance, it didn't look unusual.

However, two things immediately stood out.

First, part of the path looked very similar to Base64.

Second, when I opened the page, it displayed profile information belonging to a specific user.

At that point, a simple question came to mind:

What exactly is this value?

Looking at the Base64 Value

For anyone unfamiliar with Base64, it's simply an encoding mechanism.

It is not encryption and provides no security guarantees.

For example:

➜  ~ echo unvalidor | base64
dW52YWxpZG9yCg==
➜  ~ echo dW52YWxpZG9yCg== | base64 -d
unvalidor

Anyone can decode the encoded value and recover the original content.

With that in mind, I decoded the value found in the URL.

None

The result looked something like this:

K56396

Not JSON. Not a token. Not a UUID.

Just a simple identifier.

And that's exactly what I was hoping to see.

Because identifiers often end up being used directly in database queries.

Imagining the Backend Logic

At this point, I had no access to the application's source code.

But I always try to imagine what the developer might have written behind the scenes.

In my mind, the logic probably looked something like this:

$doctor = base64_decode($input);
SELECT * FROM Doctors WHERE doctor = '$doctor';

Of course, this was only a hypothesis.

And hypotheses are worthless until they're tested.

The First Attempt

The first thing I did was modify the original value.

As an initial test, I appended a double quote:

K56396"

I encoded it back into Base64 and sent the request.

None

The application responded normally.

https://sub.target.com/main/X/SzU2MzczIgo=
Response: Normal

No difference. No errors. Nothing interesting.

None

Next, I decided to try something even simpler.

A single quote. Just one character.

K56396'
None

After encoding the modified value and sending the request, the response changed.

https://sub.target.com/main/X/SzU2MzczJwo=
Response: SQL syntax error
None

Now things were getting interesting.

The Moment Everything Changed

There are moments in bug bounty hunting when you immediately realize something isn't right.

This was one of those moments.

The application's behavior had changed.

Enough to indicate that something had broken in the backend.

And that's all I needed.

Because when a single quote changes application behavior, something very interesting is often happening behind the scenes.

None

Final Verification

Now it was time to verify the hypothesis.

I needed to determine whether my input was actually affecting the backend query.

To do this, I performed a simple logical test.

When I supplied a condition that evaluated to true:

https://sub.target.com/main/X/base64_encode(K56396' AND '1'='1)

The application behaved normally.

When I supplied a condition that evaluated to false:

https://sub.target.com/main/X/base64_encode(K56396' AND '1'='2)

The application's behavior changed.

That difference was enough to confirm my suspicion.

At this point, I was confident that I was dealing with a genuine SQL Injection vulnerability.

Additionally, when reviewing one of the database error messages, I could clearly see that my supplied input had been reflected inside the SQL query itself.

That provided even more evidence that the application was directly incorporating user-controlled data into database operations.

Why This Bug Was Found

After submitting the report, I spent a few minutes thinking about the discovery process.

The reality is that nothing particularly advanced was involved.

No fancy scanners.

No complicated payloads.

No magical tools.

Just a few simple questions:

  • What is this value?
  • What happens if I decode it?
  • What happens if I modify it?
  • What happens if I add a quote?

That's it.

Conclusion

This wasn't the most complex vulnerability I've ever discovered. But it was one of the most valuable reminders. A reminder that curiosity is often more important than tooling. Tools can send thousands of requests. They can automate testing. They can help you scale your workflow. But sometimes, a single question can uncover a real vulnerability.

And in this case, everything started with one simple thought:

"What happens if I decode this Base64 value?"

Thank you for taking the time to read this writeup.

I hope you found it useful, and hopefully it serves as a reminder to never overlook simple observations during your testing process.

Wishing you all successful hunting, impactful findings, and many valid reports ahead.

Happy hacking!