Logslinger Walkthrough — Exploiting Local File Inclusion (LFI) to Retrieve the User Flag

Author: Muhammad Abdullah Saif

Introduction

In this walkthrough, I’ll demonstrate how I solved the Logslinger lab, a deliberately vulnerable PHP application running inside Docker. The challenge focuses on identifying and exploiting a Local File Inclusion (LFI) vulnerability to access sensitive files and ultimately retrieve the user flag.

Disclaimer: This walkthrough is for educational purposes only and should only be used in authorized lab environments.

Lab Setup

The lab was provided as a Docker image (logslinger-amd64.tar.gz).

I imported and started the container using Docker on Ubuntu WSL:

docker load -i logslinger-amd64.tar.gz

docker run -d \
  --name logslinger \
  --platform linux/amd64 \
  -p 127.0.0.1:8080:80 \
  logslinger

After confirming the container was running:

docker ps

I opened:

http://127.0.0.1:8080

The application displayed a simple Logslinger — Internal Log Viewer page.

Step 1 — Initial Enumeration

The homepage immediately hinted that content was loaded through the page parameter:

?page=

This suggested a possible Local File Inclusion (LFI) vulnerability.

Step 2 — Testing for LFI

To verify the vulnerability, I attempted to read /etc/passwd:

http://127.0.0.1:8080/?page=../../../../etc/passwd

The response displayed the contents of /etc/passwd, confirming that user input was being passed directly into PHP's include() function without validation.

At this point, I confirmed that the application was vulnerable to Local File Inclusion.

Step 3 — Reviewing the Source Code

After accessing the Docker container, I inspected the application’s source files:

/var/www/html

The directory contained:

config.php
config.php.bak
index.php
robots.txt
internal-notes/

The vulnerable section inside index.php was:

$page = $_GET['page'];
$ok = @include($page);

There was no input validation, allowing arbitrary file inclusion.

Step 4 — Discovering Sensitive Files

While enumerating the application, I discovered a backup configuration file:

config.php.bak

The backup file contained hardcoded credentials that had been removed from the active configuration:

'user' => 'mccarthy',
'pass' => 'iloveyou2'

This demonstrates a common real-world mistake where outdated backup files expose sensitive information.

Step 5 — Enumerating the System

Next, I searched for interesting files within the container.

Useful commands included:

find /var/www -type f

During enumeration, I discovered the user’s home directory:

/home/mccarthy/

Inside it was:

user.txt

which contained the challenge flag.

Final Flag: 139b04a050771058b117bf8f1a2e054a

Key Lessons

This lab demonstrates several important security concepts:

• Local File Inclusion (LFI)
• Poor input validation
• Information disclosure
• Sensitive backup files
• Credential leakage
• File system enumeration

Mitigation

Developers should prevent these issues by:

• Never passing user input directly into include()
• Whitelisting allowed files
• Removing backup files from production
• Storing secrets in secure vaults
• Applying least-privilege permissions
• Performing regular code reviews

Conclusion

Logslinger is an excellent beginner-friendly lab for understanding how a simple Local File Inclusion vulnerability can expose sensitive application files and lead to further compromise. It highlights the importance of secure coding practices, proper configuration management, and careful handling of backup files.

Thanks for reading!

If you enjoyed this walkthrough, feel free to connect with me on Medium and follow along for more cybersecurity labs, CTF write-ups, and hands-on security learning.