PHP2Shell on RHEL, Rocky and Oracle Linux: Errata and Streams

As of 23 October 2026, Red Hat has shipped PHP2Shell fixes (CVE-2026-109618 and CVE-2026-109619) for every supported PHP stream on RHEL 10, 9 and 8 except one: RHEL 9's php:8.4 stream is still listed as "Affected." Rocky Linux and Oracle Linux published matching errata on 21 and 22 October. Retired streams, such as php:8.1 on RHEL 9 and php:7.2, 7.3 and 8.0 on RHEL 8, have no Red Hat fix.

The fix on RHEL-family systems is a normal dnf update followed by a PHP-FPM or Apache restart. Verifying it is where people get caught. Most of the fixed builds are "rebases" to PHP's own fixed releases, and their RPM changelogs say only "rebase to 8.3.36" without naming any CVE. If you grep the changelog for CVE-2026-109618 on a fixed RHEL 10 server, you get nothing. Check the version instead.

This page lists the errata by release and stream, explains which checks work, and covers the streams that are not fixed. AlmaLinux has its own page, because it shipped earlier and patched more streams: see PHP2Shell on AlmaLinux.

Red Hat, Rocky and Oracle Errata by Release

Red Hat data comes from its CVE-2026-109618 security data, re-read on 23 October 2026. Oracle builds come from its ELSA pages, and Rocky advisories from its errata service. Rocky and Oracle reuse Red Hat's advisory numbers.

Red Hat's extended-support customers got separate errata on 23 October 2026: RHSA-2026:88561 for RHEL 10.0 EUS (php-8.3.19-1.el10_0.2), RHSA-2026:88565 for RHEL 8.4 AUS and EUS Long-Life, RHSA-2026:88533 for RHEL 8.6 AUS and EUS Long-Life, and RHSA-2026:88532 for RHEL 8.8 TUS and SAP. The 10.0 EUS build keeps PHP 8.3.19, so it is a backport, not a rebase. Match your installed build against the advisory for your exact stream.

Red Hat's errata also fix other PHP bugs. The RHEL 10 advisory includes a SOAP parser denial-of-service fix (CVE-2026-91765), and Oracle's text for the RHEL 8 php:7.4 erratum lists 13 CVEs in total. Expect a larger change than PHP2Shell alone on RHEL 8 with PHP 7.4.

The Changelog Trap: Why grep Finds Nothing on a Fixed Server

Many admins verify a security fix by searching the RPM changelog for the CVE. On RHEL-family systems this works for some PHP builds and silently fails for others.

• Rebased builds name no CVE. When Red Hat moved a stream to PHP's own fixed release, the changelog entry is just a version note. Oracle's errata reproduce them: "[8.3.36-1] - rebase to 8.3.36" and "[8.4.27-1] - rebase to 8.4.27". The php:8.2 and php:8.3 modules read "rebase to 8.2.35" and "rebase to 8.3.36".
• Backported builds do name the CVEs. The php:7.4 entry reads "[7.4.33-8] - Avoid state corruption via bailout CVE-2026-109618, CVE-2026-109619", and RHEL 9's PHP 8.0 build has the same wording.

So an example command such as rpm -q --changelog php-common | grep CVE-2026-109618 returns a match on a fixed PHP 7.4 or 8.0 build, and returns nothing on a fixed PHP 8.2, 8.3 or 8.4 build. An empty result does not mean you are vulnerable, and a "how to verify" guide written for another vendor (CloudLinux, for example, tells its customers to grep changelogs for its backported packages) does not transfer to RHEL rebases.

Red Hat's backporting policy adds the opposite warning: "just looking at the version number of a package will not tell them if they are vulnerable or not," and version-only scanners produce false positives. On RHEL you need both ideas at once. For rebased streams, the version is the proof. For backported builds, the changelog or the advisory is.

How to Verify the Fix

Use the method that matches your build. Package names below are examples; on RHEL 10 with PHP 8.4 the packages are named php8.4-*.

1. Check the installed version. rpm -q php-common (or rpm -q php8.4-common). Rebased builds must be 8.2.35, 8.3.36 or 8.4.27 or later. Backported builds must match the release string in the advisory, such as 8.0.30-8.el9_8.1.
2. Ask dnf about the advisory. dnf's command reference documents a --cve filter for updateinfo, and an --installed mode that covers advisories for versions you already have. Example: dnf updateinfo list --installed --cve CVE-2026-109618. This relies on the repository publishing advisory metadata, which Red Hat does. Rebuilds and third-party repos may not.
3. Confirm the running processes restarted. The dnf-plugins-core command dnf needs-restarting -s lists systemd services that still use files replaced by an update.

Our guide on how to check your PHP version covers finding which PHP binary serves your site, and the PHP2Shell version lookup checks a version string.

How to Update and Restart

Red Hat's application instructions are linked from every advisory (its article on applying updates). The RHEL clones document the same commands. AlmaLinux, for example, gives sudo dnf clean metadata && sudo dnf upgrade 'php*' followed by sudo systemctl restart php-fpm, and sudo systemctl restart httpd where PHP runs as an Apache module.

1. Find your stream on RHEL 8 or 9: dnf module list php.
2. Apply the update: sudo dnf upgrade 'php*' (example).
3. Restart PHP-FPM, and Apache if it runs mod_php: sudo systemctl restart php-fpm (example).
4. Verify with the steps above.

Red Hat notes that "Standard Red Hat Enterprise Linux deployments use PHP-FPM rather than mod_php," which is why it rates the CVEs lower than PHP does. That is a reason the risk may be lower on a default install, not a reason to wait. After patching, PHP's 23 October advisory for CVE-2026-115560, which affects fully patched releases, suggests setting session.upload_progress.enabled=0 in php.ini or the FPM pool "until the next regular bugfix release." Our guide to restarting PHP workers covers restart versus reload and long-running workers.

Streams Without a Red Hat Fix

These systems remain exposed unless you move them or get PHP from another source:

dnf documents dnf module switch-to for changing streams; for example, sudo dnf module switch-to php:8.3. A stream switch changes your PHP version and can break an application, so test it on a copy first. Red Hat supports the php:8.2 stream on RHEL 8 and 9 until May 2029, after PHP's own 8.2 end of life on 31 December 2026. TuxCare lists RHEL 7 and CentOS 7 in its extended support, but we could not read its fixed versions; see PHP2Shell on CloudLinux and TuxCare.

Rocky Linux and Oracle Linux Notes

Rocky Linux published seven advisories between 22 October 00:01 UTC and 12:01 UTC, matching Red Hat's RHEL 8, 9 and 10 errata. Oracle Linux published ELSAs for Oracle Linux 10, 9 and 8 on 21 and 22 October. Oracle's CVE page shows "Impact: Important" and a preliminary CVSS 3 base score of 8.1, the same as Red Hat. No Oracle Linux 6 or 7 PHP erratum is listed. Neither project lists a php:8.4 fix for version 9, which matches Red Hat.

PHP That dnf Does Not Update

An OS update only touches PHP from the distribution's own repositories. Remi's repository shipped PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on 22 October with no end-of-life builds listed. See Sury and Remi PHP repositories. cPanel's ea-php, Plesk's PHP handlers and container images each have their own update path. On a VPS or dedicated server, all of this is your job. On managed hosting, ask your host which build serves your site. Our guide to the shared responsibility model explains where that line usually falls. Our security patching best practices cover keeping that inventory current.

Conclusion

As of 23 October 2026, RHEL 10, 9 and 8 have fixed PHP for every supported stream except RHEL 9 php:8.4, and Rocky and Oracle Linux match Red Hat. Update with dnf, restart PHP-FPM and Apache, and verify by version for rebased builds and by changelog or advisory for backported ones. Do not treat an empty changelog grep as a failed patch. If you run a retired stream or RHEL 7 and need help planning the move, our emergency PHP patching team can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions