October 23, 2026: PHP has warned of another security flaw just two days after it released emergency fixes for two critical vulnerabilities known as PHP2Shell.
The new issue is tracked as CVE-2026-115560. It could allow an attacker to run code on a web server, but only if the website uses an uncommon combination of PHP session settings. PHP says this setup is rare in practice and has not issued an emergency patch for it.
The flaw involves the session upload progress feature. For an attack to work, the application must set the session serialize handler to php_binary or php_serialize in its configuration, then switch it to php at runtime using ini_set() before calling session_start(). Session upload progress must also still be enabled. Most websites do not change the serialize handler at runtime, so they are not affected by this particular issue.
PHP has asked website administrators to disable the session upload progress feature by setting session.upload_progress.enabled=0 until the next regular bugfix release. This is the same setting it had already recommended two days earlier as a partial protection for one of the PHP2Shell flaws. Those who already made the change do not need to do anything further.
Is this the beginning of the end for WordPress?
After this week’s PHP and WordPress security fallout, I’ve had a lot of conversations with business owners asking whether they should still be building on PHP at all.
Look at what hit in the space of a few days:
• PHP2Shell (CVE-2026-109618 / 19): a critical pre-auth PHP flaw that took 32 UK government services offline and forced NHS boards and local councils to pull sites
• Rank Math PRO (v3.0.123): a compromised plugin update that pushed a backdoor straight to sites doing routine updates
• UpdraftPlus: stolen UpdraftCentral keys used to install fake plugins and plant rogue wpsupport_* admin accounts
The uncomfortable truth is that the biggest risk isn’t just PHP itself. It’s the traditional plugin stack.
A typical WordPress site isn’t one piece of software. It’s 25 to 40 third-party plugins all running inside the same live PHP process, sharing full access to your database and server. If one plugin vendor slips up or gets breached, attackers have the keys to the whole site. And because updating 30 plugins on a live server often breaks layouts or forms, teams put off patching when they need it most.
Will this kill WordPress overnight? No. It still powers around 43% of the web, and large publishing teams tied into its editorial workflow aren’t moving tomorrow.
And to be completely fair, modern frameworks aren’t immune to security bugs either. Node.js and Next.js need patching too.
The difference is the architecture and how fast you recover:
No plugin roulette: Instead of bolting 30 third-party plugins onto a live SQL database just to run a brochure site, AI coding agents write and maintain clean code in Git.
Nothing live to brute-force: On Vercel, pages are built ahead of time and served from the edge. There is no live PHP runtime, no /wp-admin login page, and no database sitting exposed on the web server.
Patching takes minutes, not days: When a security patch dropped for our modern stack this week, an AI agent updated, built, verified, and redeployed 6 of our Vercel sites in minutes via Git pull requests. No broken plugins, and no hunting through wp_users for hidden admin accounts.
WordPress isn’t dead, but its days as the automatic default for every new business website are over. For marketing sites, landing pages, and client portals, the smart move is shifting to agent-maintained code on Vercel.
If you’re still on WordPress today: check your PHP version (8.2.35+, 8.3.36+, 8.4.27+ or 8.5.12+), update Rank Math and UpdraftPlus (1.26.13+), and check your user list for any admin accounts you don’t recognise.
Are you sticking with WordPress for your next build, or moving off the plugin stack?
#WordPress #WebSecurity #PHP2Shell #Vercel #NextJS #WebDevelopment #CyberSecurity #DigitalAgency #TechLeadership #UKBusiness
— Dean 🇬🇧 (@MrMontandon) October 23, 2026
The earlier PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619, were fixed on October 21 in PHP versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Both were rated critical and could let an unauthenticated attacker run code on a server. According to Cloudflare, hacking attempts targeting those two flaws have surged into the millions.
No exploitation of the new vulnerability has been reported so far. PHP considers it an unlikely attack vector and will address it in its next routine release along with a full advisory. Administrators running websites with non-standard session configurations are advised to check their settings and disable session upload progress as a precaution.
Leave a Reply