Local File Inclusion

Local File Inclusion vulnerabilities occur when an application accepts user-controlled input to specify which file should be loaded or executed, typically through functions like PHP's include(), require(), or fopen(). The attacker manipulates file path parameters—often using directory traversal sequences like ../ or absolute paths—to access files outside the intended directory. For example, a URL parameter ?page=dashboard might be vulnerable if changed to ?page=../../../../etc/passwd.

Modern LFI exploitation extends beyond simple file reading. Attackers leverage PHP wrappers like php://filter to apply encoding filters that bypass content restrictions. The php://filter/convert.base64-encode wrapper allows reading PHP source code without execution, exposing credentials and logic flaws. More sophisticated attacks chain multiple filters together to construct executable PHP code from seemingly harmless character transformations.

Log poisoning escalates LFI to remote code execution by injecting malicious PHP code into log files (access logs, error logs, email logs), then using the LFI vulnerability to include and execute those logs. Attackers can also abuse data wrappers (data://text/plain,<?php system($_GET['cmd']);?>) or expect:// protocol handlers depending on server configuration.

• Source code disclosure — exposing application logic, API keys, database credentials, and proprietary algorithms
• Configuration file access — reading database connection strings, encryption keys, cloud service credentials from config files
• Sensitive data extraction — accessing /etc/passwd, SSH keys, user data files, session tokens
• Remote code execution — through log poisoning, wrapper abuse, or including uploaded files containing malicious code
• Lateral movement preparation — gathering internal network details, service configurations, and authentication mechanisms

The osTicket CVE-2022-22200 vulnerability demonstrated advanced filter chain exploitation where attackers injected a PHP filter chain into a ticket's CSS style attribute. The malicious payload bypassed the htmLawed HTML sanitizer using strategic whitespace, then exploited mPDF's processing of php:// wrappers after URL-decoding. This allowed arbitrary file reading that escalated to RCE through chained filter operations.

phpMyAdmin has experienced multiple LFI vulnerabilities where attackers manipulated theme selection or language file parameters to include arbitrary files, often combining this with session file poisoning to achieve code execution. Content management systems like WordPress plugins frequently expose LFI through template loading mechanisms where developers fail to validate file path inputs properly.

• Eliminate dynamic file inclusion — use routing tables or switch statements mapping IDs to hardcoded file paths instead of concatenating user input
• Strict allowlisting — maintain explicit arrays of permitted files; validate user input against this list, never use input directly in paths
• Disable dangerous PHP wrappers — set allow_url_include=0 and allow_url_fopen=0 in php.ini; disable expect://, phar://, and data:// wrappers
• Implement path canonicalization — resolve paths with realpath(), verify they remain within allowed directories using strpos() checks
• Apply least privilege — run web applications with minimal file system permissions, preventing access to sensitive system files
• Input validation — reject any input containing ../, absolute paths, null bytes, or protocol specifiers