Blogging4 min read · 1 day ago

This PHP Vulnerability Is Serious. Is PHP Still Good in 2026?

PHP is all over my timeline again, and not for a new feature. On 21 October 2026, the PHP team disclosed a critical PHP vulnerability pair that can lead to unauthenticated remote code execution on your server.

Cue the usual “PHP is dead” posts. I wrote my first PHP script in 2015 and I still ship with PHP and WordPress every week. So here’s what actually happened, how to fix it today, and my honest take on whether PHP is still a good bet.

What the PHP vulnerability actually is

There are two bugs, both rated Critical 9.2 on CVSS v4.

The first, CVE-2026-109618, is about memory. PHP used longjmp() to bail out when a request ran out of memory. In some spots the request’s memory was only half set up when that happened, and the shutdown code then read that broken state. Attackers can force the out-of-memory condition with crafted multipart requests, like a single part carrying an unlimited number of headers.

The scary bit: on Apache mod_php this happens before any of your application code runs. The advisory says full RCE was validated over HTTP against mod_php with default limits.

The second, CVE-2026-109619, is a use-after-free. One request leaves global state (errors, sessions) pointing at memory that gets freed. The next request on the same worker touches it. RCE was confirmed on mod_php, and the session path was validated on both mod_php and PHP-FPM.

Why this one matters for WordPress folks

Most of us don’t write C. We write plugins, themes and Laravel apps. This bug doesn’t care how clean your code is. It lives in the engine.

So every unpatched WordPress site, WooCommerce store or client dashboard on an affected PHP version is exposed, whatever plugins it runs. If you manage client sites, this is a whole-fleet problem, not a per-site one.

How to fix it today

Both advisories say the same thing: updating is the only complete mitigation. Here’s the order I’d follow.

Check your version with php -v, and also check your hosting panel. CLI and web PHP can differ.
Upgrade to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or later. These shipped on 21 and 22 October.
Restart every PHP worker: FPM pools, Apache, containers. A patched binary with old workers still running isn’t patched.
On PHP 8.1 or older? There’s no patched release for you. 8.1’s last release was in December 2025. Move up.
Can’t update today? Set session.upload_progress.enabled=0 (almost nobody uses it), set fatal_error_backtraces=0 on 8.5, and block multipart requests at the proxy for apps that don’t take uploads. These reduce risk. They don’t remove it.
On shared hosting, open a ticket and ask for the exact patched version. Don’t accept “we’re on PHP 8”.

Also clean up your error logs. The second bug feeds on fatal errors and warnings, including deprecated INI settings in .htaccess. Noisy logs are now a security smell, not just bad hygiene.

So is PHP good or bad in 2026?

My take: this is a serious bug, and it’s not a reason to rewrite your stack.

I’ve worked across a lot of stacks, including React, Next.js and the newest JS libraries. Every runtime that parses raw HTTP in low-level code has bad weeks. What I judge a platform on is how it handles the bad week.

PHP handled this one well. Detailed public advisories, exploit conditions spelled out, config mitigations for people who can’t patch yet, and fixes across four supported branches within two days. That’s a mature project.

PHP’s real risk isn’t the language. It’s the long tail of servers nobody updates: the forgotten client site still on PHP 7.4, the VPS someone set up and never touched again. That’s an ops problem, and every ecosystem has it.

What I’m changing on my side

I’m still choosing PHP. WordPress is still the fastest way I know to ship content-heavy sites for real clients, and I’m active in its community for a reason.

What changes is process. Every PHP server I touch gets a patch owner, a version check in monitoring, and a plan for 8.2, which hits end of security support on 31 December 2026 under PHP’s four-year policy.

Don’t ask “is PHP dead?” Ask “who patches my servers, and how fast?”

Running PHP or WordPress for clients and not sure where you stand? Tell me what you’re running at hello@shahari.me.