PHP Security Threats 2026: PHP2Shell Flaws Explained

The newest PHP security threats are not another plugin bug. On 21 October 2026 the PHP project shipped emergency patches for two critical flaws in PHP itself, nicknamed PHP2Shell. Both can let an attacker run code on your server without logging in. If your site runs on PHP, this affects you, and the fix is a server update, not a WordPress update.

I am Vijay, and I look after WordPress and PHP sites for clients. This guide explains both flaws in plain language, shows how to check your own site, and lists what to do today. If you would rather hand it over, my website security and maintenance service covers all of it.

Quick summary of the PHP security threats

• What: two critical PHP core flaws, CVE-2026-109618 and CVE-2026-109619, each scoring 9.2 on the CVSS v4.0 scale.
• Risk: unauthenticated remote code execution, meaning an attacker does not need a password or an account.
• Fixed in: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
• Not fixed upstream: PHP 8.1 and older, which are end of life.
• Status: security firms reported exploitation attempts within hours of the patch. No confirmed breaches had been reported in the sources I read.
• Action: confirm your PHP version with your host today and update it.

What is PHP2Shell and why do these PHP security threats matter?

PHP2Shell is the nickname for two critical remote code execution (RCE) flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. RCE means an attacker can run their own commands on your server. Because the bugs live in PHP, they can affect any PHP site, whether it runs WordPress, WooCommerce, Laravel or a custom app.

What happened: the PHP2Shell timeline

The story moved fast, which is part of why these PHP security threats matter so much. Here is the sequence according to security researchers and news outlets.

• 20 October: the two CVE IDs leaked ahead of a planned 22 October disclosure. PHP posted an advance notice that evening and pulled the release forward.
• 21 October, early: Cloudflare reported exploit attempts and switched on default firewall rules.
• 21 October, afternoon: PHP published the fixed releases and advisories. Shortly after, watchTowr reported active exploitation attempts against both CVEs.
• Since then: some organisations took systems offline as a precaution, though I found no report of a confirmed compromise.

Researchers say nearly every PHP version back to 5.4 is affected, which is why the coverage on The Hacker News calls this one of the broadest PHP disclosures in years.

PHP security threat 1: CVE-2026-109618

The first flaw is an out-of-memory corruption bug. When PHP fails to allocate memory, it can leave invalid data behind. PHP then processes that data during its own cleanup, and a crafted request can turn that into code execution.

Datadog Security Labs reproduced it on PHP 8.5.11 with a single unauthenticated POST request. Three details make it worrying:

• It runs during request cleanup, before your application code starts. Login pages, nonces and firewalls inside WordPress cannot stop it.
• Any PHP script can expose the vulnerable path, even a page that only prints text.
• A successful attack does not have to crash the PHP worker, so a site can look completely normal afterwards.

Turning off session upload progress does nothing for this one. Only the patched PHP releases fix it.

PHP security threat 2: CVE-2026-109619

The second flaw involves how PHP handles session upload progress, and it can run before PHP finishes setting up a request. Reports also describe a PHP worker reusing stale state from an earlier request. The public detail is thinner than for the first flaw, so I am not going to guess beyond what PHP and the researchers have published.

The practical point is simple. Security press reports say one of the flaws reaches code execution on both Apache with mod_php and PHP-FPM. PHP rates the risk highest on Apache with mod_php, where an attacker can trigger the problem before WordPress loads at all.

Is your site affected?

Almost certainly yes, unless your host has already patched. Use this table as a quick guide.

PHP branch	Status	What to do
8.5	Fixed in 8.5.12	Update to 8.5.12 or newer
8.4	Fixed in 8.4.27	Update to 8.4.27 or newer
8.3	Fixed in 8.3.36	Update to 8.3.36 or newer
8.2	Fixed in 8.2.35	Update to 8.2.35 or newer
8.1 and older	Affected, no upstream patch	Upgrade to a supported branch, or confirm a vendor backport

Some Linux distributions backport fixes without changing the version number. If your host says it is patched while the version looks old, ask which package changelog lists the two CVE IDs.

How to check your PHP version

1. Log in to your WordPress dashboard.
2. Go to Tools, then Site Health, then the Info tab.
3. Open the Server section and read the PHP version.
4. Compare it with the fixed releases in the table above.

On a VPS, run php -v over SSH. Remember that the command line version and the web server version can differ, so check both.

How to update PHP in cPanel or hPanel

Menu names vary by host, but the steps look similar on most control panels. Also, check that your host offers a patched release before you switch.

1. Take a full backup of your files and database first.
2. In cPanel, open MultiPHP Manager or Select PHP Version. In Hostinger’s hPanel, open your website and look for PHP Configuration.
3. Pick a supported branch, such as PHP 8.3 or 8.4, and apply it to your domain.
4. Load your site, then test key pages, forms and checkout, and check the error log.
5. If something breaks, roll back, update the plugin or theme behind the problem, and try again.

However, choosing a branch only helps if your host has installed the patched build for it. So ask your host to confirm in writing.

What to do right now about these PHP security threats

If you are on managed or shared hosting

Your host patches PHP for everyone. Check its status page, and ask for confirmation in writing if you cannot find one. Hosts patched at different speeds on release day, so do not assume.

If you run your own VPS or cloud server

This one is on you. Install the patched PHP packages, restart PHP-FPM or Apache, then verify the running version. If you use a third-party repository, check that it has published the fix before you rely on it.

If you are on PHP 8.1 or older

Plan the upgrade to PHP 8.2 or newer. Test on a staging copy first, because older themes and plugins can break. Both WordPress.org and the UK NCSC suggest taking a self-managed site offline if it cannot be upgraded or protected quickly.

Temporary hardening against PHP security threats

These steps narrow the risk while the patch is scheduled. They do not replace it. Security reports describe them as partial protection only, and I always check the exact values against PHP’s own announcement before changing a production server.

• Set session.upload_progress.enabled=0 and restart all PHP workers. WordPress does not use this feature, so the side effects are minimal.
• On PHP 8.5, also set fatal_error_backtraces=0.
• Keep post_max_size low and enforce request size limits at the web server or reverse proxy.
• Review memory limit settings with care. One report suggests a fixed memory limit that applications cannot override. Test this on staging first.

; php.ini (restart PHP-FPM or Apache afterwards)
session.upload_progress.enabled = 0
post_max_size = 8M
; PHP 8.5 only
fatal_error_backtraces = 0

Signs someone already tried it

Exploit attempts leave traces if you know where to look. Datadog lists a few indicators worth checking in your logs:

• Unusually large form submissions or POST requests.
• Memory exhaustion errors during request start-up.
• PHP processes starting shell commands you did not expect.
• New or changed PHP files in uploads, cache or theme folders.

If any of these appear, treat the site as possibly compromised. Take a backup of the current state, change all passwords and keys, and scan every file against a clean copy. My WordPress security consulting page explains how I handle that kind of investigation.

Why a firewall alone is not enough

Cloudflare turned on firewall rules by default, and that is useful. But attackers changed their payloads within hours to get around them. A firewall is a supporting layer. On paid Cloudflare plans, make sure managed rules are set to block, not just log, and still patch PHP.

PHP2Shell vs wp2shell: two different security threats

A separate issue called wp2shell hit WordPress core earlier this year. According to a CanSSOC advisory from July 2026, it chains two flaws, CVE-2026-63030 and CVE-2026-60137, and affected WordPress 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1.

Unlike PHP2Shell, you fix that one with a WordPress update. So you need both layers current: a patched PHP version on the server and an up-to-date WordPress core.

How I protect client sites from these PHP security threats

For the client sites I look after, my response to PHP security threats like PHP2Shell follows a set routine:

• Audit the PHP version on every site and server I manage.
• Get written confirmation from the host that the patch is applied.
• Apply interim hardening where a patch is delayed.
• Review server and access logs for the indicators above.
• Run a file integrity check and malware scan on WordPress core, plugins, themes and uploads.
• Test and upgrade any site stuck on PHP 8.1 or older, using staging first.
• Take a fresh backup before and after each change, then send a short written report.

The full list of what is covered, and how it works, is on my website security and maintenance page. If you want a quick check of your own site, get in touch, or browse my other WordPress services.

Keeping PHP security threats out for good

PHP2Shell will not be the last critical PHP bug. A few habits make the next one much less stressful:

• Run a supported PHP branch and plan upgrades before end of life, not after.
• Keep tested backups away from the server.
• Subscribe to your host’s status page and PHP’s security announcements.
• Remove unused plugins, themes and old PHP files.
• Use least-privilege file permissions and separate users per site.
• Schedule regular updates with a staging check, instead of patching only in a panic.

FAQ: PHP security threats and PHP2Shell

What is PHP2Shell?

PHP2Shell is the nickname for two critical PHP remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, patched on 21 October 2026.

Is PHP2Shell the same as wp2shell?

No. PHP2Shell affects PHP itself, while wp2shell was a separate WordPress core exploit chain reported in July 2026. Because they sit in different layers, you need to patch both.

Are PHP security threats like PHP2Shell a WordPress problem?

The flaws sit inside PHP itself, so WordPress core, themes and plugins are not the cause. Any site that runs on an unpatched PHP version is exposed, including WordPress, WooCommerce, Laravel and custom PHP apps. WordPress.org says core needs no update. The fix is a PHP update on the server.

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?

The fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older no longer get fixes from the PHP project, so those sites should move to a supported branch.

Can I protect my site without updating PHP?

Not fully. Turning off session.upload_progress.enabled, limiting request sizes and using a firewall reduce the risk, but only a patched PHP version closes the flaws. Treat these steps as a short bridge, not a fix.

How do I check my PHP version in WordPress?

Open Tools, then Site Health, then the Info tab, and expand the Server section. Some Linux distributions backport the fix without changing the version number, so ask your host to confirm the fix includes both CVE IDs.

Does my hosting company patch PHP for me?

Managed WordPress hosts and most shared hosts patch PHP for all customers. On a VPS or cloud server you manage yourself, the patch is your job. Always ask your host for written confirmation.

Conclusion

These two PHP security threats are serious because they sit below WordPress, ahead of your login pages and plugins. The good news is that the fix is clear: move to PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer, and confirm it with your host. If you need a hand, contact me and I will check your site and server.

Sources: Datadog Security Labs, The Hacker News, Codeable. This reflects what was known on 22 October 2026, and details may change as more information emerges.