On 21 October 2026, the PHP project released fixes for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Together they are known as PHP2Shell. Both are rated 9.2 under CVSS v4.0, and both can let someone without a login run code on a vulnerable server. (PHP security announcement)
PHP is the software your server uses to run WordPress. The fix therefore happens at the hosting level, not in your WordPress dashboard. These seven steps cover what to do today.
1. Know where the fix lives
The flaws are in PHP itself. Keep WordPress, plugins and themes updated anyway, but those updates do not fix this. WordPress says no WordPress update is required or planned. (WordPress)
PHP says all installations serving web requests are potentially at risk. That includes PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, with the risk highest for mod_php. Don't assume your setup is the safe one. (PHP)
2. Check your PHP version, but don't judge by the number alone
In WordPress, go to Tools → Site Health → Info → Server. Many hosting panels show the version too. (WordPress)
The fixed upstream releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. (PHP)
A lower-looking number is not automatically unpatched. Linux vendors often add fixes to older version numbers, which is called backporting. For example, Ubuntu's fixed packages include:
- 8.3.6-0ubuntu0.24.04.13 for Ubuntu 24.04 LTS
- 8.1.2-1ubuntu2.28 for Ubuntu 22.04 LTS
The version displayed in WordPress or a control panel may not prove whether a vendor patch is installed. Your host or server administrator should check the full package revision against the vendor's advisory for both CVEs.
PHP 8.1 and older no longer receive normal upstream security releases. Some vendors backport fixes, and PHP published minimal source patches for 7.4, 8.0 and 8.1 for people who build PHP themselves. If you are on one of these versions, ask your host how it is covered, and plan an upgrade. (PHP)
3. Send your host this message
Subject: PHP2Shell (CVE-2026-109618 and CVE-2026-109619): please confirm for [your domain]
Hi,
Please confirm the following for [your domain]:
- 01The PHP version and full package revision serving the website, plus the vendor advisory showing it fixes both CVE-2026-109618 and CVE-2026-109619.
- 02Whether any required restarts or replacement of PHP services or workers have been completed, and that you checked the PHP actually serving web requests, not only the command-line version.
- 03That staging sites, subdomains, background jobs and any other sites on my account are covered.
- 04Which firewall (WAF) protections are active, and whether the server can be reached directly in a way that bypasses them.
- 05Whether you have seen anything suggesting the site needs a security investigation.
Please let me know when this is done so I can test the site.
Thank you.
4. Confirm the fix is actually live
Installing an update is not always the same as running it. Depending on the setup, PHP processes that started before the update may need to be restarted or replaced before the fixed code is used. Your host should confirm this has been handled.
A version check at the command line can also report a different PHP from the one serving your pages. Ask for confirmation against the website's own runtime.
Coverage matters too. Old staging copies, forgotten subdomains and other sites on the same server need the same fix.
5. Keep firewall protection on, but don't rely on it
Cloudflare says it deployed WAF rules before public disclosure, on both free and paid plans with WAF. It observed attack traffic, and attackers changing their payloads to slip past its protections. It still tells customers to patch PHP. Paid-plan customers should check that the Managed Ruleset is deployed in block mode. (Cloudflare)
A firewall only filters the traffic that passes through it. It doesn't repair PHP. If requests bypass that firewall and reach your server directly, its rules cannot protect those requests. Resetting passwords doesn't fix PHP either.
Attack traffic in general does not mean any particular site has been breached.
6. If your host cannot patch promptly
PHP lists temporary measures for administrators. It also says these only reduce exposure to specific attack paths and do not make an installation safe. (PHP)
These measures are your administrator's decision. Don't copy settings from forums into a live site.
CERT-EU recommends considering isolating internet-facing applications until a fix can be applied. (CERT-EU) WordPress adds that self-managed sites on PHP older than 8.2 should consider going offline while they upgrade. (WordPress)
A maintenance-mode page served by the same PHP does not isolate it. Ask your host how public requests will be kept away from the vulnerable PHP, and when the patch will be applied.
7. Test business workflows and address signs of compromise
Test what earns you money. Once the host confirms the update, check:
- the home page and key landing pages
- logging in
- contact and enquiry forms
- file or image uploads
- bookings, or add-to-cart through to checkout
- confirmation emails
- payment notifications
Note anything broken, with the time it happened, and send it to your host.
Watch for signs of compromise at the same time, not after testing. Patching closes the hole, but it can't tell you whether someone got in earlier. Wiz demonstrated remote code execution against WordPress. It also showed that attackers could read server memory, which may contain passwords, tokens and API keys. (Wiz)
Wiz suggests watching for three warning signs. (Wiz)
- unusual upload-style requests followed by memory errors or repeated server errors
- oversized or malformed session cookies
- PHP workers restarting for no clear reason
These are leads, not proof, and normal application logs may show little.
If you see warning signs, start an investigation alongside the patching:
- Ask your host to preserve logs before any cleanup.
- Bring in a qualified incident responder.
- Decide with them which passwords, API keys, payment keys and logged-in sessions to replace.
Your next step
Send the message in step 3 now. The immediate update work is complete when your host has confirmed three things:
- Both fixes are installed in the PHP that actually serves your site.
- Any required restarts or replacement have been done.
- Your key journeys still work.
Any suspected compromise still needs its own investigation, even after the patch is in place.
For ongoing help keeping website work off your plate, explore Superpress WordPress care plans or talk to the team about the care your site needs.
Frequently asked questions.
Does updating WordPress fix PHP2Shell?
No. These flaws are in PHP itself. Your host or administrator must update the PHP runtime serving the website; WordPress says no WordPress release is required for these issues.
Can an older-looking PHP version already be patched?
Yes. A vendor may backport fixes. Verify the complete package revision against its advisory for both CVEs rather than relying on the short version displayed in WordPress.
Does a firewall replace the PHP update?
No. A WAF can reduce exposure to traffic that passes through it, but it does not fix PHP. Confirm both updates are active, and investigate suspected compromise separately.
Research sources.
This guide was checked against current platform and search documentation before publication.