A quick one outside the normal schedule, because this can't wait until Sunday.
On October 21, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now being called PHP2Shell. Both are rated 9.2 out of 10. Both can let someone on the internet run their own code on a web server running PHP, without a username or password.
As a solo or small shop IT provider you probably aren’t directly responsible for PHP. However I would check with all your vendors and make sure that you have it in writing that it’s either getting patched or that they aren’t vulnerable to it.
This one reminds me a lot of the Heartbleed vulnerability that came out back in 2014, it was all hands on deck for a few days while we got our server farm patched.
Why this one matters to a small shop
PHP runs a huge share of the web: WordPress, most hosting control panels, and a lot of the intranet tools and vendor portals nobody remembers installing. Researchers say every PHP install that serves web pages is affected, whether it runs as Apache mod_php (the riskiest), PHP-FPM, php-cgi, LiteSpeed or FrankenPHP.
This isn't theoretical either. Amazon's honeypots caught an exploitation attempt on October 17, four days before the fixes were public, and proof of concept code is already out. Rapid7 says the current exploits only work on specific setups and none is broadly reliable yet, but they expect that to change.
First thing I'd check: where is PHP running?
The hard part isn't patching. It's finding every copy.
Your website. If it's WordPress or anything else built on PHP, it counts.
Your hosting company. On shared hosting you can't patch PHP yourself. Email your host today and ask: "Have you updated PHP for CVE-2026-109618 and CVE-2026-109619?" Some hosts, like SiteGround, put protections in place before the release.
Internal web apps: the intranet, the old ticket system, the wiki, the help desk portal.
Vendor appliances and anything with a web admin page. Some bundle their own PHP. Check each vendor's security advisory page.
Windows servers. PHP sometimes ends up in a random folder under IIS for one app.
On Linux, php -v shows a version, but be careful: the command line PHP can be a different install than the one serving web pages. Check the web server's PHP too, through your control panel or a phpinfo page you delete right after.
What to patch to
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you install PHP from your Linux distribution, use their update instead. Distributions got the patches early and may keep the old version number.
PHP 8.1 and older are past end of life. The PHP team released limited source backports for 7.4, 8.0 and 8.1, but the real fix is upgrading to a supported version.
After patching, restart the web server and the PHP workers. Patching the files without restarting leaves the old code running.
If you can't patch today
These reduce the risk. They don't fix it.
Put the site behind a web application firewall. Cloudflare says it has rules for the known exploit methods, including on its free plan.
Turn off session upload progress: set
session.upload_progress.enabled=0in php.ini or the FPM pool config, then restart. Setting it from inside the app is too late.Limit who can reach it. An internal app that doesn't need to be on the internet shouldn't be. For anything you can't fix right away, the UK's NCSC advises taking it offline until you can.
How to explain this to management
Three sentences, risk and date first, CVE numbers never:
"A critical flaw in PHP, the software behind our website and [other systems], lets attackers take over a web server without a password, and attacks have already started. I'm patching [systems] by [day]. The one thing I need from you is [a maintenance window / approval to take X offline until it's fixed]."
The short checklist
List every system running PHP: website, hosting, internal apps, appliances
Ask your host and vendors to confirm they're patched
Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's update
Restart the web server and PHP workers
Mitigate or take offline anything you can't patch yet
Tell management in three sentences
Back to the normal schedule Sunday with Issue 2: the firewall.
Talk soon,
Patrick
