php2shell (CVE-2026-109618, CVE-2026-109619): what it is and how to fix it

Only check systems you own or are responsible for. This page and our checker work from version numbers you type in. Nothing here tests, probes or scans a server.

Short answer

“php2shell” is the nickname Wiz Research gave to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The PHP Group rates both CVSS v4.0 9.2 and says they can allow unauthenticated remote code execution, which means a stranger on the internet may be able to run code on your server. If your server runs PHP below 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or an older branch such as 8.1 or 7.4), update now and restart PHP. The vendor’s own advisory says: “There are no complete mitigations, updating is the only safe choice.”

What php2shell is

• Two CVEs, one fix. CVE-2026-109618 is titled “RCE via OOM corruption” and CVE-2026-109619 “RCE via stale global state” in the PHP Group’s advisories (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp). Both are fixed by the same PHP releases. We do not describe how they work and you do not need that to patch.
• Severity. Both score CVSS v4.0 9.2 (Critical), as assigned by the PHP Group. NVD has since added its own CVSS v3.1 scores, 9.8 (Critical) for CVE-2026-109618 and 8.1 (High) for CVE-2026-109619 (lowered from 9.8 on 22 Oct), and keeps the PHP Group’s score as secondary (CVE-2026-109618, CVE-2026-109619).
• The name. “php2shell” does not appear in php.net’s announcement or the CVE records. It comes from the Wiz Research blog post, which NVD references, and is used by CERT-EU / NCSC-NL and the ENISA CSIRTs Network. You may also see these two CVEs under the PHP Group’s GHSA ids above.
• Is it being exploited? Statements differ, so here they are by name. The PHP Group says the risk is highest for mod_php and that an exploit has been demonstrated. CERT-EU says proofs of concept have begun to circulate and that this raises the likelihood of attacks. The PHP Foundation says proof-of-concept circulation increased on 21 Oct but that its security team did not identify any functional exploits at the time of release. The Canadian Centre for Cyber Security reports that a proof of concept is available and that it had identified no active exploitation at that time. When we checked on 22 Oct 2026, neither CVE was in CISA’s Known Exploited Vulnerabilities catalog (version 2026.10.21, released 21 Oct 2026 at 14:04 UTC, before NVD published its records, so this can change) and CISA’s assessment recorded in NVD said exploitation “none”. Treat it as urgent regardless.

Who needs to act

Anyone whose server runs PHP to answer web requests. The PHP Group’s wording: “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.” That includes WordPress, Laravel, Drupal and any other PHP app: what matters is the PHP version on the server, not the app version.

Affected and fixed versions

Source: php.net advisory and supported versions. The PHP Group’s records list 8.2.* below 8.2.35, 8.3.* below 8.3.36, 8.4.* below 8.4.27 and 8.5.* below 8.5.12 as affected. NVD’s own product data goes further: it matches every PHP version below 8.2.35, so 8.1 and older too, plus the same 8.3, 8.4 and 8.5 ranges. Full table with distro packages: fixed versions.

Distro packages keep older numbers

Linux distributions usually do not move to the new upstream version. They back-port the fix into their existing version, so the number looks old even when it is patched. Compare with your vendor’s fixed package version, not the upstream number. For example, Ubuntu lists 8.3.6-0ubuntu0.24.04.13 as the fixed build for 24.04 LTS, and 8.1.2-1ubuntu2.28 for 22.04 LTS (Ubuntu CVE page). Debian 13 (trixie) lists 8.4.27-1~deb13u1 (DSA-6574-1). Red Hat now lists fixed packages for most of its PHP streams, for example 8.3.36-1.el10_2 for RHEL 10 php and 8.2.35-1.module+el9.8.0+25111+a1450321 for RHEL 9 php:8.2, while RHEL 9 php:8.4 was still “Affected” with no advisory on 22 Oct 2026 (Red Hat CVE page). Rocky Linux has published advisories for six streams (RHEL-equivalent 10 php and php8.4, 9 php 8.0, php:8.2 and php:8.3, 8 php:7.4) but none yet for 9 php:8.4 or 8 php:8.2. Oracle Linux lists fixed builds for 10 php and php8.4, 9 php 8.0, php:8.2 and php:8.3, and 8 php:7.4 and php:8.2; we found no Oracle entry for other streams. AlmaLinux has published advisories for 10 php and php8.4, 9 php:8.3 and 8 php:7.4. The rest of the table is on fixed versions.

Old PHP branches

PHP 8.1 and older no longer receive updates from the PHP project (php.net). For PHP 7.4, 8.0 and 8.1 the security team published minimal source-only backports, aimed at people building from source or without an LTS vendor; there is no release tarball or version number. Some vendors ship their own back-ports, for example Ubuntu 22.04 for 8.1, Red Hat for RHEL 8 php:7.4 and RHEL 9 php 8.0 (see PHP 7.4, 8.0 and 8.1). For 7.3 and older, php.net announces nothing. CERT-FR lists every PHP 5.x, 6.x, 7.x, 8.0.x and 8.1.x version as affected (CERTFR-2026-ALE-014). The real fix is to move to a supported branch; if you cannot yet, ask your OS vendor or an extended-support provider for a patched package. php.net also lists interim configuration limits, which it says “reduce exposure to specific attack paths but do not make an installation safe”. Use them only as a stopgap.

The 3 steps: check, update, verify

Take a backup or snapshot first. This matters most if you jump to a new PHP branch rather than taking a patch update inside your current one.

Step 1: Check

php -v                                  # command-line PHP; may differ from the web one
ls /usr/sbin/php-fpm* 2>/dev/null       # FPM binaries; then run e.g. php-fpm8.3 -v
dpkg -l | grep -E '^ii +php'            # Debian / Ubuntu packages
rpm -qa | grep -i '^php'                # RHEL, Alma, Rocky, Amazon Linux

The web server can use a different PHP than the command line, so check the FPM or Apache one (php-fpm -v on RHEL-style systems). Then type your version into the checker and compare it against the fixed versions table. On a distro package, use the distro’s fixed package version.

Step 2: Update with your normal package path

Debian / Ubuntu (replace 8.3 with your branch):

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt install --only-upgrade 'php8.3*'

RHEL family (compare with your vendor’s advisory first; not every stream has a fixed package yet, see fixed versions):

sudo dnf check-update 'php*'
sudo dnf upgrade 'php*'

Docker: rebuild from a patched base image, then recreate the container.

docker build --pull --no-cache -t myapp:patched .
docker compose up -d --force-recreate

If you build from source or use a third-party repository, take 8.2.35, 8.3.36, 8.4.27 or 8.5.12 from php.net downloads. The PHP Group said on release day that the volunteer-maintained Remi’s RPM repository would not have updates that day. By 22 Oct 2026 Remi’s repository carried 8.2.35, 8.3.36, 8.4.27 and 8.5.12 builds for Enterprise Linux 8, 9 and 10 dated 21 Oct (for example 8.4.27-1.el9.remi).

Step 3: Restart and verify

An update does not take effect until the running PHP process is restarted.

sudo systemctl restart php8.3-fpm       # your FPM unit name; on RHEL: php-fpm
sudo systemctl restart apache2          # only if you use mod_php (RHEL: httpd)
php -v
dpkg -l | grep -E '^ii +php8.3'        # Debian / Ubuntu: compare to your vendor's fixed package version

Then confirm in three places: the installed version matches the fixed one for your vendor, the service restarted without errors (systemctl status php8.3-fpm), and your site still loads. For containers, run docker exec <container> php -v on the new container. Re-enter the version in the checker to confirm.

Timeline of official announcements

Not confirmed yet when we checked on 22 Oct 2026: an IPA update after its pre-release notice, and the Australian ACSC page (we could not open it). The ENISA CSIRTs Network also has a CNW-2026-04 page on this issue, but we did not record its date, so it is not in the timeline. Check those agencies directly if you rely on them.

Hosting and distro status

Hosts and distros are publishing fixes at different speeds. As of 22 Oct 2026, Ubuntu, Debian 12 and 13, Red Hat (most streams), Rocky Linux, Oracle Linux and AlmaLinux (some streams each), Amazon Linux 2023 (php8.2 to php8.5) and Alpine 3.24 list fixed packages; so do Alpine 3.23 (php83 to php85), Alpine 3.22 (php82 to php84) and Alpine 3.21 (php82), although those community repositories are past their support dates. The Amazon Linux 2 core php package is listed as “No Fix Planned”. Among hosts, some describe server-side protections or an ongoing rollout, some say the fix is done and others say customers must act. Those protections are no substitute for a PHP update unless the host says the update itself is done. See hosting status for each provider’s statement and the fixed versions page for distro packages. Anything we could not confirm is marked unconfirmed, not assumed to be patched. Platform walkthroughs: Ubuntu and Debian, Docker, WordPress, cPanel, Plesk, DirectAdmin, PHP 7.4, 8.0 and 8.1 and Cloudflare WAF.

Want help with your exact setup?

If you would rather not work out the right steps yourself, we offer a $49 personal patch plan: written steps for your exact setup by email within 24h. Details at /fix-service/.