PHP2Shell is the name security researchers gave to CVE-2026-109618 and CVE-2026-109619, two critical flaws in PHP itself (CVSS v4.0 9.2 each) that let an attacker run code on a web server without logging in. They are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026.

Is PHP2Shell already being exploited?

It is disputed, as of 23 October 2026. watchTowr and Amazon report exploitation attempts, Amazon even broad exploitation. Germany's BSI says it knows of no successful exploitation at scale yet, and Sansec says the public exploits do not work against a default PHP installation. VulnCheck says it has a working exploit, available only to its customers. No successfully compromised site has been publicly confirmed. None of this changes what to do: update now rather than at your next maintenance window.

Has my hosting provider already patched PHP2Shell?

Most large hosts have. As of 23 October 2026, Hostinger, IONOS, STRATO, Host Europe, Hetzner, netcup and Mittwald report the fix installed on their shared and managed hosting, often without changing the PHP version number shown. A VPS, cloud or dedicated server is your job to update. Check your host's status page or ask support.

Does the PHP update clean a site that was already attacked?

No. The update closes the hole but removes nothing an attacker left behind, such as hidden PHP files or new admin accounts. Check for the signs listed in this guide; if you find any, the site needs cleaning and new passwords.

How do I find out which PHP version my website uses?

In WordPress, go to Tools → Site Health → Info and open the Server section. On other sites, check your hosting panel (MultiPHP Manager in cPanel, PHP settings in Plesk) or ask your host. A free outside check such as zybee.ai/php-check reads the version your server discloses, if it discloses one.

Does updating WordPress update PHP?

No. WordPress is written in PHP, but PHP itself runs on your server and is managed by your hosting provider or server administrator. Updating WordPress, themes or plugins does not change the PHP version.

Is it safe to switch to a newer PHP version?

Usually, if your themes and plugins are maintained. Old or abandoned plugins are the most common cause of problems. Make a backup first, test on a staging copy if your host offers one, and check the site after switching. Most panels let you switch back in a minute.

Why does php -v show a different version than my website?

A server can have several PHP versions installed. The command line often uses a different one than the web server or PHP-FPM pool that serves your site. For your website, the version your web server uses is the one that counts.

My server reports an old-looking version number. Is it unpatched?

Not necessarily. Linux distributions such as Debian, Ubuntu and Red Hat often keep the original version number and backport security fixes into their packages. Check your distribution's security tracker or ask your host whether the package includes the fix.

PHP2Shell: check and update your PHP version

Q: How can I tell whether the fix is really installed if the version number did not change?

Ask your host whether the PHP your site uses includes the fix for CVE-2026-109618 and CVE-2026-109619. You can also look at "Build Date" in phpinfo(): a date before 20 October 2026 almost certainly means the fix is missing. A later date is a good sign but not proof. On your own server, your PHP package's changelog lists the CVE numbers.

PHP2Shell is the name researchers gave to CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities in PHP that allow unauthenticated remote code execution (RCE). The PHP project fixed them on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Updating WordPress or your plugins does not fix them: the PHP version on your server has to change.

Update, 23 October 2026: whether PHP2Shell is being exploited is disputed: security firms report attacks, while Germany’s BSI knows of no successful exploitation at scale. Also new: more hosts done and how to tell whether the fix is really installed.

Update, 22 October 2026: Amazon Threat Intelligence saw a first exploitation attempt on 17 October, four days before the fix, and now reports broad exploitation. New in this guide: what major hosts have done and how to spot signs of an attack.

This guide shows how to find your PHP version, whether it is safe, and how to update on cPanel, Plesk, managed WordPress hosting or your own server. To check a domain from outside, use our free PHP2Shell check. Auf Deutsch: PHP-Sicherheitslücke prüfen und beheben.

What is PHP2Shell, and is my site affected?

What it is: two flaws in PHP itself, each rated 9.2 of 10 (CVSS v4.0) by the PHP project. A web request is enough; no login is needed.
Who is affected: according to the PHP project, any PHP installation that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. That covers most WordPress, WooCommerce, Shopware and Magento sites. The risk is highest with Apache mod_php.
Vulnerable versions: every release older than 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on those lines. PHP 8.1 and older got no official release. Sansec reports that the vulnerable code goes back to PHP 5.4.
Is there a public exploit? Writeups and exploit tools are public, but whether they work in practice is disputed (details below).

Sources: php.net security announcement, Sansec, watchTowr, Tenable FAQ (with Amazon’s findings).

Is PHP2Shell being exploited?

Researchers and authorities disagree. As of 23 October 2026, 09:00 UTC:

Who	What they say	Date
Amazon Threat Intelligence	First attempt against its honeypots on 17 October; now reports broad exploitation	22 Oct
Sansec (citing Cloudflare)	A wave of attacks from 07:43 UTC on 21 October, still before the fix	21 Oct
watchTowr	Exploitation of both flaws observed in its honeypot network	21 Oct
VulnCheck	Working exploit against PHP 8.4.26 with standard protections, customers only, not public	22 Oct
Sansec	”Mass exploitation of PHP2Shell is less likely than we expected on release day.” The public exploits do not work against a default PHP installation	22 Oct
BSI (Germany)	No successful exploitation at scale known yet	22 Oct

In short: attackers are trying, but no successfully compromised site has been publicly confirmed. That is no reason to wait. According to VulnCheck a working exploit already exists, and it could become public at any time.

More sources: watchTowr: PHP2Shell exploited, BSI warning v1.2 (German, PDF), The Register on VulnCheck’s exploit.

Step 1: Find your PHP version

Use whichever of these fits your setup. The answer you want is the version that serves your website, not just any PHP installed on the server.

WordPress: go to Tools → Site Health → Info and open the Server section. It shows the PHP version your site runs on.

cPanel: open MultiPHP Manager. It lists each domain with its PHP version. Some hosts show Select PHP Version instead.

Plesk: open the domain under Websites & Domains and go to its PHP settings (in newer Plesk versions under the Hosting & DNS tab). The PHP version is at the top.

Managed hosting: most managed WordPress and PHP hosts show the PHP version in the site’s settings or tools page. If you cannot find it, ask support. It is a one-line answer for them.

From outside: many servers announce their PHP version in a response header called X-Powered-By. Our free PHP check reads it for you and explains what it means. If your server hides it, that is good practice, and you will need one of the other methods.

On your own server: create a file with <?php phpinfo(); in your web root, open it in the browser, note the version, and delete the file straight away, because it reveals a lot about your server. Running php -v in a terminal shows the command-line PHP, which can differ from the version your web server uses.

Step 2: Check whether your version still gets security fixes

The PHP project maintains each version for a limited time. After that, newly found vulnerabilities are not fixed in that version anymore. The official list is on php.net’s supported versions page.

As of October 2026:

PHP version	Status	Security fixes until
8.5	Active support	31 December 2029
8.4	Active support	31 December 2028
8.3	Security fixes only	31 December 2027
8.2	Security fixes only	31 December 2026
8.1, 8.0, 7.x, 5.x	End of life	No official fixes

If you are switching lines anyway, pick 8.4 or 8.5 so you do not have to move again soon.

Being on a supported line is only half of it. You also need the latest release on that line. For example, PHP 8.4.20 is a supported line but misses the fixes in later 8.4 releases.

One exception: Linux distributions and long-term support vendors often keep the original version number and backport fixes into their packages. A server reporting an older-looking number (typically with a distribution suffix such as -1ubuntu or +deb12) may be patched. Your host or your distribution’s security tracker can confirm it.

Has my host patched it?

On shared and managed hosting, the provider usually applies the fix, often without changing the PHP version number you see, because they patch their own builds. As of 23 October 2026, 11:00 CEST, according to the hosts’ status pages and announcements:

Hostinger: fix installed on all hosting servers for PHP 5.2 to 8.5. VPS customers update themselves. (announcement)
IONOS: official PHP updates applied on all its own platforms; customers need take no action (resolved 13:03 CEST on 22 October). VPS and bare metal customers update themselves. (status)
Host Europe: all systems patched as of 15:30 CEST on 22 October. (FAQ)
Hetzner: web hosting and managed servers patched (PHP 5.6, 7.3, 7.4 and 8.0 to 8.5, the last two on 22 October at 06:32). Dedicated and cloud servers are yours to update. (status)
netcup: web hosting and managed servers patched and back online since 22:51 CEST on 21 October. (status)
Mittwald: fixed for nearly all PHP versions; no fix yet for versions below 5.6. (status)
Infomaniak: protective measures in place and some file-sending features restricted; no completion notice for web hosting found yet. (status)

German and Swiss hosts, including STRATO and ALL-INKL.COM, are tracked on our hoster status page (German). If your host is not listed, check its status page or ask support: “Have you applied the PHP2Shell fix (CVE-2026-109618/-109619) to the PHP version my site uses?”

How to tell whether the fix is really installed

If the version number stayed the same, you cannot see the fix from outside. Three ways to confirm it:

Ask your host whether the PHP your site uses includes the fix for CVE-2026-109618 and CVE-2026-109619. On shared hosting this is the only reliable answer.
Look at the build date: phpinfo() shows “Build Date” near the top. A date before 20 October 2026 almost certainly means the fix is missing. A later date is a good sign but not proof. Delete the phpinfo file straight away afterwards.
On your own server: your PHP package’s changelog lists the CVE numbers, for example apt changelog php8.2-fpm or rpm -q --changelog php-fpm.

A patched host protects you from the moment of the update. If your site ran unpatched before that, check for signs of an attack.

Step 3: Update PHP on cPanel, Plesk or WordPress hosting

Shared hosting and managed hosting

On most hosting, the provider installs PHP updates within a line (for example 8.4.26 to 8.4.27) themselves. You choose the line (8.3, 8.4, 8.5) in your panel.

If you are on a supported line: ask your host when the latest security release will be applied, or check your version again after a day.
If you are on PHP 8.1 or older: switch to a supported line. In cPanel, pick a newer version in MultiPHP Manager and click Apply. In Plesk, choose a newer version in the domain’s PHP settings and save. If the newer version is not offered, ask your host, or consider moving to a host that offers it.

Plesk servers

If your host runs Plesk for you, they apply the update; you only choose the PHP line for your domain. On your own Plesk server, Plesk says all PHP versions it ships are affected. Plesk’s advice is to update to the latest available version. Fixed builds:

PHP 8.5, 8.4, 8.3, 8.2: 8.5.12, 8.4.27, 8.3.36, 8.2.35 (Linux and Windows).
PHP 8.1, 8.0, 7.4 (end of life, Linux only): same version numbers (8.1.34, 8.0.30, 7.4.33); only builds from 21 October 2026 contain the fix. Check with /opt/plesk/php/8.1/bin/php -v, which shows the build date.
Plesk itself (sw-engine / plesk-engine): Plesk Obsidian 18.0.81 Update 4 or 18.0.80 Update 11.

Docker: official PHP images

The official php images on Docker Hub have tags for the fixed releases, for example php:8.5.12-apache, php:8.4.27-fpm, php:8.4.27-fpm-alpine, php:8.3.36-fpm and php:8.2.35-fpm (available since 21 October 2026). A running container does not update itself:

Pin or refresh the tag. Use FROM php:8.4.27-fpm, or keep FROM php:8.4-fpm and rebuild with a fresh pull: docker build --pull ., or docker compose build --pull followed by docker compose up -d.
Replace the running containers, not just the image on disk.
Check the version inside the container: docker compose exec <service> php -v.

Images built on PHP 8.1 or older get no fix. Move them to a supported line.

Your own server (VPS or dedicated)

Install updates from your distribution’s packages (for example with apt or dnf), or from the PHP builds you normally use.
Restart PHP-FPM or your web server afterwards. Running workers keep the old code in memory until they restart.
Check the version your website reports, not just php -v.

Before you switch to a newer PHP line

Updating within a line rarely breaks anything. Switching lines (for example 8.1 to 8.4) can, mostly because of outdated themes and plugins.

Make a backup of files and database.
Update WordPress, themes and plugins first. Remove plugins you no longer use.
Test on a staging copy if your host offers one.
Switch, then click through the important pages: home, contact form, checkout, login.
If something breaks, switch back in the panel and fix or replace the plugin that causes it.

Was my site attacked?

Amazon recommends looking for attacks from 17 October onward, not just from the patch date. Common traces of remote code execution:

Unknown PHP files, especially in upload folders such as wp-content/uploads that normally hold only images.
Recently modified files you did not change, such as index.php, wp-config.php or .htaccess.
New administrator accounts in WordPress or your shop that nobody created.
Unexpected redirects, spam pages showing up in Google, or warnings from your host about outgoing mail.

If you find any of these, updating PHP is not enough: the site needs cleaning, new passwords and possibly a restore from a clean backup. Your host can give you access logs going back to 17 October.

Using Rank Math PRO? Separately from PHP2Shell, Rank Math PRO 3.0.123 shipped with a backdoor on 15–16 October 2026, and updating to 3.0.124 does not remove it. How to check whether your site is affected.

Make it a routine

PHP publishes security releases several times a year, and each supported line reaches end of life eventually. Check your PHP version every few months and whenever a critical release is announced. Plan the move to a new line before your current one reaches end of life, not after.