Attackers use PHP Local File Inclusion to make a PHP application include a local file they choose, often through an unsafe file parameter. If the included file contains attacker-controlled data or uploaded code, the result can be code execution, data exposure or log poisoning. Defenders should block path traversal, avoid dynamic includes, and constrain file access to approved locations.
How PHP Local File Inclusion becomes code execution or data exposure
local file inclusion is dangerous because the application asks PHP to load a file path that the attacker can influence. If that path resolves to a log file, upload, session file, or another writable local file, the attacker can turn an inclusion bug into disclosure, code execution, or poisoning of application state. The main question is not just whether a file is read, but whether the application executes it as PHP.
A local include often starts as a simple parameter manipulation issue, but the impact depends on what lives on disk and whether PHP will interpret the file contents. That is why path traversal, unsafe concatenation, and dynamic include patterns are so frequently involved in real attacks. Once the attacker can steer the include to a sensitive local path, the vulnerability stops being a file-read problem and becomes an execution or exposure problem.
For a broader view of how this pattern fits into web exploitation, the Web Application Attacks Guide covers the same attack family alongside directory traversal, file content injection, and other input-driven web flaws.
How attackers turn inclusion into a payload path
Attackers usually look for an include or template parameter that can be pointed at a local resource they control indirectly. Common targets include access logs, error logs, uploaded files, cached content, and temporary files. If the application writes attacker-supplied text into one of those files and later includes it, the attacker can inject PHP code into the file first, then trigger its execution through the include.
Another common path is to use inclusion as a visibility and probing tool. Even when the file is not executable, the attacker may still use the flaw to read configuration, source code, credentials, or session material stored on the server. That exposure can reveal database settings, application secrets, internal paths, and additional pivot points for follow-on compromise.
This pattern is part of the wider set of weakness patterns described in the CWE Top 25 Guide, especially where path handling, unsafe file access, and sensitive file disclosure are concerned.
Why log poisoning and uploaded files matter so much
Local file inclusion becomes far more serious when the target file is attacker-influenced. Log poisoning works because many web servers record request headers, user agents, or request paths before the application later includes the same file. Uploaded files can also become payload carriers if the application stores them in a web-accessible or includeable location and does not validate content strictly. Session files, debug artifacts, and cache files create similar opportunities when they contain attacker-controlled values.
The attacker does not need every file to be executable. They only need one local file whose contents can be shaped and then included in a way that PHP interprets. That makes file location, write permissions, and content handling inseparable from the vulnerability itself.
The defensive value of that distinction is reflected in the operational controls and detection techniques collected in the MITRE D3FEND Guide, especially around local file access mediation and file content analysis.
Risk and Threat Considerations
Local file inclusion is dangerous because a path-control flaw can expose source code, secrets, or executable content, depending on what the application can reach on disk. The same weakness often doubles as a path to remote code execution when an attacker can poison a writable local file first.
Failure mechanism: The application trusts a user-influenced include path, resolves it to a sensitive local file, and then executes or exposes that file’s contents instead of treating it as inert data.
Impact: Attackers may read configuration and credentials, execute arbitrary PHP, poison logs or session material, and expand access to adjacent systems or data stores.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V13 — Configuration | Includes secure include-path handling and file access restrictions for web apps. |
| V15 — Secure Coding and Architecture | Directly addresses unsafe include logic and path traversal-prone code patterns. | |
| Recommendation — Restrict dynamic file inclusion to an allowlist of approved paths and modules. Eliminate user-controlled include paths and refactor to fixed routing or templates. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Covers code-level weaknesses that enable LFI and related web exploitation paths. |
| Recommendation — Review application code for file-inclusion flaws and remediate unsafe path handling. | ||
| MITRE ATT&CK | T1005 — Data from Local System | LFI often exposes local files, configs, logs, or session data to an attacker. |
| Recommendation — Hunt for local file discovery and exfiltration attempts against sensitive server paths. | ||
Practitioner Guidance
What to verify: Confirm that every include or require statement resolves only to an approved allowlist of local templates or modules, with traversal and wrapper abuse blocked before path resolution. If the path can be influenced after normalization, the control is not reliable.
Decision rule: If the application ever includes a file that a user can cause to be written, treat it as a potential execution path, not just a read path. In that case, review logging, uploads, sessions, and cache directories before assuming the flaw is only about disclosure.
Common mistake: Teams fix the visible parameter but leave the underlying file-handling pattern intact, which means the same issue reappears through another route, such as a different include target or a different writable directory.
Practitioner takeaway: Local file inclusion is best treated as a file-ownership and execution-boundary problem, the real control objective is to ensure attacker-influenced data never becomes an includable PHP file.