PHP2Shell (CVE-2026-109618 and CVE-2026-109619): who is affected, fixed versions, how to check and how to patch

Key points for company leaders

This article reflects information available on the morning of 22 October 2026 (Japan time). Vendor statuses change quickly, so check the sources at the end for the latest.

• What happened

  On 21 October the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. If exploited, they can let someone run code on your server from the internet without logging in. Both are rated 9.2 (Critical) on CVSS v4.0.^[1][2][3]

• Who is affected

  Every PHP installation that serves web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Sites built on WordPress, Drupal, Joomla, Magento or Laravel are affected if the PHP underneath is unpatched. Updating the application or its plugins does not fix it.^[1][4][5]

• Exploitation

  Details leaked before the fixes were released, and Cloudflare and watchTowr report seeing attack traffic. Patchstack says hosting partners reported exploitation incidents to it. The US CISA and the Canadian Centre for Cyber Security said they had not observed exploitation at the time they published. When we checked, the CVEs were not in CISA's Known Exploited Vulnerabilities (KEV) catalog.^{[5][6][4][7][8][9]}

• What to do today

  Find every PHP installation run by you or your contractors, update the internet-facing ones first to a fixed release (or your OS vendor's patched package), and restart the PHP processes. PHP 8.1 and older have no official fixed release, so you need a vendor fix or a migration. If you cannot update right away, CISA and others list taking systems offline or isolating them as options.^[7][10]

Video explainer (about 5 minutes)

We made a five-minute illustrated video on how PHP2Shell works and how to check and patch. It has Japanese narration with Japanese and English captions. The full steps and sources are in the article below.

What to do today: five steps

We have put the recommendations from CISA, the UK NCSC, CERT-EU and IPA into a practical order. Your IT staff or contractors do the technical work, but leaders can check that each step is done.^{[7][11][10][12]}

1. 01Find them: list every site and system running on PHP, including the corporate site, campaign and recruiting sites, contact forms, internal admin screens, test environments and sites run by contractors. PHP can also be built into products and appliances, where users cannot see it.^[12][7] If you are not sure which sites exist under your domain, ZeroKai's free passive assessment lists the host names recorded in public certificate logs.
2. 02Prioritise: internet-facing systems come first. Apache with mod_php is the setup the PHP team considers highest risk.^[1][7]
3. 03Update: move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to the patched package from your OS vendor or host. See “Patch steps by environment” below.^[1]
4. 04Restart and verify: installing the update does not change PHP processes that are already running. Restart PHP-FPM or Apache, and rebuild and replace containers. Then confirm the version or package that is actually serving web traffic.^[13][14]
5. 05Check for compromise: you may have been attacked before you patched, so review logs and processes as described in “Looking for signs of compromise” below. The UK NCSC also asks organisations to check for compromise from before the update and look for backdoors left by attackers.^[11]

What PHP2Shell is

PHP2Shell is a set of flaws in how the PHP interpreter itself handles memory and errors. Because the problem is in PHP rather than in any one application or plugin, it touches almost every website that runs on PHP.^[15][16] The two vulnerabilities are:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), RCE via out-of-memory corruption: when a request hits PHP's memory limit, PHP aborts what it is doing. Internal data that was only half set up is left behind, and the clean-up code then treats it as valid. Crafted form submissions (multipart requests) can trigger this on purpose.^[2]
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), RCE via stale global state: a PHP worker handles many requests in turn. If a request ends abruptly, for example with a fatal error, internal state can keep pointing at memory that has already been freed, and the next request on the same worker uses it (a use-after-free). A confirmed path goes through PHP's session upload progress feature.^[3]

The impact is code execution with the web server account's privileges, reading process memory, and denial of service. Wiz, one of the reporters, showed that an attacker can read passwords, tokens and API keys from worker memory even without achieving code execution.^[3][16][17]

On severity: the PHP security team rates both 9.2 (Critical) on CVSS v4.0. Attack complexity is rated High, but no authentication or user interaction is needed. The PHP Foundation says the 10.0 score that circulated before release was wrong. Red Hat rates the impact on its products as Important.^[2][15][18]

Who is affected

The PHP team says every PHP installation serving web requests is at risk. How exposed you are depends on the setup.^[1][2][3]

• Apache with mod_php: the highest-risk setup. Unauthenticated remote code execution has been demonstrated for both CVEs with default settings.^[2][3]
• PHP-FPM (the common setup behind nginx or Apache): for CVE-2026-109619, remote code execution has been demonstrated when a suitable application operation exists. For CVE-2026-109618, source analysis indicates FPM is susceptible, but no complete exploit has been demonstrated.^[2][3]
• FrankenPHP, LiteSpeed (LSAPI) and php-cgi: listed as affected. FrankenPHP behaves like mod_php in the relevant respect, so it is considered likely susceptible to application-independent attacks.^[2][1]
• WordPress and other CMSs: Wiz demonstrated unauthenticated remote code execution against the latest WordPress, Drupal and Joomla container images. Updating the CMS or its plugins does not fix it; PHP itself must be updated.^[16][5]
• PHP built into products and appliances: some products use PHP for their admin screens. IPA asks users to start with the product manual and the vendor's security notices. The Dutch NCSC has published a list of products that may depend on PHP.^[12][11] Plesk, for example, says the PHP used by its own panel (sw-engine) also needed a fix.^[19]
• PHP used only on the command line: batch jobs and other uses that are not exposed to the web are much harder to reach from outside, but should still be updated.^[20]

For scale, W3Techs finds PHP behind 69.3% of websites whose server-side language is known. Estimates of how many exposed hosts may be affected vary widely.^[21]

Affected and fixed versions

These are the affected ranges and fixed releases for each supported branch, as listed in PHP's advisories, the NVD and AWS's bulletin.^{[2][3][22][17]}

End-of-life branches: the PHP project will not ship official fixed releases for PHP 8.1 and older. Given the severity, the security team published minimal source backports for PHP 7.4, 8.0 and 8.1 for people who build from source. There is no fix from the PHP project for PHP 5.4 to 7.3. Wiz, one of the reporters, says almost every version since PHP 5.4 is affected by at least one of the flaws.^[1][21][16]

• If you run an old PHP, your options are a patched package from your OS or LTS vendor (Ubuntu Pro, AlmaLinux, cPanel, Plesk and others) or a move to a supported branch.^{[1][25][26][27][19]}
• CISA says organisations that cannot update immediately, or that keep running PHP 8.1 or older, should take those systems offline until they can be patched or updated.^[7]

Patched packages by platform

• Ubuntu: fixed in every supported release. 22.04 needs php8.1 8.1.2-1ubuntu2.28, 24.04 needs php8.3 8.3.6-0ubuntu0.24.04.13, 26.04 needs php8.5 8.5.4-0ubuntu1.5 and 26.10 needs php8.5 8.5.9-0ubuntu2.1 or later. 20.04 and older get fixes through Ubuntu Pro (ESM), which is free for up to five machines. Even with unattended-upgrades enabled, services that use PHP still need a restart.^[14][28][25]
• Debian: 12 (bookworm) is fixed in php8.2 8.2.35-1~deb12u1 (DLA-4848-1) and 13 (trixie) in php8.4 8.4.27-1~deb13u1 (DSA-6574-1). Make sure the security repository is enabled.^[29]
• Red Hat Enterprise Linux: RHEL 8, 9 and 10 and OpenShift Dev Spaces 3 are affected. Red Hat rates the impact Important and is releasing fixes in stages. It says standard RHEL deployments use PHP-FPM, where exploitation is harder than with mod_php. Containers based on RHEL or UBI images need rebuilding once the base images are updated.^[18]
• AlmaLinux: patched packages for every PHP stream on 8, 9 and 10, including retired streams, reached the production repositories on 21 October (UTC). For example, the default PHP 8.3 on AlmaLinux 10 is fixed in php-8.3.33-1.el10_2.alma.1 and the default PHP 8.0 on AlmaLinux 9 in php-8.0.30-8.el9_8.alma.1. AlmaLinux says to check with “rpm -q php-common” rather than php -v. On AlmaLinux 8, the default stream if you did not choose one is PHP 7.2.^[26]
• Rocky Linux (CIQ): CIQ has shipped patched packages for some of its commercial variants (RLC Pro LTS 9.6 and 9.2), with the rest pending. For community Rocky Linux, check the Rocky Linux errata.^[20]
• AWS: patched Amazon Linux packages were targeted for 22 October. Elastic Beanstalk released updated PHP platform versions (v4.13.12) on 21 October. AWS cannot update running Lightsail instances, so Lightsail users need to create new instances from the updated blueprints and migrate.^[17]
• Docker (official PHP images): tags for 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are available. Point your builds at them, rebuild, and replace the running containers.^[30][13]
• Homebrew (for example on developers' Macs): php, php@8.4, php@8.3 and php@8.2 have been updated to the fixed releases. php@8.1 remains at 8.1.34 and is marked deprecated.^[31]
• Windows: fixed binaries are on PHP's downloads page.^[1]
• cPanel (EasyApache 4): ea-php74 (7.4.33-19), ea-php80 (8.0.30-12), ea-php81 (8.1.34-5) and ea-php82 to 85 (8.2.35, 8.3.36, 8.4.27, 8.5.12) are fixed. For PHP older than 7.4, cPanel points to TuxCare's extended lifecycle support. For PHP packages supplied by CloudLinux, follow CloudLinux's updates.^[27]
• Plesk: Plesk's PHP 8.2 to 8.5 builds have been updated to the fixed releases. For end-of-life 7.4, 8.0 and 8.1 the version number does not change; builds dated 21 October 2026 contain the fix. The PHP that runs the Plesk panel itself (sw-engine) is fixed in Plesk Obsidian 18.0.81 Update 4, with a fix for 18.0.80 still pending.^[19]
• Remi's repository (rpms.remirepo.net): the PHP team said it would not have updates on release day and urged users to switch to distribution packages or build from source.^[1]

How to check whether you are exposed

1. 01Map what is visible from outside: list every site you expose to the internet. The UK NCSC asks organisations to find every PHP installation, not just outdated ones.^[11] ZeroKai's free passive assessment can help: it collects your domain's host names from public certificate logs, including forgotten subdomains.
2. 02Check packages on each server: on Ubuntu run “apt list '?installed ?name(^php[0-9.]+$)'”, on AlmaLinux and other RHEL-family systems run “rpm -q php-common”, and on cPanel run “rpm -q --changelog ea-php81-php-cli | grep -m1 CVE-2026-109618” (replace php81 with the version you are checking). Compare the result with the fixed versions in the previous section.^[14][26][27]
3. 03Check how PHP runs (the SAPI): mod_php is the highest-risk setup. On AlmaLinux 8, if “httpd -M 2>/dev/null | grep -E 'mpm_|php'” shows mpm_prefork_module and php_module (or php7_module), the system uses mod_php.^[26][1]
4. 04WordPress sites: the PHP version is shown under Tools → Site Health → Info → Server in the admin screen. On shared hosting the number alone may not tell you whether the fix is in, so check your host's notices too.^[32]
5. 05Containers: list images that contain PHP and the base images they are built on. Some applications bundle their own PHP interpreter.^[13]
6. 06Products, appliances and outside services: for products that embed PHP, check the vendor's notices. The Dutch NCSC maintains a list of products with a PHP dependency on GitHub.^[12][11][20]

Patch steps by environment

In every environment, the old code keeps running until the PHP processes are restarted after the update. Restart long-running command-line PHP jobs too.^[14][20]

• Ubuntu and Debian: update with “sudo apt update && sudo apt upgrade”, then restart PHP-FPM (for example php8.3-fpm) or Apache if you use mod_php. To update only PHP you can use “sudo apt install --only-upgrade '?name(^php[0-9.]+$)'”. If in doubt, rebooting the server makes sure everything picks up the fix.^[14]
• AlmaLinux, Rocky Linux and RHEL: update with “sudo dnf clean metadata && sudo dnf upgrade 'php*'”, then restart with “sudo systemctl restart php-fpm” (or httpd for mod_php). If you are on a retired stream, plan a move to a supported one after checking your applications work with it.^[26][20]
• cPanel: update cPanel from WHM, or run “yum clean all && yum makecache” followed by “/scripts/rpmup”.^[27]
• Plesk: install Plesk updates to update both the PHP builds and the panel's own PHP (sw-engine), then check versions under Tools & Settings → PHP Settings. On Linux you can check each version, for example with “/opt/plesk/php/8.3/bin/php -v”.^[19]
• Containers: change the base image in your Dockerfile to a fixed tag, rebuild and redeploy everywhere. Check that no containers started from the old image are still running.^[13][30]
• If you build from source: get the fixed release from php.net. For PHP 7.4, 8.0 and 8.1 you can apply the minimal backports from the security team, but the long-term answer is to move to a supported branch.^[1]
• Managed cloud services: on Elastic Beanstalk, update the platform version (it applies automatically in the next maintenance window if managed platform updates are on). On Lightsail, rebuild from the updated blueprints.^[17]
• Shared hosting: your host updates PHP. Check its notices for status, and if you have selected an old PHP version in the control panel, switch to a supported one.^[5][33]

Japan: public agencies and hosting providers

On 21 October, ahead of the fixed releases, IPA issued an alert asking organisations to prepare. It asked them to inventory programs that use PHP and noted that some sites still run old, unsupported PHP. IPA said it had not confirmed attacks at the time.^[12] When we checked on the morning of 22 October, JPCERT/CC's alert list and JVN had no entry for these CVEs.^[34]

• Xserver: suspended its websites and control panels as a precaution from 16:00 on 21 October, saying this was not due to unauthorised access. Its 06:45 update on 22 October said the fix had been applied to all servers for PHP 8.2 to 8.5, with older versions being patched as fixes are ready.^[35]
• Sakura Internet: carried out emergency maintenance to upgrade PHP on Sakura Rental Server, Managed Server and related services from 23:00 on 21 October to 06:30 on 22 October, and has completed it. It asks users on old PHP to move to PHP 8.3.^[33]
• KAGOYA: said it would update PHP 8.2 to 8.5 on its rental server plans after checking the fixed releases. Other plans and versions were still under review (as of 21 October).^[36]
• Other providers: according to AB Tsushin's roundup, Lolipop! said its maintenance was a precaution for the PHP vulnerabilities, while ConoHa WING, Onamae.com and others announced maintenance as “system maintenance” without mentioning PHP. Check the notices from your own provider.^[32]

On shared hosting, updating PHP is the host's job, but your site's contents (WordPress plugins, custom code) and the PHP version you pick in the control panel are your responsibility. On VPS, dedicated or cloud servers you also have to update PHP yourself.^[32][5]

Interim mitigations if you cannot update yet

• For CVE-2026-109618: set memory_limit to -1 with php_admin_value so applications cannot override it, and check that no other setting restores a limit. Use a container or cgroup memory limit instead, ideally one that stops only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable path.^[1][2][26]
• Also lower post_max_size (8M if you do not need uploads, 32M if you do, with upload_max_filesize below it). At the web server or proxy, limit request size, number of input fields, multipart parts, headers and nesting depth. The limits must also cover requests without a usable Content-Length.^[1]
• For CVE-2026-109619: set session.upload_progress.enabled to 0. The PHP team suggests leaving it off even after patching if you do not need it. On PHP 8.5, also set fatal_error_backtraces to 0. Remove invalid or deprecated settings applied per request (in .htaccess or PHP_VALUE, for example). Hiding errors does not help.^[1][3]
• If your application does not take uploads, you can block multipart/form-data requests before they reach PHP. CIQ warns not to limit the rule to POST, because PHP 8.4 and later can parse multipart bodies on other methods. If performance allows, setting PHP-FPM's pm.max_requests to 1, so each worker handles one request, is also listed.^[2][3][20]
• Turn off PHP you do not use: on servers where PHP is installed but unused, stop PHP-FPM or disable mod_php.^[20]
• WAF: CISA says a web application firewall may provide some protection until systems are updated. Cloudflare has had protective rules on by default for WAF customers on all plans, including Free, since 21 October (UTC). They do not help if your server also accepts direct traffic that bypasses Cloudflare. For AWS WAF, AWS has published a rule that blocks bodies over 8 KB and a custom rule for CVE-2026-109619. Check that your WAF can inspect large request bodies in full.^{[7][5][4][17][13]}
• Isolate: CISA and the UK NCSC say systems that cannot be updated or mitigated quickly should be considered for taking offline. CERT-EU recommends isolating internet-facing applications.^[7][11][10]

Looking for signs of compromise

The attack happens below the application, so application logs may show little. Datadog recommends combining three layers: incoming requests, the PHP error log, and processes started by web workers. No single signal is conclusive.^[13][16]

• Requests

  Unusually large form submissions, extremely long field names (about 3.5 MB in Datadog's test), values containing null bytes or other control characters, and multipart requests with huge numbers of headers or many empty file fields.^[13][26]

• PHP error log

  Out-of-memory errors of the form “Allowed memory size of … bytes exhausted … in Unknown on line 0”. “Unknown on line 0” means PHP failed while initialising the request, before any script ran. Repeated HTTP 500 responses are also a clue.^[13][16]

• Web server logs

  Worker crashes such as “AH00052: child pid … exit signal Segmentation fault (11)” in the Apache error log, and unexplained worker restarts.^[13][16]

• Responses

  Unusually large or malformed PHPSESSID cookies, which can indicate leaked memory.^[16]

• Processes

  PHP workers or Apache launching shells (sh, bash and so on), downloading tools or making outbound connections. This is the most direct evidence of compromise.^[13][7]

• Clues for CVE-2026-109619

  Configuration warnings at request start-up, warnings during shutdown, fatal errors and execution timeouts on routes an attacker can reach.^[3][13]

If you suspect a compromise

1. 01Disconnect the server from the network to stop the damage spreading.^[11][10]
2. 02Preserve web server, PHP and system logs before rebuilding. You will need them for investigation and reporting.
3. 03Look for backdoors left by the attacker. The UK NCSC asks organisations to check for compromise from before the update and look for backdoors.^[11]
4. 04Rotate the passwords, API keys, tokens and certificate keys the server held, because these flaws can leak memory contents.^[16][4]
5. 05If compromise is confirmed, rebuild the server from a known-good state and apply the fix before reconnecting it.
6. 06If you cannot investigate fully yourselves, bring in an incident response firm. If personal data may have been exposed, check with a lawyer or other expert whether you have reporting or notification obligations.^[11]
7. 07Check your other entry points. For domains whose ownership you have verified, ZeroKai shows whether Shodan has observed remote access (such as RDP), file sharing, database or FTP services exposed to the internet.

Timeline

Exploitation status and how to read the risk

• watchTowr says its honeypot network observed exploitation on 21 October. Cloudflare saw attack traffic and payloads being changed to try to get around its rules. Datadog says there are multiple reports of active exploitation and broad untargeted scanning.^[6][5][13]
• Patchstack said hosting partners had reported exploitation incidents, but that shortly after the fixes were released its own telemetry showed only probing, with no hard evidence of breaches yet.^[4]
• CISA and the Canadian Centre for Cyber Security had not observed exploitation when they published, and IPA said it had not confirmed attacks. When we checked, the CVEs were not in CISA's KEV catalog.^{[7][8][12][9]}
• How hard is it? PHP rates attack complexity High: success requires shaping memory layout and getting several requests to the same worker. Wiz notes, however, that AI has greatly reduced the effort that this tuning takes. CIQ reports that the Dutch NCSC considers large-scale exploitation likely in the short term.^{[2][3][16][20]}

In short, large-scale damage has not been confirmed, but attacks have started, and under the right conditions these flaws allow takeover without authentication. Aiming to update internet-facing PHP today is a reasonable target.

FAQ

Printable checklist

• Listed every site, system and product using PHP, including those run by contractors
• Put internet-facing systems and mod_php setups first
• Updated to a fixed release (8.5.12, 8.4.27, 8.3.36 or 8.2.35) or the vendor's patched package
• Restarted PHP-FPM and Apache, and rebuilt and replaced containers
• Confirmed the fix by package version, not by php -v alone
• Checked notices from hosting providers and product vendors
• For PHP 8.1 and older, decided on a vendor fix, a migration or isolation
• Applied mitigations and WAF rules where updating is not yet possible, understanding they only buy time
• Checked logs and processes for signs of compromise
• Rotated credentials on any server showing signs of compromise
• Decided which interim mitigations to keep, and planned to move off PHP 8.2 before its end of life on 31 December 2026

How ZeroKai can help

The first stumbling block with a vulnerability like this is not knowing where your PHP sites are. ZeroKai takes your domain, lists the host names recorded in Certificate Transparency logs and highlights names that look like admin screens or test environments. For domains whose ownership you have verified, it also shows exposed remote access, file sharing, database and FTP services observed by Shodan. It checks email and DNS settings such as SPF and DMARC, and the console lets you browse vulnerability information from CISA's KEV catalog and JVN iPedia.