PHP2Shell: a practical patch guide for web admins

Most website owners never think about PHP until something goes wrong. It quietly runs WordPress, many shop platforms, control panels and countless in-house tools. In October 2026 two memory-safety flaws in the PHP runtime, nicknamed PHP2Shell, moved from "patch soon" to "patch now" when the US Cybersecurity and Infrastructure Security Agency (CISA) added them to its Known Exploited Vulnerabilities catalog after confirming attacks.

What we know

The PHP project released fixes on 21 October 2026 in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. According to public reporting, the flaws can allow remote code execution under certain conditions, and attackers have been seen chaining them with other bugs. PHP 8.1 and older branches are past their upstream support and did not receive fixes from the PHP project itself, although some Linux distributions backport security patches to the versions they ship.

Step 1: find every PHP you run

The hardest part is usually inventory. PHP hides in more places than people expect:

• Web servers and virtual hosts, sometimes with several PHP versions side by side.
• Container images built months ago and never rebuilt.
• Control panels, monitoring tools and old intranet apps.
• Shared hosting accounts managed by someone else.

On a Linux server, php -v shows the command-line version, but the web server may use a different one through PHP-FPM. Check each FPM pool and each container image. Your package manager will show what the distribution has installed, and whether it includes a backported fix.

Step 2: upgrade and restart

1. Upgrade to the fixed release for your branch, or to the distribution package that includes the backport.
2. Restart PHP-FPM and the web server. A patched package on disk does nothing while the old process is still running.
3. Rebuild and redeploy containers so they pick up the new base image.
4. If you are on PHP 8.1 or older with no backport, plan an urgent upgrade to a supported branch. Test the application first, because older code can break on newer PHP.

Step 3: check whether you were hit

Patching closes the door but does not tell you whether someone walked in earlier. Look at web server logs for unusual requests in the weeks before you patched, unexpected files in upload or cache directories, new admin users in your application and outbound connections from the web server to unfamiliar addresses. If anything looks wrong, treat the server as compromised: rebuild from a clean source and rotate every secret the server could read, such as database passwords and API keys. Our note on the incident response lifecycle walks through the order of work.

If you use shared hosting

You probably cannot patch PHP yourself. Open a ticket and ask your host directly whether its servers run a fixed version, and when it was applied. Make sure your WordPress core, themes and plugins are also up to date, because attackers often combine several weaknesses.

The habit to build

Keep a simple list of every server and image, the PHP version it runs and who owns it. Subscribe to your distribution's security notices. When a KEV listing appears for something on that list, it becomes a same-day job, not a next-sprint ticket. Our patch management and vulnerability prioritisation notes cover how to make that routine.

Sources

• BleepingComputer: CISA confirms PHP2Shell vulnerabilities now exploited in attacks
• The Hacker News: CISA confirms active exploitation of PHP2Shell
• Unosecur: October 2026 cyberattacks, breaches and incidents