hardMultiple ChoiceObjective-mapped

PT0-002 Practice Question: A penetration tester has discovered a local file…

A penetration tester has discovered a local file inclusion (LFI) vulnerability in a PHP web application. The vulnerable code uses the following pattern: include($_GET['page']);. The application runs on a Linux server with Apache and PHP. The tester wants to achieve remote code execution (RCE). Which technique is most likely to succeed given this LFI?

⚠ Common exam trap

Candidates often assume data:// is the most direct way to inject code, but they overlook that php://input is more reliable because it does not require allow_url_include to be enabled, which is a common security hardening measure.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use the php://input wrapper and send PHP code in the POST body.

The correct technique is to use the php://input wrapper because it allows the attacker to pass arbitrary PHP code in the HTTP POST body, which the include() function will execute as PHP. Since the vulnerable code directly includes user input without sanitization, the php://input stream reads the raw POST data and processes it as a PHP script, achieving remote code execution.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Use the php://input wrapper and send PHP code in the POST body.
Why this is correct
php://input reads the raw POST data. When included, the PHP interpreter will execute any code contained in the POST body. This is a common technique to turn LFI into RCE, and it does not require allow_url_include to be enabled.
✗
Use the file:// wrapper to read sensitive files like /etc/passwd.
Why it's wrong here
Using file:// to include local files such as /etc/passwd performs read-only disclosure: the file's contents are output in the response, but they are not interpreted as PHP code, so no code execution takes place. While useful for information gathering, this technique cannot turn an LFI into RCE because you cannot inject PHP payloads into arbitrary local files. It is not blocked by allow_url_include, but its impact is limited to file reads, not command execution.
✗
Use the data:// wrapper with a base64-encoded PHP payload.
Why it's wrong here
The data:// wrapper allows inline data inclusion (e.g., data://text/plain;base64,PD9waHA...), but PHP treats it as a remote URL for include/require, so it works only when allow_url_include is enabled. This option defaults to Off in modern PHP and is frequently disabled in hardened environments, making the attack unreliable. Even when functional, the payload must be carefully base64-encoded to avoid URL corruption, unlike php://input which reads the raw POST body regardless of allow_url_include.
✗
Set allow_url_include to On in php.ini via the LFI.
Why it's wrong here
Attempting to set allow_url_include to On through the LFI is impossible because the vulnerability only abuses include() and provides no file-write primitive or access to modify php.ini. This directive is classified as PHP_INI_SYSTEM, meaning it cannot be changed at runtime via ini_set() or per-directory .htaccess files; a server-level configuration change with administrative privileges and a restart would be required. Without a separate write vulnerability or admin control, this approach cannot succeed.

Go deeper

PT0-002 Practice Question: A penetration tester has discovered a local file…

Why each option matters

Option-by-option breakdown

Related to this question