PHP2Shell has crossed the line from exploit attempts to a documented compromise. A honeypot running Apache with mod_php on PHP 8.4.26 recorded a full remote code execution chain on 24 October 2026, including a memory leak and the shell command that followed it.

What happened

Two defects in the PHP engine were patched on 21 October after details leaked a day early: CVE-2026-109618 covers corruption triggered when a request exhausts the memory limit, and CVE-2026-109619 covers stale global state left pointing at freed request memory. Both are rated 9.2 under CVSS 4.0 by the PHP Group.

The root cause is how PHP abandons a request on a fatal error. The abort skips cleanup, the worker process keeps serving, and the next request on that worker trusts data that was never finished being built. An anonymous multipart POST is enough to steer it, because PHP parses request bodies before any application code runs.

The 24 October capture, published by Adel Karimi of Perplexity and reviewed by Expel researcher Marcus Hutchins, showed an 800 KiB cookie dump from leaked memory, a function address lifted from that dump, and a shell command executing roughly 1.6 milliseconds after the final byte of the exploit request. Earlier sightings by Amazon, Cloudflare, Patchstack and watchTowr were scanning or non-working exploits.

Who is affected

Anyone serving PHP from an internet-facing host that has not been updated since 21 October.

• PHP 8.2.0 to 8.2.34, 8.3.0 to 8.3.35, 8.4.0 to 8.4.26 and 8.5.0 to 8.5.11 are affected. Fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
• PHP 8.1 and older received source patches only, with no official binaries, so any host still on those branches stays exposed.
• PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed all qualify. The application on top is irrelevant: a page that prints one word is as exploitable as a full CMS.
• VirusTotal counts about 5.1 million PHP hosts reachable online, with roughly 3.8 million exposing at least one port to attack.

What to do now

Upgrade PHP and restart the workers. Installing the package without restarting PHP-FPM or Apache leaves the old, exploitable code running in memory.

• Confirm the running version with a phpinfo page or php -v on the host, not the version the package manager claims is installed.
• Update, then restart php-fpm and the web server, and rebuild container images from patched base images rather than patching inside a running container.
• If you cannot patch today, set session.upload_progress.enabled = 0. It closes the most-used trigger path, not the bug.
• Hunt for compromise: web server users spawning sh, bash, curl or nc, new or modified PHP files in web roots, changed auto_prepend_file settings, and worker crash-respawn bursts in FPM logs.
• Never run a proof-of-concept from GitHub against production. Fake exploit repositories were circulating within hours of disclosure.

What this means for South African businesses

Most South African SMEs do not know which PHP version their website or their client portal runs, because it is decided by a hosting provider or a developer who moved on years ago. That is the real exposure here: the bug needs no login, no plugin and no user action, so an out-of-date shared host is compromised regardless of how well the site itself is maintained. My judgement is that the practical risk for local SMEs is high and the effort to close it is small, which makes this a same-week fix rather than a project.

Source: BleepingComputer.

Also on the blog

• Magento loader: 953 online stores hit, and deleting the script is not a fix
• CVE-2026-110447: web shells planted on Nextcloud through Collabora's CODE app

Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.