PHP2Shell: Is Your WordPress Site at Risk? How to Check and Fix It

Disclosure: We may earn a commission when you buy through links on this page, at no extra cost to you. How we make money.

On October 20, details of two serious PHP bugs leaked on social media, two days before they were supposed to be announced. The PHP team rushed out an emergency release the next afternoon. By then attackers had already started probing servers, and Amazon’s honeypots had logged an exploit attempt four days before anyone outside the disclosure group was supposed to know.

Security researchers named the bugs PHP2Shell, because that’s what they give an attacker: a shell on your web server. If you run a WordPress blog, a WooCommerce store or anything else built on PHP, this one needs your attention this week.

The good news: for most people on shared hosting the fix is already in place, or will be soon, and checking takes about 15 minutes. This guide explains what PHP2Shell is in plain English, how to tell whether your site is safe, and exactly what to do if it isn’t.

What is PHP2Shell, in plain English?

PHP is the programming language that runs WordPress. Every time someone opens a page on your site, the server starts a PHP process, sets up the request (reading form data, uploads, cookies), runs WordPress, and then cleans up. PHP2Shell is two separate mistakes in that setup-and-cleanup routine:

• CVE-2026-109618, out-of-memory corruption. If PHP runs out of memory halfway through setting up a request, some of its internal data is left half-built. The cleanup code then treats that broken data as if it were valid. A carefully crafted request can turn that confusion into code execution.
• CVE-2026-109619, stale global state. Some internal data outlives the memory it points to. The next request handled by the same PHP worker can then act on leftovers from the previous one. This is a classic use-after-free bug, and it is linked to PHP’s session upload progress feature, which is switched on by default.

Both are rated 9.2 out of 10 on the CVSS v4.0 scale. What makes them so serious is the combination: no password, no plugin and no special configuration needed. According to PHP’s security team, on Apache with mod_php a single unauthenticated request can trigger the attack before any of your site’s code runs.

Why WordPress sites are squarely in the blast radius

Most WordPress vulnerabilities live in one plugin or theme, so only sites using that plugin are at risk. PHP2Shell is different. It sits in PHP itself, so it doesn’t matter which plugins you run, how strong your passwords are, or whether you’re on the latest WordPress version.

That also explains why the usual WordPress security advice doesn’t help here:

• Updating WordPress core, themes or plugins doesn’t change PHP. PHP is server software, managed by your host or by you on a VPS.
• Security plugins can’t reliably block it. Wordfence, Solid Security and the like run inside WordPress. The bug triggers while PHP is still setting up the request, before WordPress or any plugin has loaded.
• Maintenance mode doesn’t help either. The request still reaches PHP.

How PHP2Shell unfolded: the timeline

One caveat on “attacks in the wild”: security firms including watchTowr, Cloudflare and Amazon have reported exploit attempts, while CISA said at publication that it hadn’t yet seen a successful compromise. Don’t let that reassure you. Once a working exploit for a bug like this is out, mass scanning usually follows within days.

Am I affected? A quick answer for each type of hosting

Step 1: Find your PHP version (2 minutes)

In your WordPress dashboard, go to Tools → Site Health → Info, open the Server section and look at PHP version. Then compare it with this list:

If your number is at or above the patched version, you’re done with this step. If it’s lower, don’t panic yet: many hosts and Linux distributions apply the fix to their own builds without changing the version number. That’s what Step 2 is for.

Step 2: Confirm your host actually installed the patch

On shared and managed hosting you can’t patch PHP yourself. Switching PHP versions in your control panel just moves you between builds your host already has. So the question is simply whether those builds are fixed.

Two ways to check:

• Look at the PHP build date. Most panels have a “PHP Info” page (or you can see it in phpinfo()). A build date of October 21, 2026 or later is a good sign the fix is in. On Hostinger it’s under Websites → Dashboard → PHP Info.
• Ask support directly. Use the template below. “We have a firewall” isn’t the answer you’re after. You want “the patched PHP is installed and workers have been restarted.”

Here’s a short message you can paste into your host’s live chat:

Hi, I’d like to confirm my account is protected against PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Can you confirm that (1) the PHP version my site uses has been updated to a patched build, (2) PHP workers have been restarted since the update, and (3) whether my PHP version is end-of-life and I should upgrade? My domain is: ______. Thanks!

Where some big hosts stand (as of October 24):

• Hostinger says every plan except VPS was patched by October 22, across PHP versions 5.2 to 8.5, with extra firewall rules and session.upload_progress disabled server-wide. Shared, Cloud and cPanel customers don’t need to do anything. VPS customers do.
• cPanel (EasyApache 4) shipped fixed PHP 8.2 to 8.5 builds and backports for 7.4, 8.0 and 8.1. Hosts that depend on CloudLinux’s patched builds rolled out a little later.
• Other hosts are at different stages. If yours hasn’t posted a status page or emailed customers, ask.

Step 3: On a VPS or your own server: update and restart

If you manage the server, the clock is on you. Update PHP through your normal package manager (Ubuntu/Debian, AlmaLinux/Rocky, or your control panel’s updater). Distributions and LTS vendors got the patches before the public release, so packaged updates should already be available.

Then the step people forget: restart every PHP process. PHP keeps running the old, vulnerable code in memory until it’s restarted. Restart PHP-FPM (for example sudo systemctl restart php8.3-fpm, adjusting the version) or Apache if you use mod_php. Then run php -v and check your site’s PHP Info page to confirm the new build is live.

Can’t update right this minute? As a stopgap, set this in php.ini or your PHP-FPM pool config, then restart PHP:

session.upload_progress.enabled = Off

Hostinger notes that setting this with ini_set() in your code doesn’t work. It has to be in the server config. It also only blocks part of the attack surface: PHP itself says no configuration change fully mitigates these bugs. Use it to buy hours, not weeks.

Step 4: Stuck on PHP 8.1 or older? Upgrade now

PHP 8.1 and earlier are end of life, so php.net didn’t ship official releases for them. There are minimal source patches for 7.4, 8.0 and 8.1, and some hosts and commercial vendors have backported fixes. But that’s a lifeline, not a plan. And PHP 8.2 itself stops getting security fixes on December 31, 2026, so if you’re upgrading anyway, go to 8.3 or 8.4.

A safe upgrade routine for a typical WordPress site:

1. Take a full backup (files and database), and keep a copy off the server.
2. Update WordPress, every plugin and your theme. Old plugins are the most common reason a site breaks on newer PHP.
3. Switch PHP to 8.3 or 8.4 in your hosting panel. On Hostinger that’s Websites → Dashboard → PHP Configuration.
4. Test the pages that matter: homepage, a post, contact form, checkout if you sell anything, and the admin area.
5. If something breaks, switch back, find the plugin causing it (deactivate plugins one at a time), and replace or update it.

New to hosting panels? Our guide to starting a blog with Hostinger walks through the dashboard step by step.

Step 5: Check for signs that someone got in

If your server ran an unpatched PHP between October 17 and the day it was fixed, spend ten minutes looking for warning signs:

• Unknown admin users. Go to Users and filter by Administrator.
• Plugins you didn’t install, especially ones with generic names.
• PHP files in your uploads folder. wp-content/uploads should hold images and documents, never .php files.
• Spam pages in Google. Search site:yourdomain.com and look for casino, pharmacy or foreign-language pages you never wrote.
• Google Search Console → Security & Manual Actions → Security issues.
• Emails from your host about malware, spam sending or unusual resource use.

On a VPS, also check whether your PHP worker processes have been launching shells or downloading files. CISA specifically names this as something to watch for, and has published detection rules for it.

If anything looks off, don’t just delete the suspicious file. Ask your host to scan the account, restore a backup from before the infection, then change every password: WordPress, hosting, database and FTP/SFTP.

Do a firewall and Cloudflare help?

Yes, as a short-term shield. Cloudflare deployed WAF rules against known PHP2Shell exploit patterns for all customers, including the free plan, and CISA says a web application firewall “may offer some protection” until you patch. If your site already runs through Cloudflare, that’s a useful extra layer.

But WAF rules only match attack patterns someone has already seen. Attackers tweak their requests, and Cloudflare’s own CTO described the protections as temporary. Treat the firewall as a seatbelt, not as the fix.

The AI angle: why this bug is different

According to BleepingComputer, researchers at Calif, OpenAI and Wiz found the bugs. Wiz said the flaws had been sitting in PHP for a very long time, and that exploiting them used to require a long, complex chain of steps. In their words, “Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit.”

That’s the part worth thinking about beyond this week. AI tools are making it faster to find and weaponize old bugs in software everyone depends on. For site owners, the practical lesson isn’t fear. It’s to make “how fast does my host patch?” part of how you pick hosting, next to price and speed. It’s also one more reason not to leave sites on end-of-life PHP versions for years.

If you’re comparing hosts, our Hostinger review is a good place to start, and our explainer on AI agents covers how these tools work and where they fall short.

The 15-minute PHP2Shell checklist

1. Check your PHP version in Tools → Site Health → Info → Server.
2. Confirm the PHP build date is October 21, 2026 or later, or get written confirmation from your host.
3. On a VPS: update PHP, restart PHP-FPM/Apache, verify with php -v.
4. If you can’t update yet: disable session.upload_progress in server config and put the site behind a WAF.
5. On PHP 8.1 or older: back up, update plugins, move to PHP 8.3 or 8.4.
6. Look for unknown admins, stray plugins and .php files in uploads.
7. Make sure you have a recent backup stored somewhere other than your server.

Bottom line

PHP2Shell is about as serious as web server bugs get: unauthenticated, remote and present on nearly every PHP site. It’s also one of the easier ones to close. If you’re on decent shared or managed hosting, like Hostinger, which says all its non-VPS plans were patched by October 22, the fix is probably already in. A two-minute check confirms it. If you run your own server, update PHP and restart it today. Don’t wait for the weekend.

This story is still developing. Vendors are confirming affected products and PHP has disclosed a related issue, so we’ll update this guide as new details come in.

Sources: CISA alert, Hostinger, Help Net Security, BleepingComputer, watchTowr.

Frequently Asked Questions