PHP2Shell is a server problem. Here's who has to fix it.

PHP2Shell is a pair of critical flaws in PHP itself — the language running underneath WordPress, WooCommerce, Drupal and most of the web. An attacker can use them to run code on a server without logging in. PHP shipped the fix on October 21, 2026.

Short answer: if we build or maintain your site on SiteGround, you don't need to click anything. Longer answer: the fix lives on the server, not in WordPress. So if your site is hosted anywhere else, someone has to update PHP. Make sure you know who that is — today.

What is PHP2Shell?

It's the nickname researchers gave two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. PHP's security team rates each one 9.2 out of 10 on CVSS v4.0. That's critical.

Both are memory bugs in PHP's core engine. One triggers when PHP runs out of memory partway through a request. The other leaves stale data behind after a fatal error, which the next request can pick up. Either way, a crafted HTTP request can push the server into running the attacker's code.

The reach is the alarming part. PHP says every installation that serves web requests is exposed — PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates mod_php setups as highest risk. Wiz Research, one of the teams that found the flaws, reports that every PHP release back to 5.4 is hit by at least one of them.

Why can't a WordPress update fix it?

Because WordPress isn't what's broken. The flaw sits in the PHP runtime, one layer below your theme, your plugins and WordPress core. Cloudflare's write-up puts it plainly: updating site code or plugins doesn't fix this. The PHP software on the server has to be updated.

That matters if your first instinct is to install a security plugin. Frankly, don't bother for this one. A plugin runs inside PHP. It can't patch the thing it's running on.

So the real question for every site owner is simple. Who controls PHP on your server — you, your host, or your agency?

Which PHP versions are safe?

PHP released fixed builds for its four supported branches. Find your branch, then check you're at or above the fixed number.

Source: PHP security advisory, Oct 21, 2026.

Is anyone exploiting it yet?

Attackers are already trying. Whether they've succeeded is less clear.

The flaws leaked online on October 20, a day before PHP's planned release, according to The Hacker News. That forced PHP to publish early. Cloudflare says it saw attack traffic aimed at its customers — including attackers tweaking their payloads to slip past its new firewall rules.

CISA, meanwhile, said it had not observed exploitation as of its alert on October 21. Our read: attempts are live, confirmed breaches aren't public yet, and that gap usually closes fast. Treat this as active.

What did we do for Actuate-managed sites?

We manage over 50 websites, and we host client WordPress builds on SiteGround's managed PHP platform for exactly this kind of week. When a flaw lives in the server, the fastest patch is one the host rolls out to every server at once — not one that waits on each site owner to log in.

This week that choice paid off early. After PHP's advance notice on October 20, SiteGround says it pushed server-level mitigations across all its servers and switched off the affected PHP functions on every supported version. That landed hours before the official fix went public. Site owners didn't have to change a setting.

Here's the honest part. A mitigation isn't the patch. PHP's own advisory says its interim measures "do not make an installation safe" — only the updated build does. So we're not calling this done until the patched PHP version is confirmed on every client site.

We're checking the PHP version on the sites we manage against the table above, and we're not calling this done until each one reports a fixed build — or, on PHP 8.1 or older, has an upgrade plan in motion. A mitigation alone doesn't prove a site is safe. The version number has to.

What should you do, based on where your site lives?

• You're an Actuate client on SiteGround: nothing. We'll confirm the patched version on your site once it's live.
• You're on another managed host: ask one question, in writing. "What PHP version is my site running, and when will it be on the fixed release?" Accept a version number. "You're protected" isn't one.
• You run your own server or VPS: install the fixed build from your Linux distribution or php.net, then restart PHP-FPM or the web server so it actually loads. CISA says to start with internet-facing systems.
• You're on PHP 8.1 or older: this is the hard case. There's no official PHP release for you, and CISA's advice is to take those systems offline until they're patched or upgraded. Move to 8.3 or 8.4. Test your plugins first — but this isn't the week to defer it.
• You're behind Cloudflare: good. Its firewall rules for PHP2Shell went live on every plan with WAF enabled, including Free, at 3:02 UTC on October 21. That's a seatbelt, not a fix. Cloudflare itself says to patch PHP anyway.

How to check your PHP version on the big hosts

On WordPress, the fastest check works on any host: Tools → Site Health → Info → Server. If you want the number from the host itself — or you need to change it — here is where ten common hosts keep it. Panel layouts change, so treat the host's help page as the source of truth. And if a website design agency built your site and holds the host login, send them this list and ask for the version number in writing.

• SiteGround: Site Tools → Devs → PHP Manager shows the version in use. SiteGround: check your PHP version
• WP Engine: User Portal → Sites → your environment — the PHP selector and the Updates section show it. WP Engine: PHP version guide
• Kinsta: MyKinsta → Sites → Tools → PHP settings shows the current version. Kinsta: MyKinsta Tools
• Bluehost: Portal → Websites → Manage Site → Advanced → PHP Version. Bluehost: check and update PHP
• Hostinger: hPanel → Websites → Dashboard → PHP Info shows it at the top. Hostinger: check the PHP version
• GoDaddy (Managed WordPress): My Products → Managed Hosting for WordPress → Settings → PHP version; verify it under WordPress Tools → Site Health → Server. GoDaddy: change my PHP version
• DreamHost: Panel → Manage Websites → Manage → Settings → PHP; List View also shows a PHP column per site. DreamHost: view your PHP version
• Cloudways: Flexible → Applications → Application Settings → PHP Settings shows the version for that application. Cloudways: upgrade PHP version
• Liquid Web: cPanel → Software → MultiPHP Manager — the PHP Version column lists each domain. Liquid Web: upgrade PHP in cPanel
• WordPress.com: Hosting dashboard → Settings → Server → PHP; WordPress.com normally moves versions for you. WordPress.com: server settings

Host not listed? Site Health still works. No WordPress? Ask the host for the version number the same way — in writing, with a date for the fixed build.

What to do right now

1. Find your PHP version. In WordPress, go to Tools → Site Health → Info → Server — or use your host's panel above.
2. Compare it to the table above. At or above the fixed number? You're patched.
3. Below it? Get it updated today. Get the new version number in writing from whoever manages your server.
4. Skip the security plugin. It can't fix a server-level flaw.

The fix is a server update. Make sure someone owns it. For a related server-side change, see our HTTP to HTTPS migration notes.

Sources

• PHP: Security advisory — critical remote code execution vulnerabilities, update now (Oct 21, 2026)
• CISA: Critical vulnerabilities in PHP require immediate patching (Oct 21, 2026)
• Cloudflare: Cloudflare deploys protections against php2shell vulnerability (Oct 21, 2026)
• The Hacker News: PHP2Shell — two unpatched critical PHP RCE flaws (Oct 21, 2026)
• Wiz Research: PHP2Shell (Oct 21, 2026)
• SiteGround: SiteGround moves early to protect customers ahead of critical PHP security release (Oct 21, 2026, last updated 11:30 UTC)

Platform-dependent post — next review: Apr 21, 2027.