If your website runs on PHP, PHP2Shell matters to you. On 21 October 2026, the PHP project released emergency fixes for 2 critical flaws that could let an attacker run code on a server without logging in. PHP sits behind roughly 70% of websites with a known server side language, according to industry estimates reported by TNND, and that includes every WordPress site.

The catch is that this isn't a plugin problem or a password problem. The flaws sit inside PHP itself, so the fix has to come from whoever runs your server. For most people that's their hosting company. For some, it's them.

We've been working through the sites we look after this week, and the questions we're hearing are probably the same ones you have. This guide explains what this PHP vulnerability is, who's at risk and what the official guidance says to do. If you'd rather hand it over, we're happy to help.

What is PHP2Shell?

PHP2Shell is the nickname for 2 critical vulnerabilities in PHP, the language behind a large share of the web. They're tracked as CVE-2026-109618 and CVE-2026-109619. Each can let an attacker with no login run code on a web server using a crafted request. Both are rated 9.2 out of 10 on the CVSS v4.0 scale.

The "shell" in the name points at what's at stake. If an attack works, the person behind it gets control of the server your site runs on, not just a way to change a page. That includes the files and data on that server.

The 2 flaws in plain English

• CVE-2026-109618 (out of memory corruption): When PHP runs out of memory part way through handling a request, it can be interrupted while its internal data is only half built. The clean up that follows then treats that broken data as valid. The University of Toronto's security team says attackers can trigger this with crafted multipart requests, the format used for file uploads.
• CVE-2026-109619 (stale global state): After a fatal error, PHP can keep a pointer to memory that has already been freed. The next request handled by the same worker may then use that stale data before it's reset, as Datadog Security Labs explains.

You'll also see these called GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, the advisory numbers in PHP's own php-src repository on GitHub. Those advisories are PHP's own account of what went wrong.

Why a login or a plugin won't stop it

PHP processes an incoming request before your application code gets a look at it. Datadog Security Labs reproduced both flaws and confirmed that application level authentication can't block an attack for that reason. A strong admin password or 2 factor authentication won't help here.

The same goes for plugin and theme updates. TNND reported that updating website content or plugins alone won't fix flaws in PHP itself. The fix is a patched PHP, installed and running.

Is PHP2Shell being exploited?

Yes, attackers are targeting it. Security firms, Cloudflare and Amazon have all reported attack traffic, and some of it started before the flaws were public.

• 17 October: Amazon Threat Intelligence says its MadPot honeypot network recorded an exploitation attempt, 4 days before public disclosure.
• 20 October: PHP announced an emergency security release and CERT-EU published an advisory. Details of the flaws had already leaked by then, according to Recorded Future.
• 21 October: PHP shipped the fixes. VulnCheck logged probes and exploitation attempts the same day, and Cloudflare reported attack traffic against its customers.

Reports so far describe scanning and attack attempts rather than confirmed numbers of compromised sites. That's still reason enough to move quickly. Agencies in the US, UK, EU, Canada, Australia and Japan have urged organisations to find and patch their PHP systems, according to TNND.

Which PHP versions are affected by PHP2Shell?

Every PHP installation that serves web requests is at risk. PHP's advisory names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, as reported by Help Net Security. If your site runs on any of those, you're in scope for this PHP remote code execution risk.

PHP released fixes for the 4 branches it still supports:

• PHP 8.5: update to 8.5.12
• PHP 8.4: update to 8.4.27
• PHP 8.3: update to 8.3.36
• PHP 8.2: update to 8.2.35

Anything older than those releases on those branches is vulnerable.

What if you're on PHP 8.1 or older?

PHP no longer supports 8.1 and earlier. Because the flaws are so severe, the PHP security team still released minimal source backports for PHP 7.4, 8.0 and 8.1, according to Help Net Security. Hosts and Linux distributions may also ship their own patched packages.

That means a version number that looks old isn't automatically unpatched. SOCRadar points out that vendor packages can include backported fixes, so check your provider's own security advisory rather than relying on the number alone.

Wiz Research has reported that affected releases go back as far as PHP 5.4. PHP's advisories only list the 4 supported branches, so treat the older range as Wiz's finding. The NCSC's advice is to look beyond outdated versions, because all versions may be affected.

Another date for your diary. PHP 8.2 is patched at 8.2.35, but its security support ends on 31 December 2026 under PHP's support lifecycle. If you're on 8.2, plan your move now. WordPress.org currently recommends PHP 8.3 or newer.

What to do about PHP2Shell

Update PHP to a fixed version, then restart the PHP processes so the patched version is the one running. PHP's own advisory calls updating the only complete mitigation, and both CERT-EU and the NCSC urge immediate action.

Here's the order we'd work in:

1. Find out who runs the PHP for each site you own, including old ones. That's your host, a server admin or you.
2. Check which PHP version each site is actually serving.
3. Get written confirmation from your host, or install the update yourself.
4. Make sure every PHP worker has restarted so the new version is live.
5. Check for signs that someone got in while the site was exposed.

If you're on managed hosting

Most managed hosts handle PHP updates for you, and many moved fast. Automattic said sites on WordPress.com, WordPress VIP, WP Cloud and Pressable were already protected, according to The Repository. WP Engine put mitigations in place at the CDN layer shortly before the release and finished deploying patches at 01:19 UTC on 22 October. Liquid Web and Rocket.net were still rolling out fixes into that day.

Don't assume yours is done, though. Ask your host to confirm in writing which PHP version your site now runs and whether every PHP worker has restarted. Also ask whether any older PHP versions on your account are covered.

You can also check for yourself. In WordPress, go to Tools, then Site Health, then the Info tab, and open the Server section. That shows the PHP version your site is serving. Running php -v on a server's command line can report a different version from the one serving your pages, so don't rely on it alone.

How to update your PHP version if you run your own server

Install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your Linux distribution's fixed package, and update internet facing systems first. Then restart PHP-FPM or your web server so the new version loads. Windows builds are on php.net, according to the University of Toronto's security team.

If you deploy with containers, rebuild and redeploy the image so the patched version is what's running. Then think about the software you didn't build. The NCSC points to an inventory from its Dutch counterpart, NCSC-NL, listing products with a PHP dependency that may be affected. Palo Alto Networks has also confirmed that all versions of PAN-OS and Panorama are affected.

If you can't update today

Some stopgaps exist, but they only buy time. Datadog Security Labs and ELLIO both point to PHP's advisory. It describes removing PHP's finite memory limit by setting memory_limit=-1 at the server level, so nothing can switch it back, then restarting every worker.

That's a job for whoever runs the server, and it affects how the server copes under load. PHP is clear that it's no substitute for updating.

A web application firewall can help too. Cloudflare deployed an initial set of rules for the known exploit routes, available to all customers including free plans. It has also reported attackers changing their payloads to get past those rules, so treat a firewall as a delay rather than a fix.

Check for signs of compromise

If a site sat on an unpatched PHP version while open to the internet, ask your host or developer to check it. Attack attempts have been seen since 17 October. VulnCheck recorded probes using scanner names containing php2shell in the user agent, but those are trivial to change, so a clean log doesn't prove you're safe.

Sansec also reports that PHP's upload progress handler can hand freed server memory back to the person making the request. That memory can hold passwords, session tokens and API keys from other requests. If your server was exposed, our advice is to change any credentials stored on it once the patch is live.

The NCSC says that if you're not confident finding and assessing your PHP exposure yourself, you can get help from an NCSC assured Cyber Incident Response provider. UK organisations can also sign up for its free Early Warning service.

Can a firewall or security plugin stop PHP2Shell?

They can reduce your wider risk, but they can't replace the PHP update. The flaws sit below WordPress, and a plugin only runs once PHP has already processed the request.

Here's how we've handled it. Many of the sites we look after run on WP Engine's managed hosting. One site we updated a client on this week had already been moved onto a patched PHP release by WP Engine at server level. That addressed the known vulnerabilities at the source.

As an extra layer, we installed WP Cerber on that WordPress site. It gives us login rate limiting, a web application firewall to filter malicious requests, and malware scanning. File integrity checks alert us to unexpected changes to core, theme or plugin files.

We see that as a safety net. It doesn't patch PHP, and we wouldn't tell a client it does.

We're also monitoring follow up disclosures and will act on official guidance from PHP, WordPress and WP Engine as it's published.

What to do next

PHP2Shell comes down to 3 things. Find out who runs your PHP, confirm the patched version is live and restarted, then check whether anyone got in before it was. A plugin, a login or a firewall isn't a substitute for the update.

If you'd like a second pair of eyes, we can check which PHP version your sites are really running, chase your host for confirmation and look through your logs. You can see the kind of sites we build and look after on our marketing sites service page. Or get in touch and tell us what you're running.

PHP2Shell FAQs

What is PHP2Shell?

PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619, 2 critical flaws in PHP rated 9.2 out of 10 on CVSS v4.0. Each can let an unauthenticated attacker run code on a web server. PHP released fixes on 21 October 2026.

Is my WordPress site affected by PHP2Shell?

If it runs on an unpatched PHP version, yes. WordPress is built on PHP, but the flaws are in PHP itself rather than in WordPress. Check your PHP version in Site Health and ask your host to confirm the fix is live.

Do I need to update WordPress or my plugins?

Keep them up to date as usual, but they won't fix PHP2Shell. Only a patched version of PHP, installed and restarted by whoever runs your server, closes the flaws. For most sites that means your hosting company.

Which PHP version fixes PHP2Shell?

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you're on an older branch, you need a vendor or distribution backport, or a move to a supported version. Your host's security advisory will say which applies.

How do I check my PHP version?

In WordPress, open Tools, then Site Health, then Info, and look in the Server section. Your hosting dashboard usually shows it too. Check the version your website serves, because the command line version on a server can differ.

Is it safe to stay on PHP 8.1 or older?

PHP no longer supports those versions, although its security team released minimal source backports for 7.4, 8.0 and 8.1. Whether your site is covered depends on your host or distribution. Ask for confirmation in writing, and plan a move to a supported branch.

Has PHP2Shell been used in real attacks?

Attack attempts have been reported. Amazon recorded one on 17 October, before public disclosure, and Cloudflare and VulnCheck saw attack traffic and probing on 21 October. Reports so far don't put a figure on successful compromises.