Remi Ships PHP Security Patches for Fedora and RHEL After Two Critical Vulnerabilities
A pair of unauthenticated remote-code-execution flaws hit every supported PHP branch. The patches are already live in Remi's repo.
Two critical vulnerabilities that let an attacker run code without ever logging in just walked through PHP's entire active release line. PHP shipped the fixes on 21 October 2026 across PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. A day later, Remi Collet posted the matching RPM packages for Fedora and RHEL-based systems.
If you host anything on these distros, that second step is probably the part you actually care about. Remi tracks upstream faster than the vendor repos, so his builds tend to arrive first.
The PHP team rated both flaws at CVSS v4.0 9.2, which lands squarely at "Critical." Their advisory was unusually blunt, saying there are no real mitigations and that updating is the only safe move. That's not PR boilerplate. They mean it.
The two bugs
Both flaws were disclosed together and they share a theme: long-running PHP workers that forget to clean up after themselves. PHP lives or dies on these workers, mod_php, PHP-FPM, CGI, FrankenPHP, LiteSpeed, so the details matter more than usual here.
CVE-2026-109618 is a memory-exhaustion-to-code-execution trick. PHP uses longjmp() to bail out when it runs out of memory, which is normally fine. The problem is that in some cases request memory only gets partially set up before the allocation fails, so the cleanup routine ends up running against half-built state. Feed it the right kind of garbage and it branches somewhere it really shouldn't.
An attacker can push PHP over the edge several ways. A multipart request without a proper Content-Length can slip past the size check and keep coming. A single part can carry an unrestricted pile of headers that cost far more memory inside PHP than on the wire. Empty file controls don't count toward max_file_uploads but still allocate memory. Nested field names just multiply the damage.
mod_php is the worst case by a fair margin. It runs the shutdown procedure unconditionally, even when startup failed and before any application code runs. PHP validated a complete HTTP-based exploit against mod_php with default settings and a normal multi-worker prefork setup. FPM is thought to be reachable by source analysis, but nobody's actually demonstrated a working exploit there. FrankenPHP looks similar to mod_php. LiteSpeed is "likely but unvalidated," which is developer-speak for "probably, we didn't bother."
The fix removes longjmp() entirely. A delayed, graceful soft memory-outage now runs at the next VM-safe point, with a hard exit kicking in once memory crosses a second, higher threshold. Cleaner shutdown, same memory caps.
CVE-2026-109619 is the nastier one. PHP workers keep global state that still points at memory from the previous request, and that state is supposed to get reset before the next request starts. Sometimes operations run before that reset happens, so they read stale leftovers. It's a use-after-free, and a crafted heap layout turns it into full RCE.
The exploit needs two separate requests on the same worker. First a "producer" stores request-owned state globally and fails to reset it, usually because a fatal error abandoned the operation early. Then the request's heap gets freed while the worker still points at it. Finally a later "consumer" reads that stale state before the reset runs.
Two confirmed pairs exist, and both are a little embarrassing. The strongest is INI diagnostics firing before PHP finishes starting up. Warnings, notices and deprecations emitted while applying INI settings can grab the stale error state, including deprecations like auto_detect_line_endings=1, legacy assert settings, and invalid values for memory_limit, date.timezone and open_basedir. Hiding the warning with error_reporting, display_errors or the @ operator doesn't help, because PHP reads the global state before it decides whether to report anything at all.
The other confirmed path is session upload progress, which ships enabled by default and needs no session_start() call.
Getting the update
Remi posted everything to the remi-modular repository on 22 October, with the parallel-installable Software Collections in remi-safe under the names php82, php83, php84 and php85. Fedora 43 and up, Enterprise Linux 8 and up, on both x86_64 and aarch64. All signed with his GPG key, as always.
To replace your system PHP on an Enterprise Linux box:
dnf module switch-to php:remi-8.5/common
On Fedora, which now ships dnf 5:
dnf module reset php dnf module enable php:remi-8.5 dnf update
Swap the version number if you're on an older branch. Don't want to disturb the system PHP? Install a Software Collection in parallel instead:
yum install php85
Remi runs a Configuration Wizard that generates the exact commands for your setup, so use it. Then verify with php -v like a responsible adult.
The PHP advisory keeps saying the same thing in different ways, and that updating is the only real fix. But they did hand out a few half-measures if you genuinely can't patch right now. For the memory bug, set memory_limit=-1 administratively so applications can't reset it to a finite value, keep post_max_size conservative, and use a container or cgroup limit as a hard boundary. Don't use RLIMIT_AS or RLIMIT_DATA, because those actually trip the vulnerable path.
For the stale-state bug, disable session.upload_progress.enabled and restart your workers, and on 8.5 set fatal_error_backtraces=0. Also get rid of the invalid INI settings causing the pre-init diagnostics. Hiding them does nothing. For what it's worth, these buy you time, not safety, and you should treat them as temporary until you patch.
Where each branch stands
Here's the part more people should care about than the CVEs themselves. PHP 8.2 hits end-of-life on 31 December 2026, which means 8.2.35 is almost certainly the last security release for that branch. If your code still runs on 8.2, the clock is ticking and there's no LTS vendor rescue coming.
8.5 is the current feature branch, having gone GA on 20 November 2025. 8.6 is in testing, with RC3 shipping 8 October and RC4 landing the day after this update. 8.4 and 8.3 sit in security-only maintenance. 8.1 was already retired back on 8 January 2026, and Remi dropped it from the repository accordingly.
The PHP team also published minimal source backports for the long-dead 7.4, 8.0 and 8.1 lines, for anyone building from source with no LTS vendor behind them.
A wrinkle worth a glance
In a nice bit of follow-the-leadership, the PHP advisory itself carried a caution aimed at third-party packagers, saying the volunteer-maintained remi repo wouldn't have updates that day. Remi had, apparently, not yet built anything. The caution was honest at the time. It was also a day stale.
His blog post on 22 October confirms all four branches went live within 24 hours, and remi users are covered. The episode is a decent reminder of how this ecosystem actually works: PHP ships the code, Fedora's Jitka Plesnik folds it into official updates, and volunteer packagers provide the fastest route for people who don't run a stock distro.
Remi is, for the record, a French-based contributor who's been shipping Fedora packages since 2005 and works at Red Hat between hobbies.
So, update if you can, mitigate if you must, and if you're still on PHP 8.2 treat that end-of-life date as a real deadline rather than a suggestion.
Head here to Remi's blog post for the full changelog and build notes, and here to his Configuration Wizard if you want the exact commands for your system.
