PHP2Shell: What WordPress Site Owners Should Do This Week
PHP2Shell is a pair of critical flaws in PHP itself, not WordPress. Check your PHP version, patch safely, use a 503 if you go offline, and spot a hack.
By Innovixus Team ·
In short: PHP2Shell is the name for two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Updating WordPress does not fix it; your host or server admin has to update PHP. Check your PHP version today, ask your host to confirm the patch, and if you must take the site down, serve a 503 for no more than a day or two.
If you run a WordPress site, you may have had an email from your host this week about something called PHP2Shell. This guide explains what it is, how to check whether your site is exposed, and what to do, in plain terms for owners and in enough detail for whoever looks after your server.
Last checked: 28 October 2026. This is a developing story. Check the linked sources for anything newer.
What PHP2Shell is, in two sentences
PHP2Shell is the name researchers gave to two flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, which can let an attacker run their own code on a web server without logging in. Because the problem is in PHP rather than in WordPress, it also affects Drupal, Joomla and other PHP software. Wiz demonstrated attacks against all three.
The name comes from Wiz Research, which found the flaws with Calif and OpenAI and reported them to PHP in August 2026. OpenAI's Patch the Planet programme, which uses AI models to hunt for bugs in open-source code, is credited with part of the discovery.
How serious is it?
The PHP project rates both flaws critical and says the fixes cover all PHP installations serving web requests, whether they run on PHP-FPM, Apache with mod_php, LiteSpeed or something else. It considers mod_php setups the most at risk.
On exploitation, the picture has changed over the week. Canada's Cyber Centre first reported a public proof of concept but no active attacks. Its 27 October update says both CVEs are now being exploited in the wild. The US cybersecurity agency CISA added both to its Known Exploited Vulnerabilities catalogue on 26 October 2026. Recorded Future notes that public reporting does not yet show how many sites were actually compromised.
So: take it seriously and act this week, but there is no need to panic. Some hosts, such as Hostinger, finished patching within a day of the release.
Am I affected?
Your site is exposed if its server runs a PHP version older than the fixed releases. According to the PHP project and the Cyber Centre:
| PHP branch | Vulnerable | Fixed in |
|---|---|---|
| 8.5 | Before 8.5.12 | 8.5.12 |
| 8.4 | Before 8.4.27 | 8.4.27 |
| 8.3 | Before 8.3.36 | 8.3.36 |
| 8.2 | Before 8.2.35 | 8.2.35 |
| 8.1 and older | Yes | No official release |
The PHP project has published source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves, but those branches no longer get official updates.
To check your version:
- In WordPress: go to Tools > Site Health > Info > Server, as WordPress.org recommends.
- In your hosting panel: look for "PHP version", "PHP settings" or "PHP info" in cPanel, Plesk or your host's own dashboard.
One catch: some managed hosts patch PHP without changing the version number. Hostinger, for example, tells customers to check the build date instead. If the number looks old but your host says you are covered, ask them to confirm in writing.
What to do today
- Ask your host. Send one line: "Is my server running a PHP build that fixes CVE-2026-109618 and CVE-2026-109619?" Most shared and managed WordPress hosts handle PHP for you. Hostinger, for instance, patched all plans except VPS, where customers manage PHP themselves.
- Back up first. Take a full backup of files and database, and store a copy off the server.
- Update PHP if you manage it. On a VPS or your own server, install the fixed release for your branch. The PHP project says there are no complete mitigations and updating is the only safe choice.
- Plan a move off PHP 8.1 or older. Moving to 8.2 or newer can break old themes and plugins, so test on a staging copy before switching the live site. PHP 8.2 itself stops receiving security fixes on 31 December 2026, so 8.3 or 8.4 is a better target.
- Update WordPress, themes and plugins too. This does not fix PHP2Shell. WordPress.org says no WordPress update is needed for it. It does close other holes while you are already doing maintenance.
For developers who cannot update immediately: the PHP advisory lists partial measures, including setting session.upload_progress.enabled = 0 in php.ini or the FPM pool (not via ini_set()) and restarting all workers. A separate 23 October advisory recommends the same setting for a related, less likely issue, CVE-2026-115560. Treat these as stopgaps.
Drupal and Joomla owners should follow the same steps. Drupal's security team says updating PHP is the only complete mitigation. We did not find a Joomla-specific notice at the time of checking.
Taking the site down safely
If your server runs an unsupported PHP version and you cannot update quickly, WordPress.org suggests taking it offline while you prepare. If you do, protect your search rankings.
On 21 October, Google reminded site owners to return an HTTP 503 (Service Unavailable) during patching, not timeouts, 404s or 500s. A maintenance page that returns 200 can get indexed as your actual content. Google's guidance says:
- Use 503 for short outages only. Google suggests a 503 when you urgently disable a site for 1–2 days. URLs that keep returning server errors are eventually dropped from the index.
- Add a Retry-After header to tell Google's crawlers when to try again, in seconds or as a date.
- Keep robots.txt working. A 503 on robots.txt blocks all crawling.
- Serve the 503 outside PHP. Google's John Mueller suggested using a CDN or pointing DNS elsewhere. Maintenance-mode plugins run on PHP, so they do not help if PHP is what you are switching off.
On Nginx, a minimal version looks like this:
location = /robots.txt { }
location / {
add_header Retry-After 7200 always;
return 503;
}
Then run curl -I https://yourdomain.com and confirm the response says 503, as Google recommends.
Signs of compromise, and what to do if you are hacked
The Cyber Centre advises reviewing web server and application logs and looking for unexpected processes, commands, files, accounts or outbound connections linked to PHP or the web server. For a WordPress owner, that usually means:
- Admin users you did not create
- New or recently changed PHP files, especially in
wp-content/uploads - Redirects to unfamiliar sites, spam pages in Google results, or a hosting warning about unusual traffic or CPU use
If you see any of these:
- Tell your host straight away. They can see server logs you cannot.
- Do not just delete the odd file. Attackers often leave more than one way back in.
- Restore from a clean backup taken before the compromise, then update PHP before going live again.
- Change all passwords: WordPress admins, hosting, database, FTP/SFTP, and any API keys stored on the site.
Who to ask
Start with your host. On shared or managed hosting, PHP is their job, and they can confirm the patch in minutes. If you have a developer or agency, ask them to check plugin compatibility and handle any PHP upgrade on a staging site first. If you are on a VPS with nobody looking after it, that is the gap to close this week.
How Innovixus can help
We help businesses in India and the Gulf keep PHP and WordPress sites secure and running. That includes confirming your PHP patch status, testing an upgrade on staging, and checking for signs of compromise. Our quality assurance team can run a security and upgrade check, and our web applications team can take over ongoing maintenance. If you are unsure where your site stands, get in touch and we will tell you what needs doing.
Frequently asked questions
Does updating WordPress fix PHP2Shell?
No. The flaws are in PHP, the language WordPress runs on. WordPress.org has said no WordPress update is required or planned for these issues. The fix is a patched PHP build, which your host or server admin installs.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. PHP 8.1 and older no longer receive official updates, so sites on those versions need to move to a supported version or get a backported fix from their host or Linux vendor.
My host says I am protected but my PHP version number has not changed. Is that a problem?
Not necessarily. Some managed hosts install patched builds without changing the version number. Ask your host to confirm in writing that the fix for CVE-2026-109618 and CVE-2026-109619 is installed on your server.
Will taking my site offline for patching hurt my Google rankings?
Not if you do it properly. Return an HTTP 503 status, optionally with a Retry-After header, keep robots.txt reachable, and bring the site back within a day or two. Avoid 404s, timeouts or a maintenance page that returns 200.