PHP2Shell: Critical PHP Vulnerability, What WordPress Site Owners Must Do Now

As of 13 November 2026, 2:45 pm CET. Compromised WordPress websites are still not known: Wordfence had seen no such case by 28 October, and the German BSI sees no large-scale exploitation in Germany. New since 12 November: Check Point reports that from 30 October attackers used PHP2Shell against unpatched firewalls of its own through their Mobile Access portal and took over some of them (Check Point Research). This does not affect web hosting or WordPress, but it shows that devices with a web interface need their PHP update too. The security firm GreyNoise now counts 1,229 successful attacks on its deliberately vulnerable test systems from 24 attacker addresses, five of them on 12 November. Since 11 November the attackers have been downloading and starting a cryptocurrency miner (XMRig) on the server, on 12 November under the name xmrigMiner. If you have not updated PHP yet, do it now. There are no new PHP releases. Since 9 November Raidboxes has supplied the older PHP versions with security updates as well. The WordPress flaw in the upgrade process (CVE-2026-119977, fixed in WordPress 7.1.4) is still being attacked: by 5 November the Wordfence firewall had blocked over 240,000 attack attempts, and the US agency CISA has listed the flaw as actively exploited since 3 November. 7.1.4 therefore remains a must (section "Why a WordPress update does not help this time"). On 2 November Wordfence had already shown that a related flaw in the Brotli library on the server can be exploited through WordPress. I will update this post as soon as there is news.

PHP contains two critical security vulnerabilities, called PHP2Shell (CVE-2026-109618 and CVE-2026-109619). They let attackers run their own code on the server without logging in and take over the entire website, WordPress included. On 21 October at 14:00 UTC the PHP team released the fixed versions PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your WordPress website runs on an older version, PHP has to be updated today. Updating WordPress or the plugins is not enough.

What happened

Researchers, among them the company Calif, found the bugs in August and reported them to the PHP team. Before the updates were ready, details leaked to the public. The PHP team therefore issued an advance warning on 20 October and scheduled the updates for 21 October, 14:00 UTC. Both vulnerabilities are rated 9.2 out of 10 (CVSS 4.0).

Germany's Federal Office for Information Security (BSI, in German) warns that all known PHP versions back to at least PHP 5 are vulnerable and considers large-scale exploitation within a few hours of the updates likely. According to its own blog, Cloudflare saw attack traffic against its customers' websites before the release and watched attackers change their requests to get around its protection rules. The Calif researchers state that they exploited the bug against WordPress 7.1.2, Drupal, Joomla, Magento and Nextcloud, among others, without logging in.

Since the evening of 21 October, several public programs that claim to exploit the bugs have appeared on GitHub. According to Recorded Future, not all of them work, and how many websites have actually been taken over is still unclear. In the current version of its warning (version 1.2 of 22 October, in German), the BSI writes that it knows of no successful attacks at scale so far. Attack attempts started before the updates, though, and have increased since, largely automated. The BSI considers reports that the updates can be bypassed to be refuted: if you have updated, you are protected against these two bugs. For you, this means a server without the update is at risk not just in theory.

On 26 October the US cybersecurity agency CISA added both vulnerabilities to its catalog of known exploited vulnerabilities. Only vulnerabilities with evidence of exploitation go into that catalog. CISA has not published details of the attacks; US federal agencies must patch by 29 October.

The first successful attacks are now documented. A security researcher recorded 35 cases on honeypot servers running unpatched PHP 8.4.26 with Apache mod_php in which attackers used a publicly available exploit to run commands on the server (report on GitHub). The security firm Dream reports 25 compromised servers, Palo Alto Networks firewalls and management servers running the old PHP 8.0.30, where PHP2Shell was chained with a Linux kernel flaw (Dream Research, updated 29 October). The attack targeted the firewalls' management interface, and Palo Alto Networks has released its own updates (Palo Alto Networks advisory). Check Point also reported on 12 November successful attacks on unpatched firewalls of its own through their Mobile Access portal, starting on 30 October and chained with a second flaw (CVE-2026-123039) that gave the attackers full rights on the device (Check Point Research). The security firm GreyNoise counts 1,229 successful attacks on its deliberately vulnerable test systems by 12 November, 982 of them on 31 October, 36 on 4 November and, after a five-day pause, six on 10 November, three on 11 November and five on 12 November (GreyNoise). Since 11 November the attackers have been downloading the crypto miner XMRig to the server and starting it. Real websites are not included in that number, but it shows that working exploits are in circulation and still being used. Since 28 October CISA also lists this kernel flaw (CVE-2026-46300) as actively exploited. Wordfence, which says it protects over five million WordPress websites, knows of no WordPress website compromised through PHP2Shell as of 28 October. From 23 to 27 October it recorded roughly 77,600 attack requests from more than 2,000 IP addresses (Wordfence, 28 October). On its PHP2Shell situation page (in German) the BSI counts attack attempts in the tens of millions but so far sees no large-scale exploitation and no successful attacks with data theft in Germany. It also points out that routers, NAS drives and smart home hubs with a web interface can be affected too.

Is my WordPress website affected?

Very likely yes, until PHP on your server is updated. WordPress is written in PHP, so every WordPress website runs on PHP. In its security advisory the PHP team lists all PHP installations that serve web requests as at risk, whether through PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. The risk is highest with Apache and mod_php: there, the attack can be triggered before WordPress even starts.

How to see which PHP version your website uses: log in to WordPress and open Tools, Site Health, Info. The PHP version is listed in the “Server” section.

PHP version on your server	What it means
8.5.12, 8.4.27, 8.3.36, 8.2.35 or higher	Fixed. Still check whether anything suspicious happened before the update (see below).
8.2 to 8.5, but an older patch release	Vulnerable. The update must be installed today, by the host for hosting packages.
8.1, 8.0, 7.x or older	Vulnerable and no longer maintained by the PHP project. Move to PHP 8.2 or newer, unless your host explicitly provides a security fix for this version.

What you need to do now

1. Check the PHP version as described above and note it down.
2. Ask your host if your website is on a hosting package. Most hosts update PHP themselves and often report the status on their status page. A short email is enough: “Has PHP for my website already been updated to a version that fixes CVE-2026-109618 and CVE-2026-109619, and restarted?” The update only takes effect once PHP has been restarted.
3. Move to a supported version if your website still uses PHP 8.1 or older. According to php.net, only PHP 8.2 and newer are still maintained. You usually switch the version in your host's customer menu. Ideally go straight to PHP 8.3 or 8.4: according to the PHP team, PHP 8.2 only receives security fixes until 31 December 2026. Make a backup first: old plugins and themes do not always run on newer PHP. If the website then shows a critical error, follow the guide to the critical error.
4. Your own server: update your distribution's PHP packages and restart all PHP processes (PHP-FPM, Apache). The PHP team points out that the widely used rpms.remirepo.net repository had no updates on 21 October. If you use it, switch to your distribution's packages. Update the Linux kernel at the same time, because attackers chain PHP2Shell with the kernel flaw CVE-2026-46300.
5. Check for traces after the update (next section).

What hosts are reporting: German host IONOS writes in its help centre (in German) that it has installed the PHP update on its servers, including for versions the PHP project no longer maintains. If you choose your PHP version in the IONOS customer account, there is nothing to do. STRATO reports the same (including the older versions in its PHP Extended Support, in German), and All-Inkl announced the same on its homepage on 27 October (for all PHP versions it offers, including unsupported ones). Mittwald has patched all versions it runs from PHP 5.6 onwards, and Raidboxes first patched the versions from PHP 8.2 onwards and has since supplied the older ones with security updates as well (as of 9 November); it reports no compromised website so far. Hetzner had also patched PHP 5.6 and 7.3 on all its web hosting and managed servers by 28 October. It is different with your own server (VPS or dedicated server): there, the operator is responsible for the update. Ask other hosts whether they have published a similar notice. I would still plan the move away from PHP 8.1 and older, because whether a host patches old versions is a voluntary service.

Watch out for fake emails: IONOS warns that fraudsters are using the attention around PHP2Shell to send fake emails in the host's name to get hold of login details. Only log in via the address you type into the browser yourself, never via a link in such an email, and do not run scripts that someone sends you.

Is your website behind Cloudflare? Since 21 October, 03:02 UTC, Cloudflare has been filtering known attack patterns, including on the free plan, as long as its web application firewall (WAF) is active. Cloudflare itself writes that attackers are changing their requests and advises updating PHP anyway. It is an extra layer, not a replacement for the update.

For server administrators, the PHP team lists settings that make individual attack paths harder if an update is not possible right away. It states explicitly, however, that they do not make an installation safe. I would not rely on them. Since 23 October the PHP team has also advised setting session.upload_progress.enabled=0, even on updated servers, until the next regular PHP release. It concerns a third attack path (CVE-2026-115560) that the PHP team considers unlikely, because it only occurs with a rare combination of server settings and application code. If no update happens today, taking the website offline temporarily is the safe choice. According to German news channel n-tv, the city of Mainz and the University of Mannheim, among others, took their websites offline for this reason.

Why a WordPress update does not help this time

Most WordPress security warnings concern a plugin or WordPress itself, and one click on “Update” in the dashboard fixes the problem. This time the bug sits one level deeper, in PHP, the software on the server that runs WordPress. The security firm Sansec puts it plainly: the hole cannot be closed from within the website's code. Security plugins also come too late on Apache with mod_php, because the attack can take effect before WordPress starts.

That is why good WordPress maintenance covers more than plugin updates: someone also needs to know which PHP version the website runs on and to test a move to a new version on a test copy first.

WordPress updates remain a must all the same, not least because of a separate flaw in the upgrade process that WordPress 7.1.4 closed on 28 October (CVE-2026-119977). Older branches have their own fixes, such as 7.0.8, 6.9.11 and 6.8.12. Wordfence had blocked over 240,000 attack attempts by 5 November, with a peak of over 74,000 in a single day on 30 October. That sounds more dramatic than it is: an attack can only succeed in the short window while an update is running. The update to 7.1.4 itself runs through the old process one last time, though. Wordfence therefore advises not to postpone it and to block access to PHP files in the /wp-content/upgrade/ folder at web server level beforehand. The free version of Wordfence only gets the matching firewall rule on 27 November.

A WordPress update does not help against a related flaw that came up on 2 November either. It is not in PHP but in Brotli, a library for unpacking compressed data that the server's operating system supplies (CVE-2026-111497, listed as exploited by the US agency CISA since 27 October). Wordfence showed in its lab that attackers can run code through it without logging in, via WordPress's pingback feature (XML-RPC). Wordfence does not yet know of a successful attack on a real website. On the usual Linux servers, a WordPress or PHP update does not replace Brotli; your host has to do that. Only for PHP on Windows servers have there been new packages with a fixed Brotli since 26 October: 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1 (php.net). Ask them whether the Brotli library on your server contains the fix for CVE-2026-111497 and whether the services were restarted afterwards. On your own server, install the operating system update. Incidentally, the Wordfence setting that disables XML-RPC authentication does not block pingbacks.

How to recognise a successful attack

A PHP update closes the hole, but it does not remove anything an attacker left behind beforehand. So after the update, check for:

• new administrator accounts under Users that nobody created
• unknown PHP files, especially in the wp-content/uploads folder, which normally only holds images and documents. Wordfence advises paying particular attention to files created on or after 17 October.
• a file named wp2s.php in wp-content/uploads or in a plugin or theme folder. That is the name of the backdoor the attacks observed by Wordfence try to drop. The same attacks try to read the credentials in wp-config.php and the .env file.
• modified files in WordPress, the theme or plugins (a comparison with fresh original files shows this)
• redirects to unknown sites, spam pages in Google under your domain or browser warnings
• for administrators: repeated PHP worker crashes (SIGSEGV) and “Allowed memory size exhausted” messages in the server's error log, and upload requests in the access log that do not match any form on your website (pointers from the BSI and Wordfence)
• for administrators: requests from outside to PHP files under /wp-content/upgrade/ in the access log, especially setup-config.php, and leftover files or folders there. A normal update needs no such requests (Wordfence). This concerns the flaw in the upgrade process, not PHP2Shell itself.
• for administrators: a running process named xmrig or xmrigMiner, a file /tmp/xmrig or a folder /tmp/b109. That is the crypto miner attackers have been starting on GreyNoise test systems since 11 November.

Sansec also describes that one of the bugs can leak memory contents of other requests, including passwords, sessions and API keys. If your website was online unpatched, after the update I would change the administrators' passwords, renew the security keys in wp-config.php (this logs all users out) and replace access keys for connected services such as payment providers or newsletter tools.

If you find any of these signs, the website has probably been compromised. Then an update alone no longer helps, a clean-up does. In that case IONOS advises restoring a clean backup from before the attacks (early October 2026) and then resetting all passwords and access keys. If you need that, my WordPress support covers emergencies as well.

Frequently asked questions

Does WordPress use PHP?

Yes. WordPress is written in PHP and only runs with PHP on the server. That is why PHP2Shell affects every WordPress website until the server runs PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or newer.

Which PHP version is safe?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or later, released on 21 October 2026. PHP 8.1 and older no longer get new releases from the PHP project. For 7.4, 8.0 and 8.1 the PHP security team has only published fixes as source code, which Linux distributions and long-term support vendors can build into their own packages. Ask your host whether it has done so. Moving to PHP 8.3 or 8.4 is the safer choice.

Is it enough to update WordPress and the plugins?

No. The vulnerability is in PHP itself, the software WordPress runs on. It is only closed by a PHP update on the server. WordPress and plugin updates remain important, but they do not close this hole.

Does a WordPress update such as 7.1.3 or 7.1.4 protect me against PHP2Shell?

No. WordPress 7.1.3 came out on 6 October, WordPress 7.1.4 on 28 October. Both fix vulnerabilities in WordPress itself, 7.1.4 among them a weakness in the upgrade process that lets attackers run code during the upgrade. PHP2Shell sits in PHP, the software on the server. Only the PHP update helps against it. You should still install WordPress 7.1.4 right away: according to Wordfence, the upgrade-process flaw is under attack, with over 240,000 attempts blocked by its firewall by 5 November. An attack can only succeed while an update is running, so the number says little about websites actually taken over. Since 3 November CISA also lists this flaw (CVE-2026-119977) in its catalog of actively exploited vulnerabilities. You can check whether 7.1.4 is installed under "Dashboard > Updates". In which order to update WordPress, plugins and theme is in the guide Installing WordPress updates the right way.

Does a security plugin such as Wordfence help?

Not reliably. According to the PHP team, on Apache with mod_php the attack can be triggered before any application code runs. A plugin inside WordPress comes too late. Only the PHP update closes the hole.

Does Cloudflare protect me against PHP2Shell?

Partly. Since 21 October Cloudflare has been filtering known attack patterns, including on the free plan with the web application firewall active. Attackers are changing their requests to get around the rules, though. Cloudflare itself therefore recommends updating PHP anyway.

I use a hosting provider. Do I still need to do anything?

Yes: check whether your host has already updated. IONOS, STRATO and All-Inkl, for example, have installed the update for all PHP versions customers can choose there, old ones included. If your website still runs on PHP 8.1 or older, move to 8.3 or 8.4 anyway, because not every host patches old versions. On your own server (VPS) you have to update PHP yourself.

Should I take my website offline?

If your server cannot be updated today, taking it offline temporarily is the safe choice. Several German cities and universities took their websites offline on 21 October for exactly this reason. Once PHP is updated, the website can go back online.

Help if you get stuck

You do not know which PHP version your website runs on, your host does not answer, or something stopped working after the PHP switch? I will check it for you, install the update and test the website afterwards. Call +49 89 3288 6771 or write to me via the contact form.

Sources: PHP team security advisory with the technical details in GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, BSI press release and BSI warning version 1.2 (both German), CERT-EU, CISA and the IONOS help centre (German).