PHP2Shell: How to Check Whether Your Server Is Vulnerable and Patch It

PHP2Shell is the name given to two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, that let an attacker run code on a web server with a single unauthenticated request. PHP released fixes on 21 October and exploitation attempts are already widespread. For the background, see our news report. This guide covers the practical side: how to tell whether a server is exposed and what to do about it.

Step 1: find which PHP version you run

On a server you control, run:

php -v

This shows the command-line version, which is usually but not always the same as the one serving web pages. To see the version the web server uses, check the PHP-FPM service, for example php-fpm -v or the versioned binary such as php-fpm8.3 -v. On servers with several PHP versions installed, check each one that serves a site.

On shared hosting, the version is usually shown in the hosting control panel, often under a setting called PHP version or PHP selector. A WordPress site shows it under Tools, then Site Health, then Info, in the Server section.

Step 2: compare with the fixed versions

Your branch	Fixed in	What to do
8.5	8.5.12	Update
8.4	8.4.27	Update
8.3	8.3.36	Update
8.2	8.2.35	Update, and plan a move: 8.2 reaches end of life on 31 December 2026
8.1, 8.0, 7.4	No official release	Use your distribution's or LTS vendor's patched package, apply PHP's minimal backport, or upgrade
7.3 and older, including PHP 5	No fix	Upgrade to a supported branch

Linux distributions often keep their own version numbering and backport fixes without changing the main version. On Debian, Ubuntu, Red Hat and similar systems, check your distribution's security notices for the package version that includes the PHP2Shell fixes, rather than relying on the number alone.

Step 3: update and restart

Install the update through your package manager or hosting panel, then restart every PHP worker. PHP's advisory is explicit that a fix does not take effect until running workers are restarted. In practice that means restarting PHP-FPM, Apache if PHP runs as an Apache module, or the application server for setups such as FrankenPHP.

Servers running PHP as an Apache module (mod_php) should go first, since PHP rates that setup the highest risk.

Shared hosting and managed WordPress

On shared hosting and managed WordPress plans, the hosting provider controls PHP and has to apply the fix. Check your host's status page or announcements for PHP2Shell, and contact support if there is nothing. If the control panel lets you choose the PHP version, picking a newer branch only helps if the host has also installed the patched build of that branch.

WordPress plugins and themes cannot fix this. The flaws are in PHP itself and are triggered before WordPress code runs.

If you cannot update yet

• Reduce exposure. Restrict internet access to servers that cannot be patched. The UK's NCSC advises taking unpatchable systems offline.
• Put a web application firewall in front. Cloudflare has deployed rules for known exploit paths on all plans, including the free tier. A WAF reduces risk but does not fix the flaw.
• Apply PHP's interim settings. Set session.upload_progress.enabled=0 in php.ini or the FPM pool configuration (not through ini_set() or .user.ini), and on PHP 8.5 also fatal_error_backtraces=0, then restart the workers. PHP says these block the confirmed attack paths but not other variants, and do not make a server safe.

Step 4: check whether you were hit

Exploitation attempts were recorded before the fixes were public, so a server that was exposed before patching should be checked. Searchlight Cyber's open-source php2shell-scanner tests hosts for both flaws. Beyond that, look for the usual signs of a web server compromise: PHP files you did not put there, especially in upload and cache directories, unfamiliar processes or scheduled tasks, new admin accounts in your applications, and unusual outbound connections from the server.

If you find signs of compromise, patching alone is not enough. Rebuild the server from a clean state, restore content from a backup taken before the compromise, and change every password and key the server held.

Don't forget appliances

PHP also runs inside network devices and other products. Palo Alto Networks has confirmed that PAN-OS and Panorama are affected, and other vendors were still checking their products at the time of writing. Watch for advisories from the vendors of any appliances you run.