PHP 8.5.8 and 8.4.23: security patches and why it's time to update (without the panic)

Two maintenance releases, with security fine print

Earlier this month PHP shipped 8.5.8 and 8.4.23, two of those "maintenance" releases that still carry security fixes worth a look. There's no headline CVE with a nickname here, and no exploit running loose on the internet, so no panic. But there are three fixes that, depending on what you run, range from "not my problem" to "update this week".

If you manage PHP servers — your own or your clients' — this is a five-minute read to figure out which group you're in.

In one sentence

Three things get closed: a memory corruption in openssl_encrypt when using the AES-WRAP-PAD mode, a bypass of the magic .phar directory protection, and an inheritance cache flaw in Opcache that can leave unstable states under load. The first is the most serious by nature (memory corruption) but also the hardest to trigger; the other two hit more people, more quietly.

The good news: it's fixed by updating the package and reloading PHP-FPM. No machine reboot.

The three fixes, ordered by what you should look at first

1. Memory corruption in openssl_encrypt (AES-WRAP-PAD)

This is the scariest for what it is — heap corruption — but with a very specific condition: it only triggers if you encrypt with the AES-WRAP-PAD mode. That's an uncommon mode (key wrapping, not everyday data encryption), so most applications never touch it. If you don't use openssl_encrypt with that algorithm, you're not affected; if you use it to wrap keys, it's your number one priority. Fixed in 8.4.23.

2. Bypass of the .phar directory protection

PHP specially protects the "magic" .phar directory to prevent improper access inside Phar archives. This patch closes a bypass of that protection: paths starting with /.phar are now handled correctly, while still respecting normal directories that happen to share that prefix. It matters if your application manipulates Phar files or loads code packaged in .phar (some frameworks and distribution tools do). Fixed in both versions.

3. Opcache inheritance cache (inheritance cache replay)

The quietest one, but probably the one that touches the most people. Opcache caches class inheritance so it doesn't recompute it on every request; under reentrant autoloading in heavy workloads, that cache could "replay" unsafely and leave unstable states. It isn't an entry point for an attacker, it's more of a robustness bug that shows up in large apps with deep class hierarchies and high traffic. Fixed in both versions.

Who's affected

• Everyone, to some degree: any PHP on the 8.5 and 8.4 branches earlier than these versions has all three flaws.
• High priority: anyone using openssl_encrypt with AES-WRAP-PAD (rare, but if that's you, run) and anyone working with Phar files.
• Everyone else: mostly you get the Opcache robustness improvement. Not screaming-urgent, but it's a clean update with no excuse to put off for months.

What to do today

No fluff: check your version and update to the one for your branch.

1. Check which version you have

php -v

• On the 8.5 branch, the target is 8.5.8 or newer.
• On the 8.4 branch, the target is 8.4.23 or newer.

2. Update and reload PHP-FPM (no downtime)

# Debian / Ubuntu (Ondřej Surý's repository)
sudo apt update && sudo apt install --only-upgrade php8.5 php8.5-fpm
sudo systemctl reload php8.5-fpm

# RHEL / AlmaLinux / Rocky (Remi repository)
sudo dnf update php php-fpm
sudo systemctl reload php-fpm

Reloading PHP-FPM swaps in the new binary without cutting in-flight requests. Adjust the version number (php8.5 / php8.4) to whatever you have installed.

3. Confirm it stuck

php -v
php-fpm8.5 -v   # or php-fpm -v depending on your distro

As always with distributions: sometimes they backport the fix while keeping a different version number. Don't trust the number alone, check the package date or your distro's security changelog. Same old lesson: "it's updated" is something you verify, not something you remember.

What we do

As soon as PHP security releases land, we go through the servers we manage, prioritising the ones exposing internet-facing apps and, within those, the ones that match the specific flaw (here, anything touching Phar or OpenSSL encryption). For the rest, it goes into the normal update round. The point isn't to chase every point release, it's to keep the patch plan current so a release like this is a ten-minute chore rather than a to-do that drags on for half a year.

The same old routine

• php -v to know where you stand.
• apt/dnf update of PHP and PHP-FPM.
• systemctl reload php*-fpm.
• php -v again to confirm.

If your PHP hasn't seen a patch in months, or you're not sure whether you use Phar or openssl_encrypt in some corner of your code, it's a good time to check. And if you'd rather we handle it, let's talk.

References

• PHP releases 8.5.8 and 8.4.23 with security patches — LinuxCompatible
• PHP.net — Downloads and changelog