Post cover image

May 5, 2026

LFI Automated Scanning: Finding and Fuzzing with ffuf

Using wordlists and fuzzing tools to automate LFI discovery and server file enumeration. Part 6 of the File Inclusion series.

By 0x4rt1st

3 min read

Part 6 of the File Inclusion series. The previous parts covered everything from basic LFI to file upload attacks and log poisoning — all manual techniques. This part is about working smarter when you don't need to go through all of that by hand.

Everything we did in the previous parts was manual. We crafted payloads ourselves, found paths ourselves, figured out what worked through trial and error. And that's important — you need to understand what's happening under the hood, especially when there's a WAF blocking specific characters or a filter stripping parts of your input. In those cases, only understanding the vulnerability lets you work around it.

But in a lot of real scenarios, you hit a page with an LFI and you just want to know quickly — is this actually exploitable? What files can I read? You don't always need to go through every bypass by hand. That's where automation comes in.

Step 1 — Finding Hidden Parameters

Before you can fuzz for LFI payloads, you need to know which parameters to target. The obvious ones show up in forms — you can see them on the page. But sometimes there are parameters in the URL that aren't tied to any visible form, and those tend to be less hardened.

We fuzz for them using ffuf with a parameter names wordlist:

ffuf -w /opt/useful/seclists/Discovery/Web-Content/burp-parameter-names.txt:FUZZ \
-u 'http://IP:PORT/index.php?FUZZ=value' -fs 2287

The -fs 2287 filters out responses of that exact size — that's the default page size when nothing interesting happens. Anything different in size is worth looking at.

This is how you find parameters like language, page, file, path — things that might not be documented anywhere but are sitting there exposed and waiting.

None

Step 2 — Fuzzing LFI Payloads

Once you have a parameter to target, you throw an LFI wordlist at it. The one we used here is LFI-Jhaddix.txt from SecLists — it's a solid all-in-one list that covers directory traversal, encoding bypasses, and common sensitive file paths all at once.

ffuf -w /opt/useful/seclists/Fuzzing/LFI/LFI-Jhaddix.txt:FUZZ \
-u 'http://IP:PORT/index.php?view=FUZZ' -fs 1935
None

Within seconds you can see hits coming back — multiple variations of ../../../../etc/passwd returning 200 responses with the right content size. The tool just confirmed the parameter is vulnerable and handed you working payloads without you having to think about how many ../ to stack.

None

Step 3 — Finding the Webroot

Sometimes you need the absolute path of the server's webroot — for example when you've uploaded a file but can't reach it with relative paths. You can fuzz for it:

ffuf -w /opt/useful/seclists/Discovery/Web-Content/default-web-root-directory-linux.txt:FUZZ \
-u 'http://IP:PORT/index.php?language=../../../../FUZZ/index.php' -fs 2287

If /var/www/html/index.php exists and is readable, you'll get a hit. Now you know exactly where you're working.

Step 4 — Finding Log and Config Files

Same approach works for finding log files and server configs — both of which we needed manually in part 5 for log poisoning. Instead of guessing, you fuzz:

ffuf -w ./LFI-WordList-Linux:FUZZ \
-u 'http://IP:PORT/index.php?language=../../../../FUZZ' -fs 2287

This returns everything readable — /etc/hosts, /etc/apache2/apache2.conf, /etc/apache2/envvars, and a lot more. From the Apache config you can pull the webroot and log path. From envvars you can confirm where APACHE_LOG_DIR actually points.

That's the same information we needed for log poisoning, but now found in 3 seconds instead of guessing.

What About Dedicated LFI Tools?

There are tools built specifically for LFI — LFISuite, LFiFreak, liffy. They automate the whole thing including exploitation, not just detection. The honest truth though is most of them are abandoned, run on Python 2, and are hit or miss on accuracy. Worth knowing they exist, but ffuf with a good wordlist will usually get you further.

The Honest Take on Automation

Automation is fast, but it has a ceiling. It finds the obvious stuff — common paths, known bypasses, files that are typically readable. What it won't find is the weird custom filter that needs a specific nested payload, or the PHP filter chain that only works with a particular encoding. That's why you need the manual knowledge from the previous parts first.

Think of ffuf as a first pass. Run it, see what it finds, then go manual on anything that looks interesting but didn't fully resolve.

Next part — prevention. What developers should actually be doing to fix these vulnerabilities properly.