PHP2Shell-Everything you need to know

Two major flaws existed in PHP which allowed attackers to steal and access user data accounts etc. no sign-in required all. The attacker runs code on the server using a payload that hits the vulnerability. Almost 70% of websites out there run on PHP, and Censys found about roughly 1.58 million internet-facing hosts with identifiable PHP versions were unpatched on October 21.

On October 17,2026: Amazon notices something there where exploitation attempts in their honeypot. The amazon threat intelligence using MadPot, which Amazon describes as its internet-facing network of decoy systems for monitoring malicious activity understood that the attempt was made at that time there was no clear idea if it was PHP2Shell related incidents.

On October 20 details of both flaws leaked online, which accelerated proof-of-concept circulation. Amazon on October 21 stated that multiple PoC exploit where seen, followed by more attempts from anonymized infrastructure.

( Source: https://www.php.net/archive/2026.php#2026-10-20-1)

Shutdowns were reported in a wide list of countries such as Netherlands Finland where the government websites where shut down as precaution and countries like Austria universities and the Burgenland state portal went down.

On October 21, Cloudflare CEO confirmed that thousands of exploit attempts where seen in the 10 hours and it rose to millions within hours of the announcement.

The 2 big flaws where RCE, both are rated 9.2 under CVSS v4.0. Researchers using AI-assisted auditing found this months ago and kept it to themselves and worked with the PHP team to fix this before creating a chaos without a patch.

• CVE-2026-109618 is remote code execution via out-of-memory (OOM) corruption. Handling out-of-memory errors via longjmp() leaves request memory uninitialized because of improper control flow management, which lets attackers reliably reach RCE using OOM triggers.
• CVE-2026-109619 is remote code execution via stale global state. PHP globals retain references to freed request memory, so a later request on the same worker can reuse it.

PHP published fixed releases on 21 October 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 ( Source: https://www.php.net/archive/2026.php#2026-10-20-1).

However, no fixed builds had been reported for older branches such as PHP 7.4, 8.0 and 8.1 as of October 24, so sites still running those versions need to upgrade to a supported branch.

Why is the versions important?

As per studies almost 59% of php using webservers are versions 8.1 and before which will never get official patch. So what they could do is update to latest versions asap.

Understanding the flaws

The attacker doesn't need a login, and the website's own code doesn't have to be buggy, that means that no matter how secure the website is it will still be vulnerable to the flaw if an older version of webserver is used.

LCFR found that there is pre-auth RCE on the following PHP apps as well as arbitrary PHP scripts in some instances on these :

• WordPress 7.1.2
• Drupal 11.4.3
• Joomla 6.1.4
• MediaWiki 1.46.2
• Roundcube 1.7.4
• Magento 2.4.9
• phpMyAdmin 5.2.3
• Nextcloud 35.0.1
• Laravel 13.11
• Symfony 8.1
• WHMCS

The flaws are in the PHP engine, so a plain WordPress or custom PHP site can be exposed through code the site owner never wrote. A single crafted HTTP request to a reachable PHP site is the entry point.

The shared root cause. Both vulnerabilities live in Zend, the engine at the heart of PHP, and share a single root cause: PHP's fatal-error path jumps out of the current call stack with longjmp() without properly unwinding. When PHP hits a fatal error, such as running out of memory, it abandons what it was doing mid-task. If that jump happens while internal data is only half-built, cleanup code can later treat leftover bytes as if they were valid.

When there is a POST request sent to the PHP server it stores the required data in the memory and when the data is no longer required it is cleaned up so that space can be reused for another task. Now what the issue is that there are many users using this and the memory is given for each user according to their request so what PHP server does is it claims the memory before actually adding data.

So the memory is

ALLOCATED → DATA STORED → REMOVED → REUSED

constantly like a cycle.

In this process a bug was found that there is a trick the makes the PHP server to run arbitrary commands on server.

So after the allocated data is set the data stored is an incomplete key hence leading to writing the value of the key in to the memory but not considered as a valid entry because the book keeping sees it as empty, hence by replacing the data.

Now this makes the space non allocated and uses that block of memory to replace it with new data.

This is where the flaw lies the idea here is to manually allocate memory beyond the settings allowed hence triggering the out-of-memory error.

An out-of-memory error can trigger longjmp() interrupting request processing while internal request data is only partially initialized. The failing request's own cleanup routine then reads and branches on those bytes.

But the out-of-memory error is not a big deal if its handled properly it happens all the time but in this case what happened to lead it to RCE was how the PHP book keeping handled the elements.

So once the memory is full PHP abandons the job half way through that led to the memory to be full and this case PHP is actually dealing with an array. It goes through what's initialized in the memory to clean it but the issue is PHP bookkeeping considers elements that's used and considers the array that was gonna be written in the memory as valid at first before it actually fills the memory.

So PHP thinks it has a valid data stored but instead it has previous written data with a missing key. Hence PHP considers it as array and tries to destruct the array. But there is no array but the data that is left behind earlier which is carefully crafted to manipulate the pointer for the destructor to point to a completely different function in the server.

Hence PHP calls a function that allows commands written directly on the server. Hence → RCE

Thank you for reading.

Note: The content for this article is gathered from research from many sources and articles. The goal is to educate the readers.

Resources used for this article do check out :

• Article : calif.io/php2shell/
• You tube : Caleb Writes Code
• You tube : Under the Weights