PHP2Shell: Is Your WordPress Site Affected? What to Do Now

Last updated October 29, 2026: The first real-world break-in has been reported. Security firm Dream says an attacker used PHP2Shell, plus a separate Linux flaw, to take full control of 24 internet-facing firewalls and a firewall management server, including systems at a US government-affiliated organization. Those were firewall devices running old PHP 8.0.30, not websites. Wordfence, which protects more than 5 million WordPress sites, says that as of October 28 it knows of no WordPress site hacked through PHP2Shell. Attacks are still rising: a threat lab at Delft University of Technology has logged more than 67,000 PHP2Shell attack requests from 73 countries. On October 26, CISA, the US government’s cybersecurity agency, added both PHP2Shell flaws to its list of known exploited vulnerabilities and gave federal agencies until October 29 to fix them. On October 24, researchers confirmed attackers running commands on servers through PHP2Shell for the first time: decoy servers running unpatched PHP 8.4.26 recorded 35 successful attacks, using a published technique that gets past a key memory protection. The October 21 PHP updates fix the flaw. Also below: Qualys data showing 71% of PHP installs it can see run end-of-life versions, what attackers are trying to do to WordPress sites, the backdoor file names to look for, and our October 24 check of every site we host (all patched, no backdoors found). On October 23, PHP also disclosed a separate, less likely flaw (CVE-2026-115560), and every site we host already has the setting that blocks it. We will keep this post updated as the story develops.

A critical PHP vulnerability, nicknamed PHP2Shell, was patched on October 21, 2026, and attackers are already using it. It can let an attacker run their own code on a web server without logging in, and it sits in PHP itself, the language that powers WordPress, WooCommerce and most of the web. If your website runs on PHP, it needs a PHP update today.

Below is what happened, how to check whether your site is affected, how to update PHP in WordPress, and what we are doing for the 260+ websites we manage.

What is the PHP2Shell vulnerability?

PHP2Shell is the nickname for two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619, that can let attackers run code on a web server without logging in.

The PHP security team rates both flaws 9.2 out of 10 on the CVSS v4.0 scale and fixed them in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. In its official security advisory, PHP says the flaws “can allow unauthenticated remote code execution” and that all PHP users are “strongly encouraged to update immediately.”

The two flaws work differently. CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) happens when PHP runs out of memory partway through setting up a request, and the cleanup step then trusts data that was never finished. CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) leaves leftover data from one request behind after its memory is freed, so the next request on the same worker can pick it up.

The fix came out a day early. The details leaked on October 20, when a post on Hacker News claimed the disclosure was coming that Thursday. Security firm watchTowr confirmed the leak was real, and PHP moved the release up to October 21 at 14:00 UTC, according to Huntress and The Hacker News. Researchers at Calif and Wiz Research had reported the bugs to PHP in August, per Sansec’s timeline. The PHP2Shell name comes from the security community, not from PHP.

All this news has people asking whether PHP itself has a future. Our founder looked at that with data from 166 live sites: is PHP still relevant after PHP2Shell? (Short version: yes.)

Is my WordPress site affected by the PHP vulnerability?

Almost certainly, if your site runs on PHP and hasn’t been updated today. WordPress, WooCommerce, Drupal, Joomla and Magento sites are all exposed through the server’s PHP.

The problem is in PHP itself, so it doesn’t matter how clean or up to date your plugins are. PHP’s advisory says the risk covers “all PHP installations serving web requests,” including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It calls the risk highest for Apache’s mod_php, where a demonstrated exploit works before any of your site’s own code even runs. Patchstack reports that Wiz Research showed a working attack against the latest WordPress container images, and Sansec says the flaws affect every web server running PHP 5.4 or later.

Here are the versions that fix it:

If your site still runs PHP 8.1, 8.0 or 7.4, there is no official release to update to. PHP no longer supports those versions. The PHP team did publish minimal source fixes for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some Linux vendors backport fixes, but the safe move is to upgrade to PHP 8.3 or newer. Our guide to the latest PHP version lists when every branch loses support. WordPress itself recommends PHP 8.3 or greater.

Most of the web is still behind. Qualys looked at data from more than 10,000 of its customers, covering 156 million PHP installations with a known version. 110 million of them (71%) run end-of-life PHP, versions 5.4 through 8.1, and another 44 million run supported versions that hadn’t been patched yet. Only 199,000 were patched in the first 12 hours. If your site is on an old version, you’re in a very large crowd, and that crowd is exactly what attackers are scanning for.

Is PHP2Shell the same as WP2Shell?

No. WP2Shell was a WordPress flaw fixed in July 2026 by WordPress 6.9.5 and 7.0.2. PHP2Shell is in PHP itself, so no WordPress update can fix it.

The names are close, and search results mix them up. WP2Shell (CVE-2026-63030 and CVE-2026-60137) was a pair of bugs in WordPress core that BleepingComputer reported on July 18, 2026. The WordPress security team pushed forced automatic updates to fix it. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lives in PHP, the server software underneath WordPress, and the fix is a new PHP release installed by your host.

So a dashboard showing WordPress 7.0.2 or newer means you are covered for WP2Shell, but it says nothing about PHP2Shell. Check your PHP version separately, as shown below.

There’s now a third one to know about. CVE-2026-119977 is a separate WordPress core flaw that attackers are using during core updates. WordPress fixed it in 7.1.4 on October 28, and CISA listed it as actively exploited on November 3. Our guide to CVE-2026-119977 covers how to check your WordPress version.

Is there a new PHP vulnerability after PHP2Shell?

Yes. On October 23, PHP disclosed CVE-2026-115560, a separate and much less likely attack path. Turning off session upload progress blocks it until the next PHP release.

PHP posted an informational advisory two days after the PHP2Shell patch. It describes another remote code execution path that only opens up in an unusual setup: the application has to set session.serialize_handler to php_binary or php_serialize, switch it to php at runtime before starting the session, and still have session upload progress turned on. PHP says that “this setup is unlikely in practice,” so it will ship the fix in its next regular release instead of another emergency one.

Until then, PHP’s advice is simple: “We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release.” That same setting was already on the mitigation list for PHP2Shell. PHP’s October 21 advisory says to set it in php.ini, a PHP-FPM pool or the server configuration, and not to rely on ini_set() or a .user.ini file. On most shared hosting you can’t change that yourself, so ask your host whether it’s off.

Installing the PHP2Shell update does not cover this one on its own. Coverage from Techaeris and others notes it affects fully patched releases, including PHP 8.5.12. The setting is the protection until PHP’s next release.

Is PHP2Shell being exploited? Public exploits and confirmed attacks

Yes. CISA lists both flaws as exploited, and on October 26 Dream reported attackers taking over real firewalls with it. No WordPress site is confirmed hacked yet.

The volume is huge. Cloudflare saw tens of thousands of attempts 45 minutes after the flaws went public, hundreds of thousands within two hours, and millions by early October 22, according to The Hacker News. Sophos says a likely Mirai variant known as Potassium is trying to use PHP2Shell to load malware that can launch DDoS attacks, which means attackers want to turn unpatched web servers into part of a botnet.

The attacks haven’t slowed since the patch came out. The Delft Threat Intelligence Lab at Delft University of Technology publishes live PHP2Shell data from its honeypots and network telescope. As of October 27, it had logged 67,745 exploitation requests from 650 IP addresses in 73 countries, and 174 of those addresses sent attack code or a downloader for more malware. Its busiest hour so far was on October 26, five days after the fix, with 8,179 requests.

For the first few days, attempts were not the same as successful hacks. Wordfence, which protects more than 5 million WordPress sites, says its firewall had blocked over 74,000 attempts by October 22 and it has “not observed any confirmed compromises.” Sophos corrected an earlier report on October 22 and now says “there is no evidence of a successful compromise.” Some public exploit code may only work in a lab, Sophos adds. That buys you a little time. It doesn’t make an unpatched site safe, because the exploits keep improving.

That changed on October 24. Adel Karimi, detection and response lead at Perplexity, published packet captures and process logs showing 35 successful PHP2Shell attacks on three of his honeypots: disposable decoy servers running PHP 8.4.26 under single-worker Apache mod_php (his report). Attackers from two separate source addresses got the Apache web server to start shell commands, using what the report calls the “published leak-guided ASLR technique.” Malware researcher Marcus Hutchins of Expel told BleepingComputer it is “by far the highest quality confirmation of in-the-wild php2shell exploitation I’ve seen so far.”

Two caveats keep this in proportion. The decoys ran in what Karimi calls an “intentionally favorable” setup, and they ran an unpatched PHP version; the October 21 releases fix the flaw. But it shows that public exploit code now works against real, reachable servers, so an unpatched site is running on borrowed time.

The first real-world break-in followed. On October 26, security firm Dream reported that an attacker scanned about 19,000 internet-facing firewalls from one large vendor, then used a custom PHP2Shell exploit together with a Linux kernel flaw to take full control of 24 of them and an internal firewall management server. Two of those firewalls and the management server belonged to a US government-affiliated organization, where the attacker went on to probe the internal network. The victims were in the United States, Japan, Taiwan and South Korea. Dream doesn’t name the vendor or the organization, and says the evidence points to a China-linked operation without naming a group. The firewalls ran PHP 8.0.30, a version PHP stopped supporting years ago.

Wordfence’s October 28 update puts that in context for website owners: “As of October 28, 2026, Wordfence is not aware of any WordPress site compromised through PHP2Shell.” Its monitoring still recorded roughly 77,600 related requests from more than 2,000 IP addresses between October 23 and 27, and it warns that this does not make an unpatched server safe. The fix is still to update PHP.

Sansec, which first expected mass exploitation within minutes, revised its view on October 22: “The public exploits do not work against a default PHP installation.” Most of them need the site to already have a separate, serious bug that lets an attacker load local files. Sansec’s advice hasn’t changed, though: “Update PHP anyway.”

That gap is already closing. VulnCheck says its own exploit for CVE-2026-109618 achieved remote code execution on PHP 8.4.26 running on a standard x86-64 server with ASLR turned on and error display turned off, which it calls “the recommended production configuration.” As of October 23, it lists PHP 8.4.10 through 8.4.26 and 8.5.10 and 8.5.11 with default settings as covered. VulnCheck sells that exploit to its customers rather than publishing it, and says that of the hundreds of proof-of-concept projects that flooded GitHub, “only a very small number have been legitimate exploits.” It also warns that hiding errors with display_errors, error_reporting or the @ operator “does not help.” Expect attackers to get there too, which is why patching is the only real fix.

The fallout goes beyond the hacks themselves. The Hacker News reports that the UK had 32 government digital services offline and four partly offline, mostly from precautionary shutdowns, and that government, school and hospital sites went down across Asia, Europe and North America.

Amazon’s threat intelligence team spotted an attack attempt on October 17, four days before the fix was public, in its honeypot data while the flaw was still secret. Proof-of-concept exploits then appeared around 02:00 UTC on October 21, hours before PHP’s release, and more were published within hours of the patch. In Amazon’s own words, “PHP2Shell is now being broadly exploited in the wild.” Amazon also says it doesn’t yet know whether any of those attempts succeeded.

Amazon isn’t the only one seeing it. Security firm watchTowr says its honeypot network observed exploitation of both flaws in the wild on October 21. The US government has now caught up. On October 26, CISA added both CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog, its list of flaws known to be exploited, and gave US federal agencies until October 29 to deal with them. Both entries are also marked for CISA’s forensic triage requirements, so agencies are expected to look for signs of compromise, not just install the update. CISA had issued an alert on October 21 telling everyone to patch, but when it published that alert it hadn’t yet observed exploitation, as Tenable noted. Only federal agencies are bound by that deadline, but it’s a good one for everyone else to borrow.

Earlier reports from the day of the release:

• Patchstack logged “multiple active exploitation incidents” reported by hosting partners on the morning of October 21. By 13:57 UTC its own data showed “only probing attacks, with no hard evidence of breaches yet.”
• Sansec reports that Cloudflare saw early attacks against PHP sites on October 21. Cloudflare says its firewall rules went live at 03:02 UTC that day, about nine hours before the flaws were made public, on every plan including free. Cloudflare’s CTO called those rules a stopgap.
• Huntress had not seen exploitation in its partners’ environments as of October 20.

Sansec put it plainly: “We expect mass exploitation now that the patch and the writeups are public.” The UK’s National Cyber Security Centre is urging organizations to act immediately, and Help Net Security and Forbes are carrying the same warning. Attacks have started, so treat any unpatched site as at risk today.

What are attackers trying to do to WordPress sites with PHP2Shell?

Steal the passwords in wp-config.php and .env files, then plant a backdoor file such as wp2s.php in your uploads, plugins or themes folder.

Wordfence studied 10,000 attack requests from October 20 to 22 and published what the attackers run once they think they’re in. The most common payload tries to print the server’s environment variables and the first lines of .env and wp-config.php, the files that hold your database password and secret keys. Per Wordfence’s analysis, attackers are also trying to:

• Profile the server with commands like id, uname -a and hostname
• Write a PHP command shell named wp2s.php into a writable upload, plugin or theme folder, so they can get back in later
• Download and run a second-stage payload with curl or wget
• Check whether the attack worked by looking for markers like P2S_OK in the response

That’s why a patched PHP version is only half the job if your site was exposed for a while. If someone did get your wp-config.php, they have your database password even after you update. The next sections cover the update itself and how to look for the files attackers leave behind.

How do I update PHP in WordPress?

Check your PHP version under Tools, Site Health, Info, Server in WordPress, then update PHP through your hosting account or ask your host to do it today.

WordPress can’t update PHP by itself. PHP runs on the server, so the update happens at your hosting company. To update PHP in WordPress safely:

1. Find your PHP version. In your WordPress dashboard, go to Tools, then Site Health, then the Info tab, and open the Server section. WordPress’s Site Health documentation shows where this lives.
2. Compare it with the table above. Anything below 8.2.35, 8.3.36, 8.4.27 or 8.5.12 needs the update. Version 8.1 or older needs a move to a supported version.
3. Back up your site before you change anything, including the database.
4. Update PHP at your host. Most hosting dashboards have a PHP version setting. If yours doesn’t, or the fixed version isn’t offered yet, contact your host and ask when they will install the October 21 security release. Our step-by-step guide to updating PHP in WordPress has the exact menus for GoDaddy, Bluehost, SiteGround and other major hosts.
5. Test the site. Load the home page, log in, and submit a form. Moving up a major version can break an old plugin, so check the pages that matter most.

One catch: a version number alone doesn’t always tell you whether you’re patched. Some Linux distributions backport security fixes into older version numbers, so if your host uses distribution packages, ask them directly whether the fix for CVE-2026-109618 and CVE-2026-109619 is installed.

What if I can’t update PHP right away?

PHP lists a few settings that reduce the risk, but says they “do not make an installation safe.” Updating is the only real fix, so treat any workaround as a few hours of cover.

The PHP advisory lists partial measures for server administrators, such as turning off session.upload_progress.enabled, lowering post_max_size and changing how the memory limit is set. Some of these can break file uploads or let one request use all of a server’s memory, so they are a job for whoever runs your server. They are not something to paste into a plugin.

A few other options buy time:

• Cloudflare. Cloudflare turned its protection on automatically for every plan with its firewall, including the free plan, and it still tells customers to update PHP. The rules help only if your server accepts traffic exclusively from Cloudflare, Patchstack notes. If someone can reach your server directly, the rules can be skipped.
• Take a high-risk site offline. For an online store or a site holding customer data, a static maintenance page until the patch is in is the safest choice. Sansec warns that WordPress’s built-in maintenance mode does not help, because the attack happens in PHP before WordPress runs.
• Skip “fix” plugins and copied code snippets. Patchstack specifically warns against unofficial fixes. The flaw is in PHP, so nothing inside WordPress can patch it.

How can I check if my website is vulnerable to PHP2Shell?

Check your site’s PHP version. Anything older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 on its branch is vulnerable unless your host installed a backported fix.

There is no trustworthy online “PHP2Shell checker” for a site you run. The real test is the PHP version your site uses, and you can read it in a few places:

• In WordPress: go to Tools, then Site Health, then the Info tab, and open Server. Our guide to checking and updating PHP in WordPress walks through it with screenshots.
• In your hosting panel: cPanel’s MultiPHP Manager, Plesk, or your host’s PHP settings page shows the version each site is set to.
• From your host, in writing: ask “Is my site on PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later, or on a build with the PHP2Shell fix backported?” A good host answers that within a day.

One catch: Linux distributions such as Debian and Red Hat often patch their own PHP packages without moving to PHP’s new version number. Tenable says distributions got the fixes in advance, and it has released separate checks for Debian, Red Hat, Fedora and Gentoo packages. So a server can show an older-looking version and still be safe. Only your host can tell you which one you have.

And please don’t grab a “PHP2Shell” script from GitHub to test your own site. Recorded Future reviewed the public proof-of-concept code and found that “some rely on invalidated exploitation theories,” and that publicly available code “does not establish that it successfully exploits either vulnerability.” Pointing attack tools you haven’t vetted at the website that pays your bills is a bad trade when a version check answers the same question safely.

How can I tell if my site was hacked through PHP2Shell?

Look for server errors you can’t explain, unknown files or admin users, new scheduled tasks, and redirects or spam pages. If you find any of these, treat the site as hacked.

Huntress, Sansec and Patchstack describe these warning signs:

• File uploads or form posts followed by memory-limit errors or a run of 500 errors
• Unusually large or malformed PHPSESSID cookies in your logs
• PHP workers restarting for no clear reason
• Form uploads in your server logs (POST requests) that contain the text PHP_SESSION_UPLOAD_PROGRESS, the pattern Amazon tells defenders to search for
• New files in your site folders, especially PHP files you didn’t add (often a “webshell” that gives the attacker a back door). Wordfence lists wp2s.php, php2shell.php and files starting with axiom_ among its PHP2Shell attack indicators, so search your uploads, plugins and themes folders for those first
• New cron jobs or scheduled tasks, and admin accounts nobody created

If you see signs of a break-in, update PHP anyway, keep your server logs, and change every password and key the site holds: WordPress admins, database, hosting and any connected services. Then have the site properly cleaned. Restoring a backup only works if that backup was made before the attack. We cover how cleanups work, what they cost and why the cheap ones often miss things in our guide to fixing a hacked WordPress site.

What is Snazzy Solutions doing about PHP2Shell?

Every website we host is patched against PHP2Shell. All our servers had the fixed PHP builds by 17:52 UTC on October 21, less than four hours after PHP’s release.

We manage 260+ websites through our own hosting and agency partners.

We started checking every server within minutes of PHP’s release, so we knew which PHP version each site ran. We installed PHP 8.2.35, 8.3.36 and 8.4.27 as each package source published them, then restarted PHP so no site kept running the old code. On October 22 we checked again: none of the 363 PHP processes running across our servers was still on a vulnerable build. On October 23 we checked a third time. Every site we host runs PHP 8.2.35, 8.3.36 or 8.4.27, and none of them runs PHP 8.1 or older.

On October 24 we checked a fourth time and went further. Every running PHP process on every server is still a fixed build, and we searched every site folder on all of our servers for the backdoor names Wordfence published. We found no wp2s.php or php2shell.php file anywhere, and no axiom_ files created since the attacks began.

Every site we host also has session upload progress turned off in its server configuration, the setting PHP recommends against both PHP2Shell and the newer CVE-2026-115560. We checked every site configuration on all of our servers on October 23 and again on October 24, and the setting is in effect on running sites.

When can your host actually install the fix?

Most web hosts don’t build PHP themselves. They install it from a package source, and the fix can’t go on a server until that source publishes it. We have been tracking the two sources most of our servers use:

So if your host runs LiteSpeed and says it is still waiting on the update, that is no longer true. The fixed lsphp builds have been out since October 21. Ask them to confirm the update is installed today, and lean on the temporary measures above until it is. You can see the PPA’s published versions on its Launchpad page.

If we host your website, directly or through one of our agency partners, you don’t need to do anything. Your site is already patched, and we are watching for the next update.

If your site is hosted somewhere else, ask your host today whether the October 21 PHP security release is installed. If you aren’t sure, or you think your site has already been hacked, send us a message. We clean hacked WordPress sites, update PHP safely, and can move you onto hosting we manage so the next emergency patch isn’t your job.

PHP2Shell FAQ

What should you do today?

Check your PHP version, get it updated, and look for signs of a break-in. With your host’s help it is usually a short job, and it closes a critical hole that attackers already know about.

If you’d rather hand it off, talk to us. We’ll check your site, tell you what we find, and fix it.