TryHackMe PHP2Shell — Complete Walkthrough

PHP2Shell is a PHP runtime vulnerability chain that can lead to memory disclosure and remote code execution (RCE). Unlike application-level vulnerabilities such as SQL injection, this issue exists in PHP's internal request-processing and memory-management logic.

The room covers two vulnerabilities:

• CVE-2026–109618: Memory disclosure.
• CVE-2026–109619: Remote code execution.

How It Works

PHP's session.upload_progress feature tracks multipart file uploads. PHP can process upload-progress data before executing the application's script.

According to the lab, an out-of-memory condition triggers a bailout using longjmp(). If this interrupts processing while PHP's internal state is inconsistent, a pointer may continue referencing memory that has already been freed.

The attack chain is:

LAb Reconnaissance:

First, I checked the running Docker containers and the PHP version:

php2shell-target is the name of the Docker container running the vulnerable PHP server in your TryHackMe lab.

Then, I checked the web endpoint and its source code:

The application contains only a simple statement that prints OK. This shows that the vulnerability described in the lab is in the PHP runtime, rather than in the application's own code.

Root Cause: Bailout and Dangling Pointer

Before moving to the exploit, I needed to understand a few concepts:

• Bailout: PHP's emergency mechanism for escaping certain fatal conditions.
• Dangling pointer: A pointer that still refers to memory after that memory has been freed.
• Memory disclosure: When an application or process exposes data from its memory.
• ASLR: Address Space Layout Randomization, which makes memory locations harder to predict.
• RCE: Remote code execution, which allows commands to run with the privileges of the affected process.

The room describes session.upload_progress as the feature that provides the attack's entry point. The feature itself is not the vulnerability.

Simple Analogy: The Reused Chair

Imagine a room where User 1 has an assigned chair. User 1 leaves, and the chair is removed, but the seating chart still shows the old chair's location.

Later, User 2 arrives and is assigned the same space. The room has reused the space, but the old seating chart has not been updated.

If someone follows the old chart, they may reach User 2's space while believing it still belongs to User 1.

This is similar to a dangling pointer: the memory has been freed and reused, but an old pointer still refers to its previous address.

In the PHP2Shell lab:

1. Request 1 triggers the described out-of-memory bailout.
2. PHP's internal state is left inconsistent.
3. The freed memory may be reused.
4. Request 2 reaches the same worker and encounters the stale state.
5. The exploit attempts to use this condition for memory disclosure and, ultimately, RCE.

The worker process is important because it can handle multiple requests during its lifetime. If corrupted state survives the first request, a later request handled by the same worker may encounter it.

Note: This analogy explains stale memory across requests. A reverse shell is different: it is a command shell that connects back to an operator. A dangling pointer does not automatically create a reverse shell.

Memory Disclosure — CVE-2026–109618

The room describes how a stale session-identifier pointer can be mishandled, causing adjacent process memory to be exposed through the HTTP response header:

Set-Cookie: PHPSESSID

Normally, this header contains a session identifier. In the vulnerability described by the room, PHP allegedly reads beyond the legitimate identifier and exposes additional process memory.

The exploit attempts to recover two addresses:

• Heap chunk base address.
• PHP library (libphp) base address.

These addresses help reduce ASLR's protection because they reveal where relevant memory regions are located.

Remote Code Execution — CVE-2026–109619

The room describes the second stage as corrupting a PHP internal HashTable-related structure. During cleanup, the engine may follow an unintended function pointer instead of the expected cleanup routine.

The exploit uses the previously recovered memory addresses to attempt command execution.

I ran the supplied exploit:

This confirms command execution as www-data, the web server account. From this point, an attacker could potentially execute additional commands through the RCE vulnerability.

Flag:

After confirming command execution, I used the command provided by the room to retrieve the flag:

Detection and Mitigation

Detection: Look for unusually large PHPSESSID cookies, suspicious multipart POST requests, PHP memory errors, and unexpected worker crashes.

Mitigation:

• Update PHP to a verified fixed version.
• Rebuild containers and restart PHP workers.
• If unnecessary, disable upload progress:

session.upload_progress.enabled = 0

session.upload_progress.enabled = 0

For PHP 8.4, the lab lists 8.4.27 as the fixed release. Verify the official security advisory before patching real systems.

Key Takeaway

PHP2Shell shows how a PHP runtime memory flaw can lead to memory disclosure and remote code execution.