PHP2Shell in 2026: Vulnerabilities, Patched Versions & What Website Owners Should Do

The short answer

On October 21, 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities that can allow unauthenticated remote code execution, tracked as CVE-2026-109618 and CVE-2026-109619. PHP2Shell is the name used in security coverage for that pair. Unauthenticated means an attacker does not need an account on your site; remote code execution means they could run their own code on your server.

What matters is the exact PHP runtime serving your site, not your CMS or framework version. Check whether each site runs a fixed upstream release or a package your host or distribution has patched, starting from the PHP project's announcement. Treat any site on PHP 8.1 or older as a more urgent problem.

Timeline

• October 21, 2026. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released with the fixes. The same day, CISA publishes an alert calling for immediate patching, the UK NCSC publishes a news item on the issue, and the Canadian Centre for Cyber Security publishes alert AL26-026.
• October 23, 2026. php.net publishes an informational advisory about a separate issue, CVE-2026-115560, covered below.
• October 26, 2026. CISA updates its alert: both CVEs are added to its Known Exploited Vulnerabilities catalog. The same day, php.net publishes rebuilt Windows packages, labelled 8.x.y-1, with Brotli 1.2.1 for a separate issue (CVE-2026-111497) reachable through cURL's automatic decompression. PHP version numbers do not change, and only Windows builds are affected.

The two vulnerabilities, at a high level

Both concern how the PHP engine manages memory and state while it handles requests. Neither is a bug in WordPress, Laravel or your own code. This guide does not describe how either one is exploited.

• CVE-2026-109618, “RCE via OOM corruption” (GHSA-w8hw-w9fx-j79w). When PHP runs out of memory, the out-of-memory handling can interrupt it while request data is only partly set up, and the cleanup that follows treats that data as valid. The advisory rates it 9.2 under CVSS v4.
• CVE-2026-109619, “RCE via stale global state” (GHSA-6wmf-4rv5-p3rp). State that belongs to one request can survive after its memory is freed, and a later request handled by the same worker may use it. Also rated 9.2 under CVSS v4.

php.net lists who is at risk as all PHP installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk for mod_php, where it says a pre-application exploit was demonstrated. A site can be exposed even if its own code is flawless.

On exploitation, be precise. The Canadian Centre says open-source reporting indicates both CVEs are being exploited in the wild, and CISA has added both to its catalog of known exploited vulnerabilities. The security firm watchTowr reports exploitation observed in its honeypot network since October 21; honeypots are decoy systems, so that shows attempts against sensors, not confirmed breaches of real sites. None of this means every PHP site has been compromised, but an unpatched site should be treated as a target.

Which PHP versions are patched?

A recent PHP version is not necessarily a patched one. php.net says Linux distributions and long-term support vendors received the patches in advance. Vendors often backport fixes into their own packages, so a package's version string can differ from the upstream numbers in the table: a patched package may not show 8.3.36, and a number alone does not prove a package is patched. Ask your vendor or host whether the specific package you run includes the fixes for both CVEs.

For PHP 8.1 and older, php.net states that these branches no longer receive updates from the PHP project. Its source backports are for people who build or package PHP, not an installable update for most site owners.

Is my WordPress site affected?

The PHP runtime under WordPress decides this, not the WordPress version. A fully updated WordPress site on an unpatched PHP build is exposed.

To find the PHP version, look in your hosting control panel, or in the WordPress admin under Tools, Site Health, Info, Server. The version alone does not show whether a vendor backport is included, so ask your host. Do not create a public phpinfo() page to check: it shows your server's configuration to anyone who finds it. If one exists from earlier work, remove it.

If the host can move you to a newer PHP version, check your theme and plugins first. WordPress itself recommends PHP 8.3 or greater, and says it can still run on PHP 7.4 or later only in legacy environments that are past end of life.

Is my Laravel application affected?

Laravel runs on top of the PHP runtime, so the question is which PHP build serves your application on every server and container. Running composer update updates your PHP packages; it does not change the PHP interpreter, and it does not fix these CVEs. The fix is a patched PHP package or image, deployed and loaded.

If the patched version means moving to a newer PHP branch, check your Laravel version's range: Laravel 12 supports PHP 8.2 to 8.5, and Laravel 13 supports PHP 8.3 to 8.5. For applications several versions behind, our Laravel upgrade and modernization checklist walks through the phases.

A safe response checklist

You can do this without server access

• List every PHP site you own, including staging copies and old subdomains, with its PHP version from the hosting panel or Site Health.
• Ask your host or IT provider, in writing, whether the package each site runs includes the fixes for CVE-2026-109618 and CVE-2026-109619, and when it was applied.
• Mark every site on PHP 8.1 or older. Those need a plan, not just a ticket.
• Confirm a recent backup exists for each site.
• Do not rely on a firewall. CISA says a web application firewall may provide some protection; that is not the same as a fix.

This needs server access or your host

• Install the fixed upstream release or your vendor's patched package, then restart PHP-FPM or the web server so the new binary is actually loaded.
• Cover every PHP that serves requests, including worker pools and containers; rebuild images from a patched base image.
• Confirm the running version through the web server itself, not only the command line, since the two can differ. Remove any temporary check afterwards.
• If you cannot update yet, php.net lists interim measures, but says they reduce exposure but do not make an installation safe; only an update is a complete fix.
• If a system cannot be updated at all, restrict who can reach it. CISA and the NCSC go further and advise taking such a system offline until it is fixed.
• If a server shows signs of compromise, such as files you did not upload, patching alone is not enough. Bring in a security specialist.

CVE-2026-115560: a separate session issue

On October 23, php.net published an informational advisory about another issue. It applies only under a specific combination: session.serialize_handler set to php_binary or php_serialize and then switched to php at runtime with ini_set() before session_start(), with session upload progress enabled. php.net suggests setting session.upload_progress.enabled=0 until the next regular bugfix release, which will carry the full advisory. As of October 28, 2026, that release has not shipped. This setting does not fix CVE-2026-109618 or CVE-2026-109619; it is in addition to the October 21 update, not instead of it.

Still on PHP 5, 7 or early 8.x?

There is no upstream release for these branches (php.net published only minimal source backports for 7.4, 8.0 and 8.1), but there are options. First, check whether your operating system vendor or an extended-support vendor ships a patched package. Second, contain the exposure. Limiting who can reach the application helps; for organizations that cannot update or run PHP 8.1 or earlier, CISA advises taking PHP systems offline until they are patched, and the NCSC suggests considering the same. Third, plan the move to a supported branch, which is the only lasting answer.

Not every old installation is equally exposed. php.net's advisory concerns PHP serving web requests, with mod_php at the highest risk; a script run only from the command line on an internal machine is in a different position from a public website. That is a reason to prioritize, not a reason to wait.

After the urgent patch

Patching closes this pair of vulnerabilities. It does not change the support calendar. PHP 8.2 receives security fixes only until December 31, 2026, so an application patched to 8.2.35 still needs a move to a newer branch planned before that date. PHP 8.3 has security support until December 31, 2027, PHP 8.4 until December 31, 2028 and PHP 8.5 until December 31, 2029. Our PHP 8.2 end-of-life planning guide compares those targets and lists the migration steps.

Use the urgency to fix what made this patch hard: keep an inventory of which PHP runs where, add tests around the critical paths, and build a release process that can ship a runtime change quickly. Then put PHP, framework and dependency updates on a regular schedule.

When to bring in a development partner

Many teams can handle a patch with their host. Outside help makes sense when:

• the application has no active maintainer, or the original developer has left;
• your developers can change the code but not the runtime safely, or the host will not move without a compatibility check;
• plugins, extensions or packages block the move to a patched or supported version;
• payment, CRM or other integrations need regression tests before anything changes;
• several servers or environments have to be updated together.

That is the work our PHP upgrade and migration service covers, from an urgent patch assessment to a staged move to a supported version.

Last reviewed October 28, 2026, against the linked sources. Advisories change as the situation develops, so check them before you act. This guide summarizes published information; it is not a security assessment of your system.