--- title: "File inclusion (LFI / RFI)" description: "LFI and RFI: how PHP file inclusion works, the role of allow_url_include and wrappers, and how to protect a WordPress site." language: "en" locale: "en-US" type: "definition" canonical: "https://www.wp-masquerade.com/glossary/file-inclusion/" published: "2026-10-28T08:00:00+00:00" modified: "2026-10-28T20:06:16+00:00" translations: en-US: "https://www.wp-masquerade.com/glossary/file-inclusion/index.md" fr-FR: "https://www.wp-masquerade.com/fr/definitions/inclusion-de-fichiers/index.md" es-ES: "https://www.wp-masquerade.com/es/glosario/inclusion-de-archivos/index.md" de-DE: "https://www.wp-masquerade.com/de/glossar/dateieinbindung/index.md" it-IT: "https://www.wp-masquerade.com/it/glossario/file-inclusion/index.md" pt-BR: "https://www.wp-masquerade.com/pt/glossario/inclusao-de-arquivos/index.md" nl-NL: "https://www.wp-masquerade.com/nl/woordenlijst/bestandsinclusie/index.md" --- # File inclusion (LFI / RFI) File inclusion is a PHP vulnerability in which an attacker controls the path passed to include or require. With LFI (local file inclusion), they load a file already on the server; with RFI (remote file inclusion), a file hosted elsewhere. It leads to leaked secrets or code execution. In PHP, the `include` and `require` statements (and their `_once` variants) load a file and run the code it contains. They are used everywhere, for example to load a theme template. The danger arises when the file path depends on data sent by the visitor without sufficient validation. MITRE's catalog lists this weakness as CWE-98, with two common names: RFI for remote inclusion, LFI for local inclusion. ## How the attack works Code like this lets the visitor choose which file gets loaded: ``` // Don't do this include( __DIR__ . '/templates/' . $_GET['view'] . '.php' ); ``` - **LFI (Local File Inclusion)**: with `../` sequences, the attacker climbs up the directory tree and gets a file that already exists on the server loaded. At best, they read a file they shouldn't see; if they manage to include a file whose content they control (a log, an uploaded file), they get [remote code execution](https://www.wp-masquerade.com/glossary/remote-code-execution/). - **RFI (Remote File Inclusion)**: the attacker supplies a URL pointing to their own server, and PHP includes their code directly. It is the most direct form, but it requires a setting that is rarely enabled. ![Three-column comparison: LFI (including a file from the server, reading or executing wp-config.php through ../ paths, php://filter and phar:// wrappers, works with the default configuration), RFI (including an http or ftp URL containing the attacker's code, requires allow_url_include to be enabled, a setting off by default and deprecated in PHP 7.4) and defenses (fixed list of allowed files, never a path taken from the request, open_basedir and allow_url_include off, updates)](https://www.wp-masquerade.com/media/2026/10/lfi-rfi-en.webp) *RFI depends on a setting that is off by default; LFI, on the other hand, works on a standard configuration.* ## The role of PHP configuration The PHP documentation is clear about two directives: - `allow_url_include` allows URLs in `include` and `require`. It defaults to `0`, can only be changed in the system configuration (php.ini) and has been deprecated since PHP 7.4.0. It also requires `allow_url_fopen` to be enabled. - `allow_url_fopen` lets PHP open URLs as if they were files; it is enabled by default, because many scripts need it. Disabling RFI doesn't solve everything: PHP wrappers such as `php://filter` can turn some LFI flaws into code execution on a default configuration, and `phar://` was long used to trigger [insecure deserialization](https://www.wp-masquerade.com/glossary/insecure-deserialization/). Our article on the php://filter and phar wrappers covers these techniques in detail. *Video: “Web Hacker Basics 04 (Local and Remote File Inclusion)” (Netsec Explained)* ## How to protect against it The best defense, recommended by MITRE, is to never build a path from received data, but to map fixed values to known files: ``` $views = array( 'list' => 'list.php', 'grid' => 'grid.php' ); $view = isset( $views[ $_GET['view'] ?? '' ] ) ? $views[ $_GET['view'] ] : 'list.php'; include __DIR__ . '/templates/' . $view; ``` - Keep included files outside the web root when possible. - Limit what PHP can read with `open_basedir`: a hijacked include won't be able to leave the allowed directories. Hardening PHP on your hosting explains this setting and its effects. - A [web application firewall](https://www.wp-masquerade.com/glossary/waf/) blocks typical patterns (`../`, `php://`), as an extra layer only. ## For WordPress WordPress core doesn't build its includes from visitor parameters: the risk comes from plugins and themes that load a template, a language file or a module based on a URL or AJAX parameter. The favorite LFI target is `wp-config.php`, which holds the database credentials and the security keys; a sensitive file forgotten in the web root, such as a `.env` file or a backup, is another easy catch, as our article on exposed sensitive files shows. Finally, check that your host keeps `allow_url_include` disabled. ## Related terms - [Remote code execution (RCE)](https://www.wp-masquerade.com/glossary/remote-code-execution/) - [Insecure deserialization](https://www.wp-masquerade.com/glossary/insecure-deserialization/) - [WAF (web application firewall)](https://www.wp-masquerade.com/glossary/waf/) - [Backdoor](https://www.wp-masquerade.com/glossary/backdoor/) ## Sources - [MITRE CWE-98 : PHP Remote File Inclusion](https://cwe.mitre.org/data/definitions/98.html) - [PHP Manual : Filesystem and Streams Configuration Options](https://www.php.net/manual/en/filesystem.configuration.php) - [PHP Manual : Backward Incompatible Changes in PHP 8.0 (Phar)](https://www.php.net/manual/en/migration80.incompatible.php)