Short answer: On 21 October 2026, PHP released emergency fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619, known together as "PHP2Shell". If your website runs on PHP, and most WordPress, WooCommerce, Laravel and shared-hosting sites do, update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now. If you have to take the site offline while you patch, return an HTTP 503 and keep robots.txt reachable so you don't lose your Google rankings.
What is PHP2Shell?
PHP2Shell is the name for two vulnerabilities in PHP itself. They allow unauthenticated remote code execution: an attacker who has no login can run code on your server. According to CISA, they "affect all PHP installations serving web requests". Google Cloud reports a CVSS score of 9.2 (Critical) for each.
BleepingComputer reports that the flaws affect PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP security team considers the risk "highest for mod_php", because a demonstrated exploit works before any application code runs.
Is it being exploited yet?
Attackers are clearly trying. Whether any attack has actually succeeded is still unclear, so plan as though it will:
- CISA (alert updated 23 Oct): had "not observed successful exploitation" of the flaws when it published, and still urges organisations to patch immediately.
- Security firms: Cloudflare, watchTowr and others reported exploitation attempts around the time the patches landed. Amazon says it saw an attempt on its honeypots as early as 17 October and now describes "broad exploitation attempts in the wild".
- No confirmed compromise yet: Sophos withdrew an earlier report of a successful attack on 22 October, saying it had seen only scanning and failed attempts. Public proof-of-concept exploit code is available, though.
The UK's NCSC has also told organisations to update PHP or take the affected systems offline until they are patched.
Is my WordPress site affected by the PHP vulnerability?
If your WordPress site runs on any PHP version older than the fixed releases, assume yes. PHP2Shell is a flaw in PHP, not in WordPress, so updating WordPress or its plugins does not fix it. Your PHP version has to be updated. That's normally done by your hosting provider or your developer.
If you're still on PHP 8.1 or older, the risk is higher:
- These versions no longer receive regular updates from the PHP project.
- CISA says systems that can't be updated, including PHP 8.1 and earlier, should be taken offline until they're patched or upgraded.
- Google Cloud tells its customers to move to PHP 8.2 or newer.
PHP2Shell: what to do this week (step by step)
Step 1: Find your PHP version
Ask your host or developer, or check your hosting panel (cPanel, Plesk and similar panels show it). In WordPress, open Tools → Site Health → Info → Server. On a server, run php -v. Remember that the web server can use a different PHP binary from the command line, so check both.
Step 2: Patch to a fixed version
Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or any newer release. CISA and BleepingComputer both list these same version numbers. If you're on PHP 7.x or 8.1, plan a move to a supported version. The PHP team has also published minimal source backports for PHP 7.4, 8.0 and 8.1, but these are for people who build PHP themselves; most site owners should upgrade. BleepingComputer notes that some Linux distributions and hosts may ship their own backported fixes, so ask your provider exactly what they've installed. If you can't patch straight away, the PHP team has published mitigations, but BleepingComputer reports that they "don't fully protect against exploitation".
Step 3: Restart PHP workers and verify
Installing a package doesn't help until the running processes reload it. Restart PHP-FPM, Apache or LiteSpeed, then check the version that is actually serving requests, for example with a temporary phpinfo page that you delete straight after. If you run containers on Cloud Run, GKE or similar, Google Cloud says you're responsible for rebuilding and redeploying your own images. Only App Engine standard (PHP 8.2 and newer) is patched automatically.
Step 4: If you must go offline, serve a 503 from outside PHP
Google's John Mueller gave this advice (via Search Engine Roundtable): "use HTTP 503 instead of letting responses time out / 404 / 500. You can do this outside of PHP / point DNS elsewhere / CDN."
In practice, set up a maintenance rule on your CDN (for example Cloudflare) or in Nginx or Apache that returns 503 without passing the request to PHP.
Don't use the alternatives. Google's guide to pausing a site says that 403, 404 and 410 status codes, noindex, and the Search Console removal tool all remove your URLs from Google Search.
Keep the downtime short. Search Engine Journal notes that Google advises against serving a 503 for more than one to two days, because URLs that return it for several days may be dropped from the index. Google's pause guide calls disabling a whole site an extreme step that should last "a few days at most".
Step 5: Keep robots.txt returning 200
Google's guide is clear: "Don't return a 503 HTTP response status code for the robots.txt file because this blocks all crawling." Don't switch robots.txt to disallow everything either, because that can remove your content from Search. Exclude /robots.txt from your maintenance rule and check it with curl -I https://yourdomain.com/robots.txt.
Step 6: Check WordPress plugins and users
While you're patching, check for a second, separate problem. Search Engine Journal reports that attackers used stolen UpdraftCentral keys to install backdoor plugins on sites using the UpdraftPlus backup plugin. The plugin has more than 3 million installs. The backdoors created Editor accounts and then gave those accounts admin-level powers. If you use UpdraftPlus:
- Update to 1.26.13 (free) or 2.26.13 (premium) or newer. These versions were released on 19 October 2026.
- Look for plugins you don't recognise, and for administrator or editor accounts nobody created.
- Remove leftover UpdraftCentral keys under Settings → UpdraftPlus → Advanced Tools → UpdraftCentral.
- Change admin passwords. If you find signs of compromise, consider restoring from a backup taken before 17 October.
Step 7: Bring the site back and check Search Console
Switch off the 503 rule and confirm that pages return 200. Then watch Google Search Console: check Pages (indexing), Crawl stats and Manual actions / Security issues over the next few days. Google says that once you serve 200 again, "things naturally return to normal".
From our experience
At Vilva, we started rolling out the patches straight away, beginning with our critical fintech clients. Our D2C team is already on it. Patching for our GrowthOS client sites is in progress.
"Updating and securing software regularly is a high priority in this agentic AI era." — Gopinath Ravirajan, Vilva Business
Security is SEO now
A hacked site or a long outage costs you rankings, traffic and leads. For a wider plan, read our cybersecurity guide for growing businesses and our list of technical SEO mistakes that stop Indian SME sites ranking. If you're stuck on an old PHP version, our custom software team can help you plan a migration.
Frequently asked questions
What is PHP2Shell?
It's the name for CVE-2026-109618 and CVE-2026-109619, two critical PHP flaws disclosed on 21 October 2026. They allow unauthenticated remote code execution on PHP servers that serve web requests.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and any newer release.
Is my WordPress site affected?
If it runs on an unpatched PHP version, yes. The flaw is in PHP, so updating WordPress alone won't fix it. Ask your host to update PHP.
How do I take my website offline without losing Google rankings?
Return HTTP 503 from your CDN or web server, outside PHP. Keep robots.txt returning 200, and keep the downtime to a day or two. Don't use 404, 403, 410, noindex or the removal tool.
Is PHP2Shell being actively exploited?
Attackers are trying. Several security firms have seen exploitation attempts since 21 October, and proof-of-concept code is public. As of 23 October, CISA had not observed a successful attack and Sophos had withdrawn an earlier report of one. Patch as if it is being exploited.
I'm on PHP 8.1 or older. What should I do?
Those versions no longer get regular official updates. CISA advises taking such systems offline until they're upgraded. Plan a move to PHP 8.2 or newer.
Not sure which PHP version your site runs, or how your downtime is set up? Ask Vilva to check your website's PHP version and downtime setup →
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)

.webp)
.webp)
.webp)
.webp)
.webp)











