🧪 Labs › File System
Log Poisoning (LFI → RCE)
Severity: High
Write attacker text into a log the server will later include, and a file read becomes code execution.
What it is
Log poisoning is a classic chain: a local-file-inclusion lets you read files, including server logs — and you can influence what goes into those logs (a request header, a username). Put code into the log, then include the log, and the inclusion executes it.
It upgrades an LFI from 'read files' to 'run code', which is why LFI is rated more dangerous than it first looks.
The ingredients are an inclusion sink that evaluates what it includes, plus any sink you can write into that the server stores verbatim.
How to approach it
- Confirm the file-inclusion read and find a log or file whose contents you can influence.
- Place a marker into that sink and confirm it appears when you include the file.
- Reason about what the inclusion does with the file's contents — is it served, or evaluated?
- Chain the write and the include to turn a read primitive into execution.
Your task
Chain the file-inclusion with a writable server-side sink to move from reading files to running code.
▶ Access the labOpens your hosted RatCTF instance. Work on it directly — there's nothing to submit here; you'll know when you've solved it.
How to prevent it
- Fix the inclusion first — don't build include paths from user input (this is the root cause).
- Don't store unsanitised user input in files the app will later process.
- Run with least privilege and keep logs off any execution path.
More File System labs
- Local File Inclusion (LFI) — A file path built from your input can be walked out of its intended folder.
- Unrestricted File Upload — An upload that trusts the filename or the content type can become code on the server.