PHP Security Update: Remi Pushes Critical Fixes for Versions 8.2 Through 8.5 on RHEL and Fedora
Remi Collet just released a batch of PHP updates that address a significant number of security vulnerabilities across multiple versions. If you are running Enterprise Linux distributions like RHEL, AlmaLinux, or Rocky, or Fedora 42 and newer, there are packages available for PHP 8.2.31, 8.3.31, 8.4.21, and the latest 8.5.6. The list of fixed issues is long enough that delaying this update leaves your server exposed to known exploits. Remi marks these releases as strongly recommended for a reason, and applying them should be at the top of your maintenance queue.
Why this PHP update matters now
Each version in this release cycle fixes between eight and thirteen security bugs, including CVE-2026-7259, CVE-2026-7261, and CVE-2026-7262 among others. These are not minor edge cases; they represent active vulnerabilities that can be leveraged for remote code execution or information disclosure. I have seen servers get compromised after admins ignored a patch cycle because the issues sounded too technical to matter. The reality is that automated scanners target these exact CVEs within hours of public disclosure. Updating now closes those doors before attackers start knocking.
How to apply the update safely
Remi provides two main paths for installation depending on whether you want to replace your current PHP version or run a parallel instance. The module switch method is usually the cleanest approach if you are ready to move your stack to the new version. On Enterprise Linux systems using dnf 4, running dnf module switch-to php:remi-8.5/common handles the stream swap and package updates in one command. This reduces the risk of leaving dependencies in a broken state during the transition.
Fedora users on dnf 5 need to follow a slightly different sequence because of how modules are managed in that environment. You must reset the existing PHP module first using dnf module reset php, then enable the Remi stream with dnf module enable php:remi-8.5, and finally run dnf update to pull everything down. This two-step reset prevents conflicts where old metadata might block the new packages from installing. If you need to test the new version without disrupting production, Software Collections offer a safe sandbox. Installing php85 via yum install php85 keeps the new binaries isolated so existing applications continue running on their current PHP version while you verify compatibility.
Extension and backend changes to watch
There are a few underlying library shifts in this release that could affect how your application behaves. The intl extension now relies on libicu version 74.2, which might change locale formatting for dates or numbers if your code depends on specific regional standards. On Enterprise Linux builds, the mbstring extension has switched to using oniguruma5php version 6.9.10 instead of the system library. This is a practical move since it removes an outdated dependency that often causes compatibility headaches during upgrades.
Oracle database users will find that the oci8 extension now bundles Instant Client version 23.26 for both x86_64 and aarch64 architectures. You no longer need to hunt down external drivers or worry about mismatched client versions. The RPMs are also built against specific RHEL release bases, with EL-10 using RHEL-10.1, EL-9 using 9.7, and EL-8 using 8.10. This ensures the binaries align closely with the base system libraries for maximum stability.
Upcoming official repository updates
If you are running a newer Fedora release, these versions will hit the official repositories shortly. Fedora 42 and 43 are set to receive PHP 8.4.21, while Fedora 44 and Rawhide get the latest 8.5.6. This means users on those distributions can expect to pull these updates through standard update channels soon without relying on third-party repos once the rollout completes.
️ PHP version 8.2.31, 8.3.31, 8.4.21 and 8.5.6
RPMs of PHP version 8.5.6 are available in the remi-modular repository for Fedora ≥ 42 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).
Check your application logs after updating, run a quick smoke test of your critical endpoints, and verify that extensions are still loading correctly. PHP 8.2 is old enough now that staying current matters more than ever for both security and performance. Keep those servers patched and move on to whatever else needs attention.
