What is Remote File Inclusion?

Remote file inclusion (RFI) occurs when an application loads an attacker-selected external resource as code, a template or configuration component. If the attacker controls the remote content and the server interprets it, direct code execution in the application's context is often possible.

How does RFI work?

An application may use a request parameter as an include name. If the runtime accepts https://attacker.example/payload or a network path instead of a local name, the server retrieves and processes that resource. RFI is especially associated with older PHP applications and unsafe URL-include configuration. The design flaw is language-independent, however: an untrusted party determines which executable or trusted content the server imports.

What prerequisites does an attack need?

• Request data can influence file selection or the import source.
• The function and runtime permit remote schemes or network paths.
• The application server can reach the remote host over DNS and the network.
• Loaded content is interpreted in a dangerous context rather than handled only as data.
• Allowlists, signature validation or other trust checks are absent or bypassable.

When one prerequisite is absent, the same parameter may still cause another weakness, such as information disclosure, local file inclusion or a server-side request.

What impact is possible?

Successful RFI often results in remote code execution. Attackers read secrets, alter data, establish persistence or attack further systems with the application process's rights. If content is retrieved but not executed, internal responses, cache manipulation or availability issues may result. Egress filtering and low process privileges contain impact but do not replace safe selection.

RFI, LFI or SSRF?

How is RFI prevented?

1. Select templates and executable modules only through fixed internal identifiers and a server-side allowlist.
2. Disable remote includes, URL-aware file wrappers and dynamic loading when not essential.
3. Obtain required extensions as signed, versioned artifacts through a controlled deployment process.
4. Restrict service egress to necessary destinations, accounting for redirects and DNS resolution.
5. Run the application with minimal privileges, read-only code and separated secrets.

Code example: do not permit remote include targets

Vulnerable:

include $_GET['template'];

Safer:

$templates = [
    'invoice' => __DIR__ . '/templates/invoice.php',
    'receipt' => __DIR__ . '/templates/receipt.php',
];

$name = $_GET['template'] ?? '';
if (!isset($templates[$name])) {
    http_response_code(404);
    exit;
}

include $templates[$name];

For PHP, disable allow_url_include and restrict outbound network access from the web process. This hardening complements the fixed mapping but does not replace it.

How is RFI tested?

Testers identify dynamic include, plugin, template and import parameters. A controlled external resource returns a unique harmless marker, while DNS or HTTP logs prove whether the server retrieves it. Code execution is tested only with explicit approval and a non-destructive proof. Schemes, redirects, alternative host representations and local paths are examined to distinguish RFI from SSRF and LFI.