Update, 22 October 2026: Attackers are now actively trying to exploit PHP2Shell. Cloudflare saw attacks before PHP’s fixes were released, and researchers expect mass exploitation now that patches and technical write-ups are public. If you have not patched, do it today. The UK’s National Cyber Security Centre advises taking offline any system you cannot fix immediately.

Update, 21 October 2026: PHP has released fixes for PHP 8.2 and newer, and the PHP team has published source patches for PHP 7.4, 8.0 and 8.1. Ondřej Surý has also backported the fix into his PHP packages for Debian and Ubuntu, covering every version back to PHP 5.6. If you’re on PHP 8.2 or newer, update now.

If your organisation runs PHP anywhere, this guide explains what has happened, which systems are at risk and the five steps to take today.

What is PHP2Shell?

PHP2Shell is a pair of flaws in the core of the PHP language that could let an attacker run their own code on a web server. In security terms, that is remote code execution: the most serious class of web vulnerability.

The details leaked before the PHP security team had a fix ready. A screenshot of an exploit tool has circulated publicly, and researchers at watchTowr have confirmed the flaws are real by reproducing CVE-2026-109618.

The full technical write-ups are now public. Both flaws are use-after-free bugs, triggered when PHP hits a fatal error such as running out of memory mid-request. A single crafted upload request can trigger them before any application code runs, with no login required.

How serious are the PHP2Shell vulnerabilities?

Both PHP2Shell vulnerabilities are rated 9.2 (Critical) under CVSS v4.0 by the PHP security team. A successful attack could give an outsider control of the server and access to the data and systems behind it.

Exploitation attempts have already been seen in the wild. Cloudflare saw attacks on the morning of 21 October, hours before PHP released its fixes, and Amazon’s threat intelligence team logged an attempt four days before the flaws were disclosed. Researchers have demonstrated unauthenticated code execution against Magento, WordPress, Drupal and Nextcloud.

The risk is highest for internet-facing systems, where anyone can reach the vulnerable code.

Which systems are affected?

Treat any system running PHP as vulnerable until it is patched. The flaws date back to PHP 5.4 and affect default configurations, including PHP-FPM, Apache with mod_php and php-cgi. Setups using mod_php are at greatest risk. Official fixes cover PHP 8.2 and newer, with source patches for 7.4, 8.0 and 8.1. On Debian and Ubuntu, Ondřej Surý’s packages cover every version back to PHP 5.6. Outside those, older versions remain unpatched.

PHP often runs where teams do not expect it. Check:

Public websites built on WordPress, Drupal or Magento
Intranets, customer portals and internal tools
Hosted and managed platforms, including hosting control panels
Third-party appliances and vendor software that run PHP behind the scenes

The last two are the easiest to miss. Ask your hosting providers and software suppliers to confirm in writing whether their products use PHP and when they will patch.

What to do now: a five-step response plan

The PHP security patch is the fix, but most of the work is knowing where to apply it. Run these steps in order.

Find your PHP. Build an inventory of every system running PHP, including vendor software and hosted platforms. You cannot patch what you have not found.
Patch now. PHP released its fixes on 21 October 2026. On PHP 8.2 or newer, update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On PHP 7.4, 8.0 or 8.1, apply the PHP team’s source patches. On Debian or Ubuntu, Ondřej Surý’s packages carry the fix for every version back to PHP 5.6. Patch internet-facing systems first. If you use managed hosting or a Linux distribution’s PHP packages, check when their fix will land.
Plan for unsupported versions. Anything older than PHP 8.2 is past end of life. A backported fix buys you time, but plan the upgrade to a supported PHP 8 release and contain any system you cannot patch (see the next section).
Reduce exposure. Take PHP applications that do not need to be public, such as admin panels and internal tools, off the open internet. Put them behind a VPN or restrict access by IP address.
Watch for compromise. Monitor web servers for the warning signs below, and keep doing so after you patch.

What about older PHP versions?

PHP versions older than 8.2 are past end of life, so PHP does not release fixes for them. You still have routes to patch today:

PHP 7.4, 8.0 and 8.1: the PHP team has published source patches.
Debian and Ubuntu: Ondřej Surý’s packages carry backported fixes for every version back to PHP 5.6. Read the package changelog before deploying, as a backport can change behaviour.

Treat any backport as a reprieve and keep the upgrade to PHP 8 on the plan. Upgrading is the only permanent fix.

If you cannot patch, you have three options:

Upgrade to a supported PHP 8 release. This is the only permanent fix, though older code may need changes and testing before it runs on PHP 8.
Isolate the system. Remove it from the internet or place it behind a VPN. This removes most of the risk, but users lose public access.
Put it behind a web application firewall (WAF). This keeps the service public, but a WAF only blocks attacks it can recognise.

For most organisations the right answer is to isolate first, then upgrade. The UK National Cyber Security Centre advises taking offline any system that cannot be fixed immediately. A WAF is a stopgap for systems that must stay public.

How to spot a PHP2Shell compromise

An attacker exploiting PHP2Shell will usually try to plant a web shell: a small script that gives them ongoing access to the server. Look for:

PHP or web server processes starting shells, interpreters or download tools such as curl and wget
New or changed PHP files in web folders, especially in upload directories
Unusual outbound connections from web servers
New cron jobs, scheduled tasks or user accounts

If you suspect a compromise, isolate the server and preserve the web server and PHP logs before you clean anything up. Patching a compromised server does not remove an attacker who is already in.

Frequently asked questions

Is there a patch for PHP2Shell?

Yes. PHP released fixes on 21 October 2026 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and published source patches for PHP 7.4, 8.0 and 8.1. On Debian and Ubuntu, Ondřej Surý’s packages carry backported fixes for every version back to PHP 5.6.

Is WordPress affected by PHP2Shell?

WordPress runs on PHP, so treat any WordPress site as vulnerable until PHP on the server is patched. The fix comes from patching PHP, not from a WordPress plugin or core update.

Has PHP2Shell been exploited?

Yes. Exploitation attempts have been observed since before the fixes were released, and researchers expect mass exploitation now that technical details are public. Neither CVE is on CISA’s Known Exploited Vulnerabilities list yet.

Does a web application firewall protect against PHP2Shell?

A WAF can reduce the risk. Cloudflare has deployed rules for known exploit techniques to all customers, including free plans. A WAF only blocks attacks it can recognise, so treat it as a stopgap while you patch or upgrade.

Summary

PHP2Shell is a pair of critical PHP vulnerabilities that leaked before a fix existed, and attackers are already trying to exploit them. Fixes are out for PHP 8.2 and newer, with backports for older versions. Find every system running PHP, patch internet-facing systems first and contain anything you cannot patch.

PHP2Shell: what the leaked PHP vulnerabilities mean and what to do now