PHP2Shell: The PHP Vulnerability and What to Do Now

PHP2Shell is the name for two critical security flaws in PHP, the programming language that WordPress and many other websites run on. If your website runs on PHP, the fix is a PHP update to version 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Attacks have already been reported, so treat this as a job for this week. This post explains what's happening, gives you a quick checklist to see whether you're affected, and walks through how the update works on common setups.

The PHP project released the fixes on October 21, 2026, and in its security announcement told all PHP users to update immediately. Both flaws are rated Critical, with a CVSS v4 score of 9.2. You run a trade business, not an IT department, so most of what follows comes down to a short conversation with your host or web person. The technical settings sit in a clearly marked section you can hand to them. It's the same kind of tech-stack homework we covered in our post on keeping customer data safe in your field service software.

How the PHP2Shell vulnerability works

PHP is the software on many web servers that builds a page each time someone visits. The two flaws, tracked as CVE-2026-109618 and CVE-2026-109619, break that process in different ways. The first involves running out of memory. PHP can get interrupted while a visitor's request is only partly set up, and the cleanup step may then treat that half-built data as valid.

The second flaw involves leftovers. Internal data tied to one request can outlive the memory behind it, and a later request handled by the same worker process may use that stale data before it gets reset. Either problem can open the door to what security teams call unauthenticated remote code execution. That means an attacker with no login could run their own commands on your server.

For one common server setup, called mod_php, the PHP project reports a demonstrated exploit that an unauthenticated request can trigger before any of your website's own code runs. Word of the flaws leaked on social media before the planned announcement, which had been scheduled for October 22. watchTowr reports that its network of decoy servers, called honeypots, saw exploitation in the wild as of October 21, and Cloudflare reports early attacks. Tenable cites two different measures: a rough estimate of over 1.3 million internet-exposed hosts that are potentially vulnerable, and a Shodan search showing over 1.9 million internet-exposed hosts running PHP.

Key Takeaway: Two flaws in PHP itself can let someone with no login run commands on your server, and attacks are already being reported. The fix is a PHP update on the server, not a change inside your website.

Who is at risk from the PHP vulnerability

The PHP project says every PHP installation that serves web requests is at risk. That covers the common ways servers run PHP, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The project considers the risk highest for mod_php.

Many popular website platforms are built on PHP. Tenable's FAQ on PHP2Shell notes that WordPress, Drupal, Joomla, Laravel and Magento all run on PHP. Tenable also reports that Calif says it confirmed pre-authentication remote code execution against specific versions of WordPress, Drupal, Joomla and Magento. If your business site is on WordPress, treat it as in scope until you confirm its server is patched.

Older versions carry extra risk, because PHP 8.1 and older no longer get updates from the PHP project. VirusTotal's analysis counted about 758,000 internet-facing hosts on the end-of-life branches 5.4 through 8.1, compared with about 272,000 on the supported 8.2 through 8.5 branches. That number shows how many servers run those versions, not how many are confirmed vulnerable.

How to check if your site is affected

Work through these steps in order. Most of them take a few clicks or one email.

1. Confirm whether your site runs on PHP. WordPress sites do. If you're not sure what your site runs on, ask whoever hosts or built it.
2. Find your PHP version. In WordPress, go to Tools > Site Health > Info and open the Server section. WordPress's Site Health documentation says this section shows information about your server, including various PHP variables. If your host gives you cPanel, the MultiPHP Manager lists the PHP version each domain currently uses.
3. Compare your version to the fixed releases. The patched versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, according to the GitHub advisories for CVE-2026-109618 and CVE-2026-109619. In PHP's own releases, anything below those in the same line, such as 8.3.35, is affected. If your host uses a Linux vendor's PHP package, the fix may be included under a different version number, so ask (step 5).
4. Check whether you're on an unsupported line. If your version is 8.1 or older, the PHP project no longer updates it. Skip ahead to the platform guidance and plan an upgrade.
5. Ask your host in writing. Ask whether your server has a patched PHP release yet. If it uses PHP packages from a Linux distribution or a long-term support vendor, ask whether those packages include the fix.
6. Write down who controls the server. Note whether your host manages PHP or whether you or your developer do. That answer tells you who makes the update.

Don't worry if you can't find a setting. WordPress notes that changing these server settings may require your hosting provider. Your host can also turn the MultiPHP Manager on or off, so if you don't see it, ask them.

Key Takeaway: Find your PHP version, compare it to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and get your host's answer in writing. If you're on 8.1 or older, ask about vendor backports, but the lasting fix is an upgrade.

How to prepare for the PHP update on your platform

Who does the work depends on where your site lives. Find your setup below.

WordPress on a hosting account

Your host may apply the patch for you, or you may switch versions yourself. Either way, WordPress's own guide to updating PHP lays out a safe order. Start by making a backup of your website. Then update WordPress, your theme and your plugins, and confirm the site still works.

If you're moving to a newer PHP line, such as 8.1 to 8.3, run a PHP compatibility checker plugin first. For anything it flags, contact that plugin's or theme's developer, or switch to an alternative. The update itself happens through your host's settings, or your host can do it for you. WordPress's advice is to email your hosting company and ask them to help.

If something breaks, you can switch the PHP version back yourself or contact your host or web developer. If you restore a backup, ask your host to restore the previous PHP version first. Keep in mind that rolling back to an unpatched version puts your site back in the exposed group. Treat a rollback as a short-term fix while the broken plugin gets sorted out.

cPanel hosting

If your host gives you cPanel, its MultiPHP Manager is where you manage your account's PHP setup. It lists each domain with the PHP version it currently uses. To change a version, select the domain's checkbox, choose a version from the PHP Version menu and click Apply. Ask your host to confirm that the version you pick includes the October 21 fixes.

Google Cloud

If a developer built your site on Google Cloud, Google has published guidance for each of its services. App Engine standard apps on PHP 8.2 or newer are updated automatically and need no action. App Engine flexible apps are not updated automatically and need a redeploy. Cloud Run services with automatic base image updates are updated automatically, and others need a rebuild and redeploy. GKE workloads need updated container images and a redeploy. Google says unsupported runtimes will not be patched, and apps on PHP 8.1 or earlier stay vulnerable until they are upgraded to PHP 8.2 or newer.

Vercel

Vercel's runtime documentation lists its official function runtimes as Node.js, Bun, Python, Rust, Go, Ruby, Wasm, Edge and Container. PHP is not an official runtime. It can run through a community runtime called vercel-php or inside a container image. A Next.js site running on Vercel's Node.js runtime doesn't run PHP. If a Vercel project uses vercel-php or a container image with PHP in it, it needs a rebuild on a patched PHP release. Every site ASP manages on Vercel runs on Next.js or static pages, and none of them runs PHP. We checked each one on October 21.

Your own server or VPS

If you or your developer manage the server, the PHP project says Linux distributions and long-term support vendors received the patches in advance, so check your vendor for updated packages. For PHP 8.1 and older, some vendors provide backported fixes. The PHP security team also published minimal source backports for 7.4, 8.0 and 8.1 for people building from source or without an LTS vendor. If your server gets PHP from rpms.remirepo.net, the PHP project urges you to switch to distribution packages or build from source. It said on October 21 that the repository would not have updates that day.

Key Takeaway: On a typical hosting account, your host makes the change, and your job is a backup, a WordPress update and a written confirmation. On Google Cloud, Vercel and your own servers, the update can mean a rebuild, a redeploy or new packages.

How to fix the PHP vulnerability

The PHP project's release notes say there are no complete mitigations and updating is the only safe choice. The interim steps below reduce exposure to specific attack paths, but the project says they do not make an installation safe.

If a site can't be updated right away, the UK's National Cyber Security Centre urges organizations to consider taking offline any system that can't be fixed right away, as Help Net Security reports. Tenable reports that CERT-EU also recommends that organizations that can't update right away consider isolating internet-facing applications from public networks until a fix is applied and verified. For a small business website, that could mean asking your host to take the site down briefly instead of leaving an unpatched server online.

For your web developer or host

Hand this part to whoever manages your server. These steps come from the PHP project's announcement and the GitHub advisories, with notes from VirusTotal and Cloudflare. The project says they reduce exposure to specific attack paths but do not make an installation safe. Read the full advisory before you change anything.

• Memory and request size settings (CVE-2026-109618). Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration. Check that no pool, directory or application setting puts a finite limit back. Because -1 removes PHP's own memory cap, use a container or cgroup memory limit as an availability boundary, preferably with a policy that kills only the affected worker. This removes PHP's controllable memory limit failure, but an underlying allocation failure can still reach the vulnerable path. Set a low post_max_size: 8M for applications that don't need file uploads, or 32M if they do. Keep upload_max_filesize below post_max_size. Do not substitute RLIMIT_AS or RLIMIT_DATA, because these can cause the vulnerable allocation failure.
• Turn off upload progress (CVE-2026-109619). Set session.upload_progress.enabled=0 in php.ini, an FPM pool or server configuration that applies before request parsing, then restart every worker. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants. The feature has been part of PHP since 5.4.0 and is on by default, and turning it off only breaks upload progress bars that rely on it.
• On PHP 8.5, turn off fatal error backtraces. Set fatal_error_backtraces=0 and restart every worker.
• Block multipart requests the site doesn't use. If the application doesn't use multipart form data, block those requests before they reach PHP.
• Use a WAF, and close the bypass. Cloudflare has deployed an initial set of WAF rules for the known exploit vectors, available to all customers including free plans. Make sure the origin server isn't directly reachable, so the WAF can't be bypassed.

Key Takeaway: Only the PHP update fixes this. The interim settings and firewall rules buy time against known attack paths. Taking a site offline when it can't be fixed right away is the step the UK's NCSC urges organizations to consider.

What won't protect your site

Three common instincts don't help much here. The first is hiding your PHP version. Setting expose_php = Off hides the version header, not the vulnerability. VirusTotal found that roughly four out of five PHP servers already hide their version, and hiding it doesn't change whether the server is vulnerable.

The second instinct is hiding error messages, and that doesn't help either. The PHP project says hiding diagnostics with error_reporting, display_errors or the @ operator does not help.

The third instinct is to lean on a firewall. Cloudflare's rules are a useful layer, but Cloudflare itself calls them a stopgap. They only cover traffic routed through Cloudflare, and attackers can bypass them if the server can be reached directly. As Cloudflare's CTO put it, quoted in VirusTotal's write-up, only updating PHP fully protects a site.

PHP 8.2 end of life on December 31, 2026

Getting patched this week is the first step. The second step is making sure you don't end up on an unsupported version in a few months. PHP 8.2 reaches end of life on December 31, 2026, and will receive no further security fixes after that date. Here is the security support schedule from PHP's supported versions page.

If your host is moving you off 8.1 or 8.2 anyway, ask about going straight to 8.3 or newer so you only do the compatibility work once. A site that stays current is also a better base for a website that converts for a home service business.

This is also a good moment to confirm that you can get into your own hosting account. If you couldn't answer the checklist without calling someone, that's worth fixing. It's the same ownership question behind what to secure before you leave your marketing company.

Common questions

What is the PHP2Shell vulnerability?

PHP2Shell is the name given to two critical flaws in PHP, tracked as CVE-2026-109618 and CVE-2026-109619. They can let an attacker run their own code on a web server without logging in. One flaw involves how PHP handles running out of memory, and the other involves leftover data from an earlier request being used again. The PHP project released fixes on October 21, 2026, and urged all PHP users to update immediately. Exploitation attempts have already been reported.

How do I check what PHP version my website runs?

On WordPress, go to Tools, then Site Health, then the Info tab, and open the Server section, which shows information about your server and its PHP setup. If your host gives you cPanel, the MultiPHP Manager shows the PHP version each domain currently uses. If you can't find either screen, or you're not sure what your site runs on, ask whoever hosts or built it. Then compare your version to the fixed releases: 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

Which PHP versions fix PHP2Shell?

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. In PHP's own releases, any version below those in the same line is affected, such as 8.3.35 or 8.4.26. PHP 8.1 and older no longer get updates from the PHP project, although some Linux distributions and long-term support vendors provide backported fixes. If your server uses a vendor's PHP packages, ask the vendor whether its packages include the fix.

Is my WordPress site affected by the PHP vulnerability?

WordPress runs on PHP, so a WordPress site is in scope if its server runs an unpatched PHP version. Tenable reports that Calif says it confirmed pre-authentication remote code execution against specific versions of popular PHP applications, including WordPress. The fix is a PHP update on the server, and updating WordPress itself is not a substitute for it. Check your PHP version in Site Health and ask your host whether the server has a patched release.

Will hiding my PHP version or using a firewall protect my site?

Not on their own. Turning off the PHP version header hides the version number, not the vulnerability. Cloudflare has released firewall rules for the known attack methods, including on free plans, but it describes them as a stopgap, and they only cover traffic that passes through Cloudflare. If your server can be reached directly, attackers can go around the firewall. Updating PHP is the only complete fix.

What if my site runs PHP 8.1 or older?

PHP 8.1 and older no longer receive updates from the PHP project. Some Linux distributions and long-term support vendors provide backported fixes, so ask your host or vendor first. The PHP security team also published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP from source. The long-term answer is an upgrade to a supported version. Plan for 8.3 or newer, because 8.2 stops getting security fixes on December 31, 2026.

Next steps for your website

Find out whether your site runs PHP and check the version. Then get it onto 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or onto a vendor package that includes the fix. If you're on 8.1 or older, plan the upgrade now. If you can't update right away, have your web person apply the interim settings, and consider taking the site offline until it's fixed. After that, set a date to move off PHP 8.2 before December 31, 2026.

If you want a second set of eyes on what your website runs and who controls it, contact ASP and we can help you check.