How I Uncovered an LFI in 15 Seconds: The Tale of a Curious Hacker and an Unprepared Server

👋 Hi there! I’m Shyam — a security researcher with a knack for finding vulnerabilities faster than your coffee gets cold. Today, I’m sharing how I casually stumbled upon a critical Local File Inclusion (LFI) vulnerability on the xyz website. Spoiler alert: Google Dorks were involved. 🔍

Warning: This blog contains scenes of unexpected success, facepalming developers, and a hacker trying not to laugh too hard ☄️

It was a chill Tuesday afternoon, and I was in “hacker mode.” Imagine me sitting at my desk with Kali Linux open on one screen, memes on the other, and a cup of tea. ☕

Feeling curious, I decided to run some Google Dorks to see what popped up. For the uninitiated, Google Dorks are advanced search queries that can reveal interesting (and sometimes vulnerable) endpoints. Think of it as treasure hunting but on Google. 🗺️

One of my favorite Dorks is:

inurl:”download.php?filename=”

Why? Because it often reveals endpoints that dynamically serve files — prime territory for LFI testing. So, I fired up the search, and there it was:

xyz Download Endpoint:
https://www.xyz.com/downloads/download.php?filename=

Seeing that URL was like spotting a big red button labeled “DO NOT PRESS.” Naturally, I pressed it. 😂

Me: “Let’s see if you’re really as innocent as you look, little URL.”
Server: Sweats nervously.

I modified the filename parameter in the URL to

../../../../etc/passwd

Here’s what I sent:

**************************************************************GET /downloads/download.php?filename=../../../../etc/passwd HTTP/1.1Host: www.xyz.com**************************************************************

And within 2 seconds, the server responded with this:

Me: “Wait, what?! It worked?!” 🤯
Server: “Oh no, I shouldn’t have done that…” 😰

At this point, I’m sitting there like:

Did I just unlock the gates to Mordor? 🏰How is this even real?Should I laugh or cry for the server’s security team? 😅

While my brain was celebrating, I imagined the developers:

Manager: “Hey, is that file download feature secure?”Developer: “Yeah, totally. We’ve tested it with all kinds of PDFs!”Manager: “Cool, ship it!” 🚢

For the uninitiated, Local File Inclusion (LFI) is like asking someone for their dog’s photo, and instead, they accidentally give you their browser history. 🐕💻

It happens when a website allows you to load local server files by manipulating input parameters. Why is it dangerous?

You can access sensitive files like /etc/passwd.You might find API keys or passwords.If exploited further, it could lead to full server takeover.

LFI is like leaving your front door open because you think no one will walk in. It’s easy to exploit but just as easy to prevent.

Here’s what should’ve happened:

Input Validation: The server should’ve checked if the filename matched a list of allowed files (e.g., .pdf only).Sanitization: Remove suspicious characters like ../.Error Handling: Instead of handing over sensitive files, return a polite error like, “Sorry, this file doesn’t exist!”

Because no blog about hacking is complete without memes:

The Server Be Like:
“You wanted one file? Here, take the whole system.”

Developers After Reading the Report:
“Wait, people can do that with our endpoint?”

Me Reporting the Bug:
“Your server trusted me. That was your first mistake.”

Discovering this vulnerability wasn’t just about flexing my hacker skills — it was about highlighting the importance of proper input validation. If this vulnerability had fallen into the wrong hands, it could’ve led to serious consequences.

This experience reminded me of two things:

Never underestimate the power of curiosity and a good Google Dork.Always sanitize your inputs, folks!

Have you ever found an LFI this fast? Or do you have a favorite Dork? Let me know in the comments below.