Local file inclusion (LFI)

How local file inclusion can lead to a breach

Local file inclusion (LFI) remains a common web vulnerability because many applications dynamically load files based on user input, from templates and images to configuration files and modules. When that input is not properly validated, attackers can manipulate it to access unintended files on the web server.

The impact is often underestimated and waved off as “just a file read”. What starts as simple file access can quickly expose sensitive information such as credentials, API keys, and application logic. From there, attackers can escalate to access backend systems, pivot into cloud services, or chain with other weaknesses to get remote code execution.

A typical attack path is that an attacker reads a .env file or probes system files like /etc/passwd to understand your environment, extracts credentials, and uses that information to access databases or infrastructure. In modern environments, this can extend to environment variables or cloud or API tokens, which opens up the risk of a local file inclusion vulnerability escalating to a broader compromise.

What is local file inclusion (LFI)?

Local file inclusion (LFI) is a web vulnerability where an application uses unsanitized and unvalidated user-controlled input to request and access files. Successful LFI may allow attackers to read arbitrary files on the server, resulting in information disclosure. In some cases, LFI can be chained with other weaknesses to execute malicious code. Note that unlike remote file inclusion (RFI), LFI only accesses files already present on the local system.

How LFI attacks work in real applications

Here’s a high-level overview of how attackers might investigate and exploit local file inclusion vulnerabilities.

The entry point: User-controlled file paths

Many web applications dynamically load files based on parameters passed at runtime. Examples of using such behavior include page or template selection, file download or preview features, image or document display, or modular application components.

A typical vulnerable PHP script that loads a file based on a raw parameter value might look like this:

<?php
$file = $_GET['file'];
include($file);
?>

If input is not restricted, attackers can supply arbitrary paths and manipulate them as described in the next step. Note that user-controlled input may come from many places besides the most obvious form fields, including query parameters, cookies, headers, or values such as the User-Agent header.

A safer approach might be to avoid the direct use of user input by relying on controlled mappings. This example defines an allowlist of page names and corresponding file paths, with only the page name controlled by the user:

<?php
$allowed = ['home' => 'home.php', 'about' => 'about.php'];
$page = $_GET['page'] ?? 'home';

if (array_key_exists($page, $allowed)) {
   include(__DIR__ . '/pages/' . $allowed[$page]);
} else {
   http_response_code(404);
}
?>

While often associated with PHP, similar file access issues can occur in other languages, such as Python (send_file), Node.js (fs.readFile), or Java resource loading when user input is not properly validated.

Exploitation: Attackers manipulate the path

Attackers exploit LFI vulnerabilities using path traversal (aka directory traversal) and related techniques. A simple payload included in a query parameter might look like:

?page=../../../../etc/passwd

Common techniques include:

• Path traversal using sequences such as ../
• Encoded payloads to bypass filtering (for example, %2e%2e%2f)
• Null byte injection (%00) in some older environments (PHP before 5.3.4)
• Abusing PHP wrappers such as php://filter, php://input, or data://

PHP wrappers in particular provide many possibilities. As an example of abusing php://filter, attackers might be able to use the Base64 encoding filter to read the source of a PHP file without executing it:

?file=php://filter/convert.base64-encode/resource=index.php

Other wrappers such as php://input and data:// are more dangerous because they allow attackers to supply file content (not just a path) directly in the request body or URL. This can turn an LFI vulnerability into remote code execution without resorting to techniques such as log poisoning or file uploads, since the application might directly include and execute attacker-controlled input as PHP code.

As with many other attacks, basic sanitization or blocklists might catch some exploits but are never sufficient protection on their own – attackers can bypass them using encoding, truncation tricks, or alternative path representations.

Recon: Sensitive file read and data exposure

Once the path is controlled, attackers can try to retrieve environment-specific sensitive files such as:

• /etc/passwd and other system files on Linux
• Application files under /var/www
• Configuration files containing credentials
• Logs such as /var/log/apache2/access.log or error.log
• Runtime data such as /proc/self/environ that may expose environment variables and secrets

At this stage, attackers gain insight into the application, its dependencies, and its execution environment.

Escalation: Chaining LFI into bigger compromise

Information disclosure is already dangerous enough, but attackers can escalate from just gathering data to using it for other attacks. Common escalation paths include:

• LFI to sensitive data exposure by extracting credentials and secrets
• LFI to cross-site scripting (XSS) by including attacker-controlled HTML or JavaScript
• LFI to remote code execution (RCE) by including a malicious file such as a web shell

Because LFI is restricted to files that are stored locally, more advanced attacks need some way to place an attacker-controlled file on the server. Two common techniques used against PHP applications are:

• Log poisoning by injecting malicious PHP code into web server logs (for example via the User-Agent header) and then including a logfile like /var/log/apache2/access.log
• Abusing file upload functionality by uploading a malicious PHP file and forcing the application to include it

In both cases, the attacker may be able to turn file read access into execution of PHP code on the server.

What attackers look for with LFI

Though sometimes discounted as a low-risk weakness, local file inclusion can expose a wide variety of sensitive resources, including:

• Environment and secrets files: Files such as .env often contain database credentials, API keys, and cloud tokens.
• Framework and application configuration: Configuration files store connection strings, authentication secrets, and internal endpoints.
• Source code and application logic: Access to source code may reveal hidden functionality and additional vulnerabilities.
• Logs and writable files: Logs and upload directories are valuable for chaining attacks, especially in log poisoning scenarios.
• Cloud and container-era targets: Modern environments introduce high-value targets that can provide direct access to cloud infrastructure, such as cloud credential files, container-mounted secrets, and Kubernetes service account tokens.

LFI vs. related vulnerabilities

LFI vs. remote file inclusion (RFI)

In LFI attacks, files are included from the local server. In RFI, the application loads files from an external source, which often enables direct code execution. However, LFI can sometimes be escalated to similar impact.

LFI vs. path traversal

Path traversal allows attackers to access files not intended for user access by manipulating file paths. LFI refers to unsafe file inclusion or access within application logic. The two issues often overlap and share the same root cause – insufficient input validation and improper file handling. Definitions may vary, but in practice, LFI and path traversal often appear together.

Real-world impact of LFI vulnerabilities

LFI vulnerabilities can have serious business consequences, including:

• Exposure of sensitive information
• Compromise of credentials and backend systems
• Unauthorized access to infrastructure
• Full server takeover through chained attacks
• Compliance violations and reputational damage

For example, vulnerabilities in components such as TimThumb allowed attackers to read arbitrary files and execute code, which resulted in widespread website compromises. Similar issues have exposed configuration files and credentials, enabling attackers to pivot into databases and backend services.

How to prevent LFI vulnerabilities

There is no single fix that will prevent all LFI vectors. Apply the following best practices to minimize the risk of successful local file inclusion:

• Avoid dynamic file includes: Do not use user input directly to determine which files to load. Map input values to known resources instead.
• Use allowlists instead of blocklists: Restrict file access using a whitelist (allowlist) of permitted values. Blocklists are ineffective as your sole protection because attackers can usually bypass them eventually.
• Use indirect references: Replace direct filenames with internal identifiers resolved on the server.
• Normalize and validate paths carefully: Canonicalize file paths and enforce directory boundaries. Be aware that encoding, truncation, or mixed path formats can bypass weak validation logic if checks are not applied consistently.
• Restrict file access and permissions: Apply least-privilege principles, separate writable and executable directories, enforce strict file permissions, and use controls such as open_basedir in PHP environments. Isolation mechanisms such as containers or chroot environments can further limit impact if exploitation occurs.
• Patch and update dependencies: Update vulnerable libraries and frameworks. A web application firewall (WAF) can help block common traversal payloads and known attack patterns, but it cannot reliably stop all variants, especially when attackers use encoding, application-specific logic, or wrapper-based techniques.
• Test continuously in the SDLC: Use automated vulnerability scanning combined with penetration testing (manual and agentic) to identify LFI issues in development and production environments.

How to detect LFI vulnerabilities

Confidently detecting a local file inclusion vulnerability requires testing how the application behaves at runtime. For known vulnerable software with reported CVEs, version checks using SCA tools can identify known issues. For custom applications, you need targeted testing of file-handling logic.

Static analysis using SAST tools is a valuable first step but is often insufficient on its own because it cannot reliably determine how user input is resolved into file paths during execution. As part of code review, developers should look for dangerous sinks where user input flows in without proper validation, for example include, require, or file_get_contents in PHP, and similar file access functions in other languages.

Automated vulnerability scanning at runtime is the most reliable way to identify accessible LFI vulnerabilities.

How automated scanners detect LFI

Dynamic application security testing (DAST) tools identify LFI by interacting with running applications. This includes crawling the application to discover inputs, injecting payloads that attempt to read local files, and analyzing responses for evidence of file access.

Advanced tools such as Invicti DAST can use proof-based scanning to confirm exploitability and provide evidence of impact. This reduces false positives and helps security teams focus on real, exploitable vulnerabilities rather than theoretical risks. Learn more about Invicti’s DAST-first approach that prioritizes what attackers can actually exploit, and request a demo to see how it can help you reduce real risk faster – for LFI and thousands of other vulnerabilities.