Red Hat 9490 CentOS 5535 Fedora Linux 9486 Published by

Remi Collet has published testing builds of PHP 8.4.28RC1 and 8.5.13RC1 in his repository for Fedora 43–45 and RHEL-based distros like CentOS Stream, AlmaLinux and Rocky Linux. Both supported branches can be installed as base packages in the remi-modular-test repo or as Software Collections via remi-test for safe parallel testing. The releases arrive just months after the PHP2Shell security flaws forced operators to rush toward 8.4.27 and 8.5.12, making these RCs a natural next step in the upgrade path. 



Remi ships PHP 8.4.28RC1 and 8.5.13RC1 testing builds for Fedora and RHEL-based distros

Remi Collet announced on Friday that testing builds of PHP 8.4.28RC1 and 8.5.13RC1 are now live in his repository. They're set up for Fedora 43 through 45, and for RHEL plus the usual sprawl of free clones: CentOS Stream, AlmaLinux, Rocky Linux and friends.

Release candidates are the final freeze before a stable release ships. Their whole purpose is to let the community hammer on an upcoming version in real conditions before it goes live. For admins who lean on Remi for PHP newer than what their distro ships by default, these builds are the first real chance to try the next round of code in a controlled, parallel setup.

Gnome_shell_screenshot_09fnu0

You have two ways in. Remi ships both base packages and Software Collections for parallel installation. Base builds land in the remi-modular-test repository, while the SCL versions live in remi-test. He puts it plainly in the post: "They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages." So you can poke at the new code without disturbing the system PHP.

A quick detour on who's behind this. Collet has been shipping PHP for the Fedora and RHEL world for over two decades, and he does it with a foot in both worlds. He maintains Red Hat's official PHP packages by day and runs this independent repository on the side since 2005. That's why the testing builds carry weight, they're cut with the same care as upstream, just faster. The repo itself moves on the order of 15,000 RPM downloads a day. At this point, it's hard to imagine the Fedora and RHEL PHP ecosystem without it.

Everything's built for x86_64 and aarch64. The packages compile against toolchains you'd expect for each tier: EL-10 against RHEL 10.2 and EPEL 10.2, EL-9 against RHEL 9.8, EL-8 against RHEL 8.10. Two extension specifics are worth flagging. The oci8 extension bundles Oracle's Instant Client 23.26, and intl is built against libicu 74.2. Keep in mind that second one if your apps lean heavily on internationalization.

New in 8.4 and 8.5

PHP 8.5 is the branch under the spotlight here. It hit GA on 20 November 2025, and its latest stable patch is 8.5.12, a security release from 22 October 2026. Support runs until 31 December 2027, with end-of-life landing two years later on 31 December 2029.

The headline additions are a new URI extension for parsing and normalizing URLs, a pipe operator written as |>, and a clone() "with" syntax that lets you tweak properties while cloning. There's also a #[\NoDiscard] attribute that nudges you when you toss away a return value, persistent cURL share handles to avoid reconnecting to the same hosts, and convenience helpers like array_first() and array_last().

PHP 8.4 is the previous branch, and it stays supported through 31 December 2026. Property hooks were its marquee feature, native get/set logic that IDEs actually understand, trimming a lot of getter/setter boilerplate. Asymmetric visibility, an object-oriented BCMath with an immutable Number class, and ext-dom with real HTML5 parsing round out the interesting stuff. A small but oddly satisfying touch lets you call methods on a freshly created object directly, no parentheses needed.

The PHP2Shell backdrop

The reason anyone's paying attention right now isn't the new syntax. It's the PHP2Shell vulnerabilities.

On 21 October, the PHP project shipped emergency fixes for two critical flaws. CVE-2026-109618 is a use-after-free in the upload-progress unserializer that hands attackers unauthenticated remote code execution. CVE-2026-109619 is another use-after-free, this one in the fatal-error backtrace path, opening the same door. Both carry a CVSS v4.0 score of 9.2.

Since both live in the request lifecycle, they can fire before application code even runs, and both Apache mod_php and PHP-FPM are affected. The guidance was pretty blunt. There were no complete mitigations. Just update.

CISA, CERT-EU and Google Cloud all issued urgent advisories. A third RCE vector turned up two days later, though PHP chose not to cut yet another out-of-band release for it. The point, really, is that operators were under intense pressure to reach at least 8.4.27 and 8.5.12 by late October.

That pressure frames Remi's announcement nicely. These RCs are the next increment on each branch, and since they normally equal the final release, testing 8.4.28RC1 and 8.5.13RC1 is basically validating your upgrade path ahead of time. If nothing blocks the testing, both will very likely ship as 8.4.28 and 8.5.13. Keep in mind that 8.5.13RC1 is already sitting in Fedora rawhide for QA. Meanwhile, PHP 8.3 has slipped into security-only mode, so no more RCs will come for it, and 8.6.0RC5 is already in the repo as a look ahead at the next major line.

Getting the installs done

You can drop in an RC in parallel without touching system PHP:

yum --enablerepo=remi-test install php85

Or switch the modular stream over entirely:

dnf module switch-to php:remi-8.5

For 8.4, swap in php84 and php:remi-8.4 instead. Remi recommends running his configuration wizard first so the repo matches your specific distro and version. Head here to set it up.

It's a low-risk way to prep for the next PHP bump, and the parallel-install approach is genuinely handy since you're not gambling with production. However, at the same time, these are testing builds. Treat them as preview material, not production. The finals should land roughly two weeks out, assuming nothing blocks, you'll know when the repos move to the shipping versions.