PHP2Shell:
What the PHP vulnerability means for your WordPress site

On October 21, 2026, the PHP project closed two critical security vulnerabilities. Their name: PHP2Shell. Attackers can use them to inject malicious code onto a web server without needing to log in.

Every website running on PHP is affected, whether it’s WordPress, a shop system, or a custom development. This hits practically all WordPress sites, because WordPress runs on PHP. Only a PHP update on the server can protect you. A WordPress update or a security plugin won’t help here.

The key facts at a glance

• Every PHP version from 5.4 (released in 2012) onwards is affected, even with default settings.
• The vulnerability is in PHP itself. WordPress, themes, and plugins are not the cause.
• The PHP project classifies both vulnerabilities as critical: 9.2 out of 10 points.
• The update must be installed by whoever operates the server. For managed or shared hosting, that’s your provider; for your own server, it’s you.
• Initial attack attempts were already seen before the patch was released.

What is PHP2Shell?

PHP2Shell is the collective name for two bugs in the PHP core, officially CVE-2026-109618 and CVE-2026-109619.

In the first bug, PHP runs out of memory during a request. During the subsequent cleanup, PHP continues working with half-created data. In the second bug, data from a request remains in memory even though it should have been deleted long ago. If the next request hits the same PHP process, it accesses these remnants.

For you, the result is what matters: with crafted requests, an attacker can execute code on your server. They don’t need a password. According to the PHP project, every installation that serves web pages is affected, whether PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, or LiteSpeed. The risk is highest with mod_php.

The discoverers at Calif demonstrated the attack on popular PHP applications, including WordPress 7.1.2, Drupal, Joomla, Magento, and Nextcloud, according to Sansec.

Why WordPress updates and security plugins won’t help here

The attack happens in PHP before WordPress even starts. Therefore, a security plugin, a plugin-level firewall, or a maintenance mode never even gets a chance to act. There is also no update button for this problem in the WordPress backend.

Only a new PHP version on the server can help. And that is in the hands of whoever operates the server.

Timeline: from leak to patch

All times in Central European Summer Time (CEST).

• August 1, 2026: The security firm Calif finds the vulnerabilities and reports them confidentially to the PHP team. Shortly after, Wiz Research also reports the bugs.
• October 20, 2026: Details leak onto the web prematurely. The PHP project moves the updates forward by one day; they were originally planned for October 22.
• October 21, 5:02 AM: Cloudflare enables protection rules, including on the free plan.
• October 21, 9:43 AM: Cloudflare reports the first attack attempts. No patch exists at this point.
• October 21, 4:00 PM: The PHP project releases the secured versions.
• October 21, 4:10 PM: All PHP versions on our hosting server are updated.
• October 21, 5:15 PM: Our customers receive an email with the status. They have nothing to do.
• October 21, afternoon onwards: Linux distributions follow suit. AlmaLinux and Ubuntu report “patches in progress” on October 21; the popular Remi repository has no updates on this day according to the PHP project.

Why speed matters: The patch makes the changes public. This allows attacks to be developed, and a ready-made tool is already circulating. Experts expect automated mass attacks. Every hour without an update is an hour your site remains vulnerable.

Am I affected? How to check your WordPress site’s PHP version

1. Check the PHP version: In the WordPress backend under Tools → Site Health → Info → Server, you can see which PHP version your site is running.
2. Compare with the secure versions: PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12, as well as all newer versions, are secured. But be careful: some Linux distributions apply the fix without changing the version number. So a lower number doesn’t automatically mean your site is open. When in doubt, ask.
3. PHP 8.1 or older? The PHP project no longer provides ready-made updates for these. Ask your provider if they have backported the fix, and plan the move to at least PHP 8.3.
4. Ask your host: A short email is enough: “Has the PHP update against PHP2Shell (CVE-2026-109618 and CVE-2026-109619) been applied to my website, and was PHP restarted afterward?” Pay attention to the answer. “We’ve enabled a firewall rule” is good, but it doesn’t mean “PHP has been updated.”
5. Look for signs of compromise: A backdoor installed before the update remains even after it. Check for unknown admin accounts or plugins, whether there are PHP files in the wp-content/uploads folder, if Google Search Console reports security issues, and if a Google search for site:ihredomain.de shows foreign pages.

What to do if your host hasn’t closed the vulnerability yet?

If you run the server yourself (VPS, cloud server, Docker), install the updated packages for your distribution and then restart PHP-FPM or Apache. The old code continues to run until the restart. For Docker, downloading the new image isn’t enough: the containers must be recreated.

Until the update is available, there are workarounds. Cloudflare’s protection rules apply even on the free plan. The PHP project also lists settings that make individual attack vectors more difficult, such as session.upload_progress.enabled=0 and smaller upload limits. However, the PHP team itself says this doesn’t make an installation secure. These measures only bridge the time until the update.

And if your host can’t give a clear status when asked? Then follow up or get support.

What we did for our customers

The PHP update was performed on our end on October 21 at 4:10 PM, ten minutes after release. Since then, all PHP versions on our hosting server have been secured.

The websites were briefly reloaded during the process. None went down. By 5:15 PM, all customers had an email with the status update in their inbox. They didn’t have to do a thing.

To learn why this happens so quickly with a Managed Service, read our guide Managed WordPress Hosting.

Conclusion

Experts consider PHP2Shell to be one of the most serious PHP vulnerabilities in years. It works without a login and affects almost every PHP installation. For you as a WordPress operator, the situation is still manageable. If your server is running a secured PHP version and you find no signs of compromise, you are on the safe side.

Not sure? Then ask your host today. Or let us take a quick look: The hosting check is free, and you’ll know today where your site stands.