On October 21, 2026, PHP shipped fixes for two critical remote code execution flaws, the ones covered in PHP2Shell: Two Critical PHP Flaws Leaked Before the Patch. The same day, WordPress.org posted its own notice, and the key line was this: “No WordPress update is required or planned for these issues.”
That sentence is easy to read as good news. It isn’t. It means the fix isn’t in your dashboard. Your “Update” buttons can’t install it, and your security plugin can’t install it either. It lives on the server, in a piece of software most site owners have never chosen, configured or even looked at. Your PHP version is a security setting, and on most sites it belongs to the host.
Who owns what
A WordPress site is a stack, and different people are responsible for different layers:
- Your content, theme and plugins. Yours. You choose them and you update them.
- WordPress core. Yours to update, though minor security releases often install themselves.
- PHP, the web server and the operating system. On shared and managed hosting, the host’s. You might get a menu to pick between PHP 8.2 and 8.4, but the binaries behind those choices, and when they get patched, are up to the host.
Most WordPress security advice lives in the top two layers, because that’s where most WordPress vulnerabilities live. PHP2Shell is a reminder that the bottom layer can fail too, and when it does, nothing you do in WordPress matters. The attack is handled by PHP before WordPress ever runs.
Check your PHP version
In WordPress, go to Tools → Site Health → Info, open the Server section, and look at PHP version. Most hosting control panels show it too, usually under a heading like “PHP configuration” or “PHP version manager.”
Then compare it with PHP’s own supported versions list:
| Branch | Status | Security fixes until | PHP2Shell fix |
|---|---|---|---|
| 8.5 | Active support | December 31, 2029 | 8.5.12 |
| 8.4 | Active support | December 31, 2028 | 8.4.27 |
| 8.3 | Security fixes only | December 31, 2027 | 8.3.36 |
| 8.2 | Security fixes only | December 31, 2026 | 8.2.35 |
| 8.1 and older | End of life | None | No official release |
Two things to notice. PHP 8.1 and older got no fix from PHP at all. The security team published minimal source patches for 7.4, 8.0 and 8.1, but those only help someone who builds PHP themselves or a host that does it for you. And PHP 8.2 has ten weeks of security support left. If you’re on 8.2 today, you’re patched, and you’re also already planning a move.
The number isn’t the whole answer
A version number below the fixed release doesn’t always mean you’re exposed, and one above it doesn’t always mean you’re safe. Three reasons:
- Backports. Linux distributions and some hosts patch older PHP builds without changing the version number. A Debian or Ubuntu server can report an older upstream version and still carry the fix. Only the host or the package changelog can tell you.
- Old processes. Installing a patched PHP doesn’t touch the PHP-FPM workers already running. Until the host restarts them, they keep serving requests with the old, vulnerable code.
- More than one PHP. Hosts that offer a version switcher run several PHP builds side by side. The one your site uses has to be patched, not just the default.
That’s why the real check is a question to the host, not a number on a screen.
What to ask your host
Open a support ticket. Keep it short and specific, so you get a specific answer:
- Is my site running a PHP build patched for CVE-2026-109618 and CVE-2026-109619? Ask for the exact version, or confirmation of a backported fix.
- When was it deployed, and were the PHP processes restarted afterward?
- If my site is on PHP 8.1 or older, what’s my upgrade path and deadline? Some hosts provide their own extended-support builds for old PHP. Ask whether yours does and whether those builds got this fix.
- How do you notify customers about runtime security updates? An email, a status page or an RSS feed. You want to hear about the next one from them, not from the news.
- Can I control the PHP version myself, and can I test a new version before switching the live site?
A good host answers the first two in one reply, with a version number and a date. A host that can’t answer them, or that answers with “we take security seriously,” has told you something too.
Moving to a newer PHP
If the answer is that you need to upgrade, don’t flip the switch on the live site and hope. A PHP upgrade is exactly the kind of change that breaks an old plugin or a theme with code written for an older version. Do it the way you’d do any other risky change: on a copy first. That’s what a staging site is for.
- Update WordPress, your theme and your plugins first. Current versions are the most likely to support current PHP.
- Switch the staging copy to the new PHP version and turn on debug logging in its
wp-config.php. - Click through the pages and features that matter: forms, checkout, logins, search, anything a plugin provides.
- Read the debug log. Deprecation notices are warnings for the next upgrade. Fatal errors are things to fix now.
- Switch production, then watch its error log for the next day.
Jump to the newest branch your plugins support, not just the next one. Moving from 8.1 to 8.2 buys ten weeks. Moving to 8.4 buys two years.
Choose hosting like it’s a security decision
For most sites, the host is the biggest security decision nobody thinks of as one. The plugins you install matter. The PHP that runs them matters at least as much, and you’re trusting someone else to keep it patched.
PHP2Shell was a good test of that trust. Hosts that patched within hours, told their customers and could answer the questions above passed. If yours didn’t, this is a better time to find out than the next time PHP ships an emergency fix.