PHP2Shell: Two Critical PHP Flaws Get an Emergency Patch Today (CVE-2026-109618)

The PHP security team is shipping an emergency release today, Wednesday, October 21, 2026 at 14:00 UTC (10:00 a.m. ET) to fix two vulnerabilities it rates 9.2 (Critical) under CVSS v4.0. Researchers are calling the pair PHP2Shell and tracking them as CVE-2026-109618 and CVE-2026-109619. Details leaked before the fix was ready, Cloudflare says it is already seeing early attacks, and PHP runs most of the web, WordPress included. This is a patch-the-same-day event.

We're updating this post as the release lands and as hosts confirm their rollouts.

Live Updates

All times UTC.

• Oct 21, 13:20: Post published. PHP's release is still scheduled for 14:00. Kinsta has not posted a public notice on its status page or changelog yet. Every site TopSyde hosts runs PHP 8.2 or newer: still vulnerable until patched, but on branches that receive the fix.

What We Know So Far

Confirmed by PHP. On October 20 the PHP project posted an advance notice of a security release for October 21 at 14:00 UTC. It covers two vulnerabilities, each scored 9.2 under CVSS v4.0, and asks every PHP user to be ready to upgrade the moment it's out. The notice says PHP may release earlier if details go public or exploitation appears. It does not name affected versions, fixed versions, or the vulnerable component.

Reported by researchers, not yet confirmed by PHP:

• The leak. On October 20 a Hacker News post claimed two PHP remote code execution bugs were due for disclosure on Thursday, October 22. It was taken down, but screenshots spread. Security firm watchTowr then confirmed the bugs were real and under embargo until Thursday, and PHP moved its release up a day. (The Hacker News, Huntress)
• The CVE IDs. CVE-2026-109618 and CVE-2026-109619 came out of the leak. CERT-EU used them in its advisory; PHP's notice does not. (Tenable)
• Remote code execution. watchTowr says both bugs allow an attacker to run code on the server, and says it has reproduced CVE-2026-109618. A short exploit video credited to researchers at Calif.io circulated and was pulled. (Tenable)
• Early attacks. Cloudflare's CTO said the company is seeing early attacks and has pushed WAF rules for known exploit paths to every Cloudflare customer, free plans included. He called the rules a stopgap and told everyone to patch at 14:00. (Tenable, Sansec)
• Scope. The leaked post claimed every PHP version from PHP 5 onward is affected, and the exploit video references PHP 5.4.0 and later. CERT-EU says the same range could be affected. Treat that as possible until PHP publishes its list.

One more warning from Tenable: code claiming to exploit PHP2Shell is already circulating, none of it verified, and some of it may be malware aimed at the people running it. Don't download "test scripts" to check your own server.

Which PHP Versions Get a Fix

Being on a current version does not make you safe. Every branch below is presumed vulnerable until it runs the patched build; the only difference is whether a patch exists for it. PHP only ships security fixes for supported branches. Today that's 8.2 through 8.5. Pre-release trackers (Kevin Beaumont, Alpine Linux) expect these version numbers. They are not confirmed until PHP publishes them:

The current builds before today's release are 8.5.11, 8.4.26, 8.3.35 and 8.2.34. If you see one of those after the release, you're still unpatched.

If you're on PHP 8.1 or older, the fix is an upgrade to a supported branch. Some Linux distributions and hosts backport security fixes to older PHP builds, so ask yours, but don't plan on it. Our PHP version guide for WordPress covers what moving up involves and how to test plugins first.

How to Check Your WordPress Site's PHP Version

1. In wp-admin, go to Tools → Site Health → Info.
2. Open the Server section.
3. Read the PHP version line. You need the full number (for example 8.3.36), not only the branch.

If you can't get into wp-admin, your hosting dashboard usually shows the PHP version per site. Over SSH, php -v reports the command-line build, which is not always the same build serving web traffic, so trust Site Health for the site itself.

What to Do Today, in Order

1. Find out who patches your PHP. On shared or managed WordPress hosting, your host controls the PHP binary and you can't patch it yourself. Ask them directly when the fixed build reaches your site, and check the version afterward instead of assuming. On your own VPS or server, plan to update shortly after 14:00 UTC. Sansec notes that Remi's repository, a common source of PHP packages on RHEL-family servers, will not publish updates today, so you may need your distribution's packages or a source build.

2. If you're behind Cloudflare, make sure attackers can't go around it. Cloudflare's emergency rules only see traffic that passes through Cloudflare. If your origin server answers requests from any IP, an attacker who finds the origin address skips the rules entirely. Restricting the origin firewall to Cloudflare's IP ranges closes that gap.

3. Know what the stopgaps cost. Sansec lists blocking multipart/form-data requests at the web server as an interim measure. That also breaks file uploads, media library uploads and some checkout and contact forms, so it's a short-term trade, not a setting to leave on. The .htaccess versions of this rule circulating today only work on Apache. Hosts that serve WordPress on nginx, Kinsta among them, ignore .htaccess entirely, so on those the rule has to go in the server config or the WAF in front of it. Turning off session.upload_progress.enabled and turning on session.use_strict_mode was also suggested, but PHP's own developers have said ini settings won't save you and patching is the only mitigation.

4. Upgrade anything on PHP 8.1 or older. No patch is coming for those branches. If a site can't move today, consider taking it offline or behind a firewall until it can.

5. After patching, check whether anyone got in first. Like any remote code execution bug, the patch closes the hole but evicts nobody. Look for:

• PHP files you can't explain in the web root, wp-content/uploads/ or wp-content/mu-plugins/
• Admin users and plugins nobody on your team added
• New cron jobs or scheduled tasks
• Web server or PHP-FPM processes starting shells or download tools (sh, bash, curl, wget), which is the pattern Huntress expects exploitation to produce

If you find any of that, treat the site as compromised and work through a full malware removal, then rotate database and admin passwords. Changing passwords while a backdoor is still in place just hands the attacker the new ones. We wrote about how that plays out in the reinfection cycle, and it's the same lesson as WP2Shell this summer: patching is step one, eviction is step two.

Why This One Is Different From a Plugin Bug

Most WordPress security news is about a plugin. You update the plugin, or deactivate it, and you're done. PHP2Shell sits underneath all of that. PHP is the language WordPress, WooCommerce and every plugin run on, and the reporting so far points to an attack that reaches PHP before your site's own code runs. That means no WordPress security plugin can block it, because the plugin hasn't loaded yet when the request is handled. The fix has to happen at the server.

That's also why the exposure numbers are large. Tenable cites estimates of more than 1.3 million internet-facing hosts potentially vulnerable, and The Hacker News reports roughly 884,000 hosts whose banners advertise PHP 8.1 or older, the branches with no fix coming.

What TopSyde Is Doing for Our Clients

If TopSyde hosts your site, this is where things stand:

• Every site we host runs a supported PHP branch (8.2 or newer). That doesn't mean they're unaffected. It means an official fix exists for every one of them, and none are stuck on an end-of-life version with no patch coming.
• PHP itself is patched at the hosting platform level. We're watching for the patched builds and will confirm the running PHP version on each site once they roll out, then post the result here.
• TopSyde Sentinel already scans every site daily for exactly what a remote code execution attack leaves behind: webshells, PHP files where they don't belong, rogue plugins and rogue admin accounts. Over the next several days we're watching that scan closely on every site.

You don't need to open a ticket or change anything. If you want to talk it through anyway, reply to any of our emails or open a ticket in the portal.

Not hosted with us? Our free scanner checks your site from the outside for signs of an infection. It can't see your PHP version or patch your server, but it will tell you if something is already wrong. If it finds something, our malware removal service cleans it up and finds how the attacker got in. Hosting with us, which covers PHP updates and Sentinel, starts at $89/mo per site.

Frequently Asked Questions

What is PHP2Shell?

PHP2Shell is the name researchers gave to two critical vulnerabilities in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. The PHP project rates both 9.2 under CVSS v4.0 and is releasing fixes on October 21, 2026 at 14:00 UTC. Public reporting describes them as remote code execution flaws that don't require a login.

Is my WordPress site affected?

Assume yes until PHP publishes its affected-version list with the release. If your site runs on PHP at all, and every WordPress site does, it needs the patched build. Check your exact PHP version under Tools → Site Health → Info → Server.

Can a WordPress security plugin protect me?

No. The flaws are in PHP, below WordPress, and the reporting so far suggests the attack is processed before any plugin loads. The fix is a PHP update on the server. A firewall in front of the site, like Cloudflare's emergency rules, can reduce risk for a few hours but is not a substitute.

I'm on PHP 8.1 or older. Will I get a patch?

Not from PHP. Branches 8.1 and older are end of life and are not expected to receive a fix. Some Linux distributions and hosts backport security fixes, so ask yours, but the reliable path is upgrading to PHP 8.2 or newer.

Does patching PHP remove an attacker who already got in?

No. The update stops new attacks. Webshells, rogue admin accounts, malicious plugins and stolen credentials planted before you patched are still there afterward. Check for them once you've updated, and rotate passwords after the cleanup, not before.

Colton Joseph

Founder & Lead Developer

20+ years full-stack development, WordPress, AI tools & agents

Colton is the founder of TopSyde with 20+ years of full-stack development experience spanning WordPress, cloud infrastructure, and AI-powered tooling. He specializes in performance optimization, server architecture, and building AI agents for automated site management.

LinkedIn