php2shell: Two critical unauthenticated remote code execution vulnerabilities in PHP

Summary: On 21 October, the UK National Cyber Security Centre (NCSC) issued a warning about a critical issue affecting PHP. The issue is actually two separate vulnerabilities: one arises when a request is interrupted because memory runs out, the other when state left over from one request is used in the next request in the same worker process. Both can go as far as executing code with the web server's user account, without authentication. PHP released fixes in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 and says the only complete solution is to update. In this article I have collected separately what the official advisories say, where the risks are concentrated, the temporary measures that can be taken if updating cannot be done immediately, and claims that have not yet been verified.

What is php2shell and who does it affect?

Short answer: php2shell is the common name for two critical vulnerabilities in the PHP core (CVE-2026-109618 and CVE-2026-109619). All PHP installations that process web requests are affected; the highest risk is on servers using Apache mod_php. The solution is to update PHP to version 8.2.35, 8.3.36, 8.4.27 or 8.5.12 and restart all PHP workers.

Question	Answer
Vulnerabilities	CVE-2026-109618, CVE-2026-109619
Severity	Critical, CVSS 4.0 score 9.2
Is authentication required?	No
Advisory date	21 October 2026
Fixed versions	8.2.35, 8.3.36, 8.4.27, 8.5.12
Highest-risk installation	Apache `mod_php`
Complete solution	Update; configuration changes only reduce the risk

What happened?

On 20 October the PHP project pre-announced that a critical security release was coming, and on 21 October it released security versions in four branches at once. The same day, the NCSC, the Canadian Centre for Cyber Security and the Dutch NCSC (NCSC-NL) issued warnings. In security circles the two vulnerabilities are referred to together as php2shell. PHP's own advisory does not use this name; NCSC-NL's tracking repository and various security firms do.

The NCSC's warning is kept short and general. It states that any web server running PHP may be at risk and asks organisations to find and update their PHP installations, starting with internet-facing systems. I took the version numbers and technical details from PHP's security advisories on GitHub and from php.net.

What do the two vulnerabilities break?

1. CVE-2026-109618: a request left half-finished when memory runs out

When a request exceeds the memory_limit, PHP interrupts it with longjmp(). If the interruption arrives while some of the request's internal data is still only half-prepared, the request's shutdown phase can read this half-prepared data as if it were valid. The result is memory corruption.

According to PHP's advisory, an attacker can inflate memory usage with multipart/form-data while apparently staying within the limits. Remote code execution over HTTP without authentication, with default settings, on Apache mod_php has been confirmed. The advisory says that, based on source code review, PHP-FPM, FrankenPHP and LiteSpeed may also be affected; however, no full exploit has been demonstrated for FPM.

The fix removes the use of longjmp() entirely when memory runs out. In its place comes a two-stage structure: first a soft limit that stops the request at a safe point, and at a higher threshold a hard limit that terminates the process immediately.

2. CVE-2026-109619: old state carried over to the next request

In installations that run with persistent worker processes such as PHP-FPM or mod_php, the same process serves many requests in succession. Some of PHP's error, session, object and extension states can remain in the worker even after the request's memory has been freed. If the next request accesses this state before normal initialisation resets it, freed memory is reused. This type of bug is called use-after-free in English.

Exploitation requires two steps in the same worker: a request that leaves the state corrupted, and an operation that later reads it. There are two paths confirmed by PHP:

The combination of the fatal_error_backtraces feature in PHP 8.5 with INI warnings emitted before initialisation (confirmed on mod_php).
The session upload progress path (session.upload_progress) corrupted by an out-of-memory condition (confirmed on mod_php and PHP-FPM).

The impact of the vulnerability is leakage of memory contents and code execution with the privileges of the web worker.

3. Severity

	CVE-2026-109618	CVE-2026-109619
English title in the advisory	RCE via OOM corruption	RCE via stale global state
Severity	Critical, CVSS 4.0 score 9.2	Critical, CVSS 4.0 score 9.2
Authentication	Not required	Not required
Attack complexity	High, precondition exists	High, precondition exists
Confirmed environment	Apache `mod_php`	Apache `mod_php`, PHP-FPM

The vector is the same for both: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. The fact that complexity is "high" does not mean the vulnerability cannot be exploited; it shows that successful exploitation depends on build options, extensions and memory layout.

Which versions are affected?

Branch	Affected	Fixed version	Note
8.5	Before 8.5.12	8.5.12
8.4	Before 8.4.27	8.4.27
8.3	Before 8.3.36	8.3.36
8.2	Before 8.2.35	8.2.35	Support ends on 31 December 2026
8.1, 8.0, 7.4	Affected	No official release	PHP published minimal patches only for those compiling from source

All installations that process web requests with PHP are affected: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest in installations using mod_php, because the demonstrated exploit is triggered while the request is being processed, without any application code running at all. In other words, whether the site is WordPress, Laravel or a hand-written application makes no difference on its own.

The fourth release candidate (RC4) of the 8.6.0 version in testing includes the fixes, but it is not for production. Distributions and long-term support vendors received the patches in advance; some, such as AlmaLinux, published packages the same day. PHP also announced separately that the rpms.remirepo.net repository will not be able to offer up-to-date packages on 21 October.

1. How do I find out what I'm using on my own server?

The version on the command line and the version used by the web server may differ. Both need to be checked first:

# Komut satırı sürümü
php -v

# PHP-FPM kuruluysa (paket adı dağıtıma göre değişir, ör. php8.3-fpm)
php-fpm8.3 -v

# Debian/Ubuntu: yüklü PHP paketleri ve sürümleri
dpkg -l | grep -E '^ii\s+(php|libapache2-mod-php)'

# RHEL/AlmaLinux/Rocky
rpm -qa | grep -E '^php'

To see which server interface (SAPI) PHP runs under on the web side, look at the Server API line in the phpinfo() output; if the line says "Apache 2.0 Handler", that means mod_php is in use. This page should be opened temporarily and deleted once you're done.

Those using shared hosting can usually see the version in the panel, and the hosting company performs the update. In this case, the best step is to check whether the company has made a statement and to ask if necessary.

2. Updating

The only complete solution is to update. If distribution packages are used, the version in the distribution's security advisory applies; if compiling from source, the version in the table above applies. After updating, all PHP workers need to be restarted; merely installing the package does not change running processes:

# Örnek: Debian/Ubuntu, PHP-FPM ve Apache
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

The NCSC specifically points out that network devices, management panels, ready-made applications and container images that bundle PHP internally are not updated through the server's package manager. For these, you have to wait for the vendor's patch. NCSC-NL keeps a list of potentially affected products on GitHub.

3. If the update cannot be done right away

The temporary measures PHP recommends are below. In PHP's own words, these narrow certain attack paths but do not make the installation secure. The settings must be set in php.ini, the FPM pool or the server configuration, and then all workers must be restarted; settings applied via ini_set() or .user.ini should not be relied on.

For CVE-2026-109619:

; Oturum yükleme ilerlemesi gerekmiyorsa kapalı tutulmalı (yamadan sonra da)
session.upload_progress.enabled = 0

; Yalnızca PHP 8.5
fatal_error_backtraces = 0

In addition, invalid or deprecated per-request settings that produce a warning at startup (such as php_value lines in .htaccess) should be cleaned up. Hiding the warning with error_reporting, display_errors or @ does not work.

For CVE-2026-109618:

; Dosya yükleme gerekmiyorsa 8M, gerekiyorsa 32M
post_max_size = 8M
; upload_max_filesize, post_max_size değerinden küçük kalmalı
upload_max_filesize = 6M

PHP also offers memory_limit=-1 as a partial measure. Because this setting removes the memory limit, the server must be protected by another means, for example a container or cgroup memory.max limit. RLIMIT_AS and RLIMIT_DATA should not be used; they can lead to exactly the memory allocation error that triggers the vulnerability. Limits should be set at the web server or reverse proxy layer for request size, number of fields, number of multipart form parts and number of headers. If the application does not use multipart forms, these requests can be blocked at the front layer.

If none of this is possible, the NCSC recommends considering taking the system offline until it is patched. For systems where the patch has to be delayed, checking web server logs, unexpected processes, files and outbound connections is also among the recommendations.

Unverified claims

What follows is not in the official advisories or is contradictory:

Active exploitation: watchTowr says it saw exploitation in its own honeypot network as of 21 October. Patchstack and Aikido also reported exploitation; however, according to SOCRadar's note, neither published technical details. Datadog, citing AWS, reports that exploitation attempts began on 17 October, four days before the vulnerabilities were publicly disclosed; Sansec, citing a social media post, writes that Cloudflare saw attacks on the morning of 21 October, before the fixes were released. I could not verify any of these first-hand. On the other hand, the Canadian Centre for Cyber Security says it did not detect active exploitation on the same day, but that the situation can change quickly; Rapid7 also does not report confirmed exploitation, and writes that it is expected. According to SOCRadar, as of 21 October neither vulnerability was in CISA's Known Exploited Vulnerabilities (KEV) catalog.
Public proof of concept (PoC): The Canadian Centre for Cyber Security writes that, according to public reports, a proof of concept exists. There are repositories published on GitHub under this name; I have not tried whether they work and I am not providing links.
Extending back to PHP 5: Some articles say the vulnerabilities affect all versions from PHP 5 onward. In its announcement, PHP states that it has released a minimal patch for 7.4, 8.0 and 8.1; it does not say anything explicit about older versions. The NCSC's phrase "every version of PHP" can also be read in this direction, but it does not give a version range.

Frequently asked questions

Am I affected if my site is WordPress?

Most likely yes. The vulnerabilities are not in WordPress but in PHP itself. Regardless of which application the site is built with, there is a risk if the PHP version on the server is older than the fixed versions. Updating a plugin or theme will not solve this problem.

What should I do on shared hosting?

Your hosting company updates PHP. Checking the PHP version in the panel, checking whether the company has issued a statement about php2shell, and asking if there is no statement is enough. If the panel allows it, switching to the newest supported PHP branch is also a good step.

I only use PHP on the command line, is there a risk?

The official announcements target installations that handle web requests; they do not specifically mention command-line (CLI) use. Still, if a web server is also running on the same machine, the update should not be postponed.

Are temporary settings enough?

No. PHP explicitly states that settings such as session.upload_progress.enabled=0, fatal_error_backtraces=0 and memory_limit narrow certain attack paths, but do not make the installation secure.

I use PHP 8.1 or older, what happens?

The PHP project is not releasing new versions for these branches. Minimal patches were published for 7.4, 8.0 and 8.1 for those compiling from source; distributions and companies providing long-term support may also offer their own patches. The permanent solution is to move to a supported branch.

My reading

What is certain: There are two separate, critical vulnerabilities that do not require authentication; the fixes came with 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The installation most at risk is Apache mod_php.
Configuration alone is not a solution: PHP explicitly states that none of the temporary measures make the installation secure. Changing settings and postponing the update only reduces the risk.
The real burden is outside the server: Updating your own server is relatively easy. The hard part is devices, panels and container images that bundle PHP internally; when these get patched depends on the vendor.
End-of-life versions: Systems remaining on 8.1 and earlier did not receive an official release this time. Considering that 8.2 will also reach end of life on 31 December 2026, planning the update together with a move to the next branch seems sensible.
Being cautious about exploitation: Claims of active exploitation come from a few security firms, but official bodies have not yet confirmed them. I do not treat them as certain; however, I also do not see them as a reason to wait with the update. If new official information comes in, I will update the article.

Sources

Official announcements

Assessments from security firms