PHP2Shell: The Critical PHP Vulnerability

On 21 October a serious security vulnerability affecting vast numbers of websites globally became known and several websites were taken down temporarily as a precaution. Exploitation had, however, already begun: Amazon recorded an exploitation attempt on 17 October, while details were still under embargo, and Cloudflare reported attacks on the morning of 21 October, hours before PHP released its fixes. The UK’s National Cyber Security Centre (NCSC) has urged organisations to consider taking offline any system that cannot be fixed straight away. The vulnerabilities were found by security researchers at Calif, Wiz Research and OpenAI, and Wiz reports that frontier AI models played a significant part in turning a long-standing flaw into a working exploit. As with any vulnerability once known and published, further exploits will be developed very quickly. The danger of not correcting or mitigating the vulnerability is therefore considerably greater than before it was discovered.

The vulnerability, which has become known as PHP2Shell in cybersecurity circles, was reported by the BBC as a vulnerability with the PHP programming language. Strictly speaking, it is a vulnerability in the way that PHP has been implemented, rather than an inherent weakness in the language itself. The flaws lie in the PHP interpreter, and every PHP installation that serves web requests is reported to be affected.

What Is PHP?

PHP is a programming language, or more precisely a scripting language, which runs on web servers. PHP scripts run server-side and are most typically used to generate web pages, in the form of HTML instructions, which are then sent to your browser to be displayed.

PHP is the scripting language that has been used to develop many well-known web applications and content-management systems. WordPress, Joomla and Drupal were all written in PHP. Large platforms such as Wikipedia, MailChimp and Slack were also developed using PHP.

What Sort of Vulnerability Is PHP2Shell?

PHP2Shell actually consists of two related vulnerabilities, CVE-2026-109618 and CVE-2026-109619 as they have officially been designated under the CVE Programme, which is run by the MITRE Corporation. These vulnerabilities could result in unauthenticated remote code execution. This effectively means that remote attackers, operating across the Internet, could exploit this by manipulating web servers into executing suitably coded instructions of their choice. The attackers would not need to have any credentials, hence the term “unauthenticated”. There are two ways in which this remote code execution can be triggered:

One way relates to how out-of-memory (OOM) conditions are handled in PHP implementations. When an OOM condition is triggered, such as through a specially crafted multipart HTTP (web) request, of the kind used for form submissions and file uploads, in which one part carries an excessive number of headers, the PHP service exits the current context and aborts handling of the request. In some contexts, request memory is temporarily reachable before it is fully initialised. If any allocation fails at that point, PHP leaves the request memory in an invalid state after the early exit. The failed allocation need not relate to the invalid memory. The request shutdown procedure may then process it in a way that leads to remote code execution (RCE).

The other way relates to how the internal state of a request can persist after its allocated memory has been freed. The global states of PHP include error, session, object and extension states retained by a process/thread but pointing to memory owned by one request. That state must be reset before the request memory is released. Some input, configuration, session and error handling operations run before normal initialisation of the next request. They inadvertently access stale states not reset by the previous request before initialisation has a chance to replace it, causing a “use after free”. If the layout of the memory can be manipulated, this can produce full remote code execution (RCE).

Either way, once remote code execution is achieved, it affects the actual platform and potentially the operating system (OS), and is not limited to the web application, such as WordPress, that you are running on it.

What Implementations Are Affected?

The PHP platform most obviously affected is the mod_php module running on Apache servers. This module contains a PHP interpreter that executes PHP scripts. Remote code execution has been confirmed against mod_php for both vulnerabilities. It has also been demonstrated against PHP-FPM for the second (stale state) vulnerability, and PHP-FPM is thought to be susceptible to the first. FrankenPHP and LiteSpeed are thought likely to be vulnerable to at least one of the two, though this has not been confirmed, and some security researchers also list php-cgi. All of these run PHP scripts.

PHP is also embedded in other products. Palo Alto Networks has confirmed that all versions of its PAN-OS and Panorama software are affected, and other vendors are still assessing their products.

Remediation

It is important to note that this vulnerability does not depend on the PHP application you are running, whether it is WordPress, Moodle or your own custom-developed PHP application. The vulnerability lies within the PHP interpreter itself and can be triggered by the worker process before your application has even loaded. Therefore, no amount of defensive coding in your PHP scripts will mitigate the vulnerability.

One question administrators and developers alike might ask is whether the vulnerability could be mitigated by changing PHP settings so that PHP scripts cannot pass shell commands to the OS using functions like exec(), shell_exec(), system() and passthru(). While it is good to disable passing OS shell commands if they are not needed, this vulnerability is unlikely to be mitigated by such a measure. As the root of the issue is a memory-corruption bug in PHP’s C engine, any exploit is likely to aim to run binary-level code rather than inject PHP instructions that call OS shell commands. At the time of writing, however, published advisories do not actually confirm whether any exploit would involve execution of injected PHP commands, or execution of binary code at machine or OS level.

One obvious measure that should be taken is to ensure your PHP processes do not run with system administrator or root privileges. They should have only the OS-level permissions and file-access rights that are necessary. It may take longer to establish the minimum necessary privileges, but taking the easy route when installing a PHP platform by giving the PHP services an administrative account will result in far more damage being done by any exploit. The exploit would run remote code with the same privileges and context as the PHP worker process.

The only complete remediation is to update PHP itself to a fixed version: 8.2.35, 8.3.36, 8.4.27 or 8.5.12. These updates are available from the PHP project and through the operating system distributions and other suppliers that package PHP. Updating the web server, such as Apache, will not on its own fix the vulnerability. If you are running a version of an affected PHP platform that is no longer supported, it is obviously wise to update to a supported one. Given the seriousness of the issue, however, the PHP security team has released minimal source-code fixes for the unsupported 7.4, 8.0 and 8.1 versions, and some Linux distributions and long-term support vendors are providing backported fixes.

If you cannot update straight away, PHP’s advisories suggest some interim measures, none of which is a complete fix:

• setting memory_limit to -1 (which removes PHP’s memory cap, so needs care)
• not using the RLIMIT_AS or RLIMIT_DATA resource limits
• disabling session upload progress (session.upload_progress.enabled=0) if it is not needed
• on PHP 8.5, setting fatal_error_backtraces=0
• on PHP-FPM, setting pm.max_requests=1 if performance allows. Cloudflare has also deployed web application firewall (WAF) rules for the known exploit methods.

Fixing PHP2Shell quickly depends on knowing where PHP runs across your estate, including inside appliances such as firewalls, and on having a tested way to patch it. If PHP2Shell has raised questions about either, our Cyber Maturity Assessment looks at your people, process and technology controls to help you be more secure in this evolving landscape.

Sources

• Global Scramble to Fix Critical Cyber-Security Flaws as Many Websites Taken Offline — BBC News
• RCE via OOM Corruption (CVE-2026-109618) — PHP Group security advisory GHSA-w8hw-w9fx-j79w, GitHub
• RCE via Stale Global State (CVE-2026-109619) — PHP Group security advisory GHSA-6wmf-4rv5-p3rp, GitHub
• CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP — Rapid7 Blog
• PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619) — Sansec Forensics Team, Sansec
• PHP2Shell: Critical PHP Vulnerabilities Patched, Update Now! — Mirko Zorz, Help Net Security