PHP2Shell Vulnerability: Is Your WordPress Website at Risk? (CVE-2026-109618 and CVE-2026-109619)

Last updated: October 23, 2026

On October 21, 2026, the PHP team released emergency security updates for two critical flaws now known as PHP2Shell. The flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and each one scores 9.2 out of 10 on the CVSS v4.0 scale.

This is not a WordPress plugin bug. The problem sits inside PHP itself, the engine that runs WordPress and a huge share of the web. That means updating WordPress, your theme and your plugins will not fix it. The fix has to happen at the PHP level, usually through your hosting provider.

I’m Hamza, a WordPress developer, and I wrote this guide to explain PHP2Shell in plain language: what it is, who is affected, what to do today, and how to tell whether your site has already been attacked.

Quick answer: is my WordPress site affected by PHP2Shell?

Your site is vulnerable if it runs a PHP version older than the fixed release for its branch (8.5.12, 8.4.27, 8.3.36 or 8.2.35) and your host has not applied its own patch. If you are on PHP 8.1 or older, there is no official fix from the PHP project, so you need to move to a supported version or confirm that your host has backported the patch.

Being vulnerable does not mean you have been hacked. It means the door is unlocked, and you should lock it now.

What is the PHP2Shell vulnerability?

PHP2Shell is the nickname researchers gave to two flaws in the PHP core. The name points to the worst outcome: an attacker getting a “shell,” meaning the ability to run commands on your server. Security writers have compared the naming and the scale to Log4Shell.

Both flaws allow remote code execution (RCE). In simple terms, an attacker can run their own code on a vulnerable server, and no login is needed. They only have to reach a PHP page over the internet.

CVE	What goes wrong	CVSS v4.0
CVE-2026-109618	PHP runs out of memory partway through handling a request and is left with half-built internal data. The cleanup code then trusts that broken data. PHP’s advisory calls this “RCE via OOM corruption.”	9.2
CVE-2026-109619	A use-after-free bug: PHP can reuse stale data left behind by an earlier request that ended in a fatal error. PHP’s advisory calls this “RCE via stale global state.”	9.2

Researchers describe the technical path a little differently from each other, but the root cause is the same: PHP mishandles memory. Use-after-free means PHP touches a piece of memory after it has already been released, and attackers can sometimes steer what ends up there.

JFrog’s analysis also notes that one of the flaws can leak memory from a PHP worker. Depending on your setup, that memory could hold things like database credentials or API keys, which is why a successful attack could reach beyond your website files.

Why does a PHP bug matter for WordPress?

WordPress is written in PHP. Every page request on a WordPress site is handled by PHP code running on your server. A flaw in the engine therefore reaches WordPress, WooCommerce, Elementor sites and custom PHP projects alike, even when their own code is clean.

Researchers at Calif, as reported by Sansec, showed that an attacker without a login can run code on a long list of PHP applications, including WordPress, Drupal, Joomla, Magento and phpMyAdmin. Huntress also points to control panels such as cPanel and Plesk, and to appliances with embedded PHP. Figures cited by IT Daily put PHP at around 69 percent of all websites, which is why this one got attention so fast.

The affected server setups include PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. Researchers rate mod_php as the highest risk, but PHP-FPM is not safe either.

The vulnerable code is old. According to Sansec, it goes back to PHP 5.4, released in 2012.

Is PHP2Shell being exploited right now?

Yes, according to several security firms. watchTowr reports seeing exploitation of both CVEs in the wild. Amazon Threat Intelligence says its honeypot network recorded an exploitation attempt on October 17, 2026, four days before the public disclosure.

There is some disagreement about how easy it is. Datadog reproduced the memory corruption on PHP 8.5.11 with an unauthenticated POST request. Sansec, on the other hand, tested public proof-of-concept exploits and found that they did not work against a default PHP installation, and that most needed the target application to have a separate local file inclusion bug.

My advice: treat this as urgent, but not as a reason to panic. Attackers move quickly after a disclosure like this, and PHP’s own release notes state that there is no complete mitigation. Updating is the only safe choice.

Which PHP versions are affected?

All PHP versions below the fixed release of their branch are affected. The fixed versions were released on October 21, 2026.

PHP branch	Update to	Support status
PHP 8.5	8.5.12 or later	Active support until Dec 31, 2027
PHP 8.4	8.4.27 or later	Active support until Dec 31, 2026
PHP 8.3	8.3.36 or later	Security fixes only, until Dec 31, 2027
PHP 8.2	8.2.35 or later	Security fixes only, ends Dec 31, 2026
PHP 8.1, 8.0 and 7.4	No official fix	Not supported by the PHP project
PHP 7.3 and older (including PHP 5)	No fix available	Not supported

You do not need to jump to a new major version. Stay on the branch you already use and move to its latest patch release. On PHP 8.3 and 8.2, the update contains only the security fix.

Your host may still protect an older version. Some hosting providers and Linux vendors backport security patches without changing the version number, so the number shown in WordPress may look old even though the fix is in. Ask your provider and get a clear answer in writing for each site.

Vulnerable website vs. hacked website

These two situations are different, and mixing them up leads to bad decisions.

A vulnerable website runs a PHP build that has not received the fix. Nothing has necessarily happened to it yet.

A compromised website is one where an attacker has already gained access or changed something. Updating PHP closes the entry point, but it does not remove a backdoor that someone has already installed. If you suspect an attack, updating alone is not enough. You also need to investigate and clean up.

How to check your PHP version in WordPress

1. Log in to your WordPress dashboard.
2. Go to Tools > Site Health > Info.
3. Open the Server section and find “PHP version.”
4. Write down the full version number, for example 8.4.26.

If you have SSH access, you can run php -v for the command-line version. Keep in mind that the command-line PHP can differ from the PHP your website actually uses, so trust the Site Health result or your hosting control panel for the web version. If your server has more than one PHP version installed, check each one, including versions your sites do not currently use.

How to secure your WordPress website from PHP2Shell

1. Contact your hosting provider

Ask two direct questions. Is the PHP runtime used by my site patched against CVE-2026-109618 and CVE-2026-109619? And if not, when will it be? On managed hosting, ask them to apply the update for you.

Don’t assume automatic updates already took care of it. Laravel’s Forge documentation, for example, points out that its automatic security updates do not patch PHP, because PHP comes from a separate package repository.

2. Back up, then update PHP

Take a full backup of your files and database first. Then update PHP through your hosting control panel (for example a PHP version selector) or ask your server administrator to do it. On a VPS, update the PHP packages for every installed PHP version and restart or reload PHP-FPM or your web server so the new version is actually the one running.

Test your theme, plugins, WooCommerce, Elementor and any custom PHP code on a staging copy when you can. Do not delay an urgent security patch while waiting for routine maintenance, though. A short test is better than a long delay.

3. Use stopgap settings only if you control the server

If you cannot update right away and you manage the server yourself, some providers suggest temporary hardening. Examples include disabling PHP’s upload progress tracking (session.upload_progress.enabled = 0), turning off fatal error backtraces (fatal_error_backtraces = 0) and lowering request size limits.

Treat these as a short-term bandage. They make an attack harder but do not fix the flaw. Some vendors also suggest setting memory_limit = -1. That removes PHP’s memory ceiling, so only do it if you have other limits in place, such as container memory limits. If you are on shared hosting, leave server settings to your provider.

4. Check for signs of compromise

Look at the following, especially if your site was online and unpatched since October 17:

• New administrator accounts that you did not create
• Unfamiliar PHP files, especially in wp-content/uploads, wp-content/cache and wp-content/plugins
• Plugins you do not recognize, or recently modified files in places where nothing should have changed
• Odd scheduled tasks (WordPress cron events or server cron jobs)
• Strange processes on the server and spikes in CPU use
• Web server logs showing unusual POST requests, particularly large uploads
• Unexpected changes to wp-config.php

If you find something, take the site offline or isolate it, keep a copy of the logs, restore from a clean backup, and then change every secret the server could have seen: WordPress passwords, database password, salts and keys in wp-config.php, API keys and hosting or FTP logins.

5. Keep the rest of WordPress tight

Keep WordPress core, plugins and themes updated. Turn on two-factor authentication for admin accounts, keep tested off-site backups, use sensible file permissions, and remove plugins and themes you no longer use. A reputable web application firewall (WAF) is a good extra layer, and some WAF providers have published rules for this issue. It is still an extra layer. PHP’s own release notes say updating is the only complete fix.

6. Verify the fix

After the update, confirm the PHP version again in Site Health, make sure your key pages, forms and checkout still work, and keep watching your logs and security alerts over the next few weeks.

Don’t confuse PHP2Shell with wp2shell

The names are close, and people are already mixing them up in search results. “wp2shell” is a different issue: a WordPress core vulnerability chain (CVE-2026-63030 and CVE-2026-60137) disclosed in July 2026 and fixed in WordPress 6.8.6, 6.9.5 and 7.0.2.

PHP2Shell is a PHP engine problem, so it needs a PHP update. wp2shell is a WordPress core problem, so it needs a WordPress update. If you maintain WordPress sites, you should have both fixed.

What this means if you manage many websites

If you look after several client sites, do not assume they are all safe because they share a host. Each environment can run a different PHP version, and a staging site or an old subdomain is easy to forget. Make a simple list with the site, the PHP version, the host’s patch answer and the date you verified it. Agencies and freelancers can use that list to show clients that the issue has been handled.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name for two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619. They can allow an attacker to run code on a server without logging in. PHP released fixes on October 21, 2026.

Is my WordPress website vulnerable to PHP2Shell?

It is if your site runs a PHP version older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 for its branch, and your host has not backported the fix. Check your version in Tools > Site Health > Info > Server, then ask your host.

Does a vulnerable PHP version mean my site is already hacked?

No. Vulnerable means the flaw exists on your server. Hacked means someone has used it. You should still update quickly and check for signs of compromise, because updating PHP does not remove a backdoor that was already planted.

Which PHP version fixes PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 contain the fixes. PHP 8.1, 8.0, 7.4 and older have no official fix, so use a supported version or confirm a backport with your host.

Can a security plugin or firewall protect me from PHP2Shell?

They can add a layer of protection, but they do not replace the PHP update. The flaw is in PHP, below WordPress, so a plugin cannot fully remove it.

Do I have to update WordPress plugins to fix PHP2Shell?

No. Plugin updates are still good practice, but they do not fix this issue. The fix is a PHP update.

Is PHP2Shell being exploited in the wild?

Yes, several security firms report exploitation, including attempts recorded before the public disclosure. Researchers disagree on how easy it is to exploit a default setup, so the safe move is to patch.

How do I know if my WordPress site was compromised through PHP?

Look for unknown admin users, unfamiliar PHP files or plugins, recently changed files, odd scheduled tasks and unusual log entries. If you find any, restore from a clean backup and change all passwords and keys.

Final thoughts

Website security does not begin and end with a security plugin. It covers the whole stack: PHP, the web server, WordPress core, plugins, themes and hosting. PHP2Shell is a reminder that the layer under WordPress needs the same attention as the plugins on top of it.

Today, check your PHP version, ask your host for a clear answer, update, and then look for signs of compromise. If you would like me to review your site or your hosting setup, you can get in touch through my contact page.

Two questions for the comments: have you checked the PHP version on your WordPress site yet? And if a site runs a vulnerable PHP version, does that mean it is hacked, or that it is at risk?

Sources and further reading

• PHP 8.5.12 release announcement
• PHP news archive
• watchTowr analysis and FAQ
• Datadog Security Labs
• Sansec research
• JFrog Security Research
• Help Net Security
• Tanium response guide
• Laravel Forge PHP security release notes