Malware
Local file inclusion
Also called LFI.
Local file inclusion is a flaw where an app includes a file from its own disk based on user input, letting an attacker read files or run code they should not reach.
How it is measured
Test parameters that choose files: `?page=about`, `?template=`, `?lang=`. Try `?page=../../../../etc/passwd` and see if the contents appear. Code review looks for `include`, `require`, or file reads built from request data without a strict allowlist.
Log signs are requests with `../`, `%2e%2e%2f`, or `php://filter` in a query string. Web server logs and a WAF both surface them.
Worked example
A small conference site uses `index.php?view=schedule`, with `include($_GET['view'] . '.php')`. An attacker requests `?view=../../wp-config` and the response is blank, but `?view=php://filter/convert.base64-encode/resource=../wp-config` returns the database password in base64.
The developer replaces the include with a fixed array of allowed view names, rotates the database credentials, and adds a log search for `php://filter`.
How it differs
Local file inclusion pulls in a file already on your server. Remote file inclusion pulls in a file from the attacker's server, which needs `allow_url_include` on and gives direct code execution. LFI still reaches code execution when the attacker can plant text in a log or upload that then gets included, which is how a webshell often follows.
Common errors
Filtering `../` once and missing encoded variants. Appending `.php` and thinking that blocks it. Blacklisting a few paths. Letting uploads be included. Ignoring that the debug page uses the same pattern.
In practice
Never build include paths from request data. Map short names to fixed files in an array. Search your code for `include` and `require` with variables, and check logs for `../` and `php://` in query strings.