Home Library CVE-2026-109618
CVE-2026-109618 High

PHP2Shell, memory corruption in PHP leads to remote code execution

PHP2Shell is the name given to two PHP core bugs disclosed in October 2026: CVE-2026-109618 and its companion CVE-2026-109619. Both are memory-safety flaws in PHP itself (not in a specific application), and both were rated critical because they can be reached by an unauthenticated, remote attacker.

CVSS
9.8 / 10
Vector
Remote
Difficulty
Hard
Added
2026-10-26
01

About this target

PHP2Shell is the name given to two PHP core bugs disclosed in October 2026: CVE-2026-109618 and its companion CVE-2026-109619. Both are memory-safety flaws in PHP itself (not in a specific application), and both were rated critical because they can be reached by an unauthenticated, remote attacker. This lab installs PHP 8.4.26, the last 8.4 build before the fix, as an Apache `mod_php` module.

CVE-2026-109618 is described by the vendor as an out-of-memory handling issue: if PHP runs out of memory while request data is only partially set up, request cleanup can end up trusting that half-built data. Public reporting ties the observed exploitation attempts to the multipart upload-progress code path. CVE-2026-109619 is a related stale-state issue, where request-owned internal state can outlive the memory it pointed to and get reused by a later request handled by the same persistent worker.

This is a good lab target for practicing memory-corruption research against a real, unmodified web stack, for patch/version verification, and for log and WAF-signature review — rather than for an application-layer bug. A flag is dropped at the filesystem root; winning the lab means getting a shell and reading it.

Remote code execution bugs are the ones defenders care about most. This target is useful for testing detection rules and logging.

Product
php
Version
8.4.26
Type
RCE
Severity
High
apache ctf memory-corruption mod_php php php2shell
02

Before you start

This playbook needs the setup from the earlier steps. Check these first.

  • The base VM from Step 01 is built and reachable over SSH.
  • You cloned the playbooks repo and set inventory/hosts.ini in Step 02.
  • A snapshot named clean-base exists, and the machine is booted from it.

One CVE at a time. Don't run this on top of another playbook. Reset first.

03

Run the playbook

Boot the machine from clean-base, then run the playbook for CVE-2026-109618. It installs php 8.4.26, sets up its config and starts the service.

Terminal · host
ansible-playbook cve/cve-2026-109618.yml

A clean run ends with a recap that shows failed=0. If it fails partway, run it again.

04

Verify the target

The verify tag checks that the service is listening and running the version this CVE affects. Run it from the host.

Terminal · host
ansible-playbook cve/cve-2026-109618.yml  --tags verify

You should see target OK.

05

How it was fixed

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive supplier-provided patches.

06

Reset when you're done

Restore clean-base. Nothing from this playbook carries over.

Terminal · host
VBoxManage controlvm thehackingmachine acpipowerbutton
VBoxManage snapshot thehackingmachine restore clean-base
VBoxManage startvm thehackingmachine
07

References

08

Credit

Playbook and write-up by TheHackingMachine Team.

Want to add your own? See how to contribute.