Update PHP on RHEL, AlmaLinux, Rocky Linux and Amazon Linux

Only check systems you own or are responsible for.

Short answer

PHP upstream fixed the two php2shell flaws (CVE-2026-109618 and CVE-2026-109619, both critical) in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. As of 22 Oct 2026, fixed packages exist for most RHEL 8, 9 and 10 streams, for Rocky Linux, Oracle Linux and AlmaLinux where they have published an advisory, for Amazon Linux 2023 (php8.2 to php8.5), for the Amazon Linux 2 php8.2 extras stream and for Remi. Not fixed yet: RHEL 9 php:8.4 and Rocky Linux 9 php:8.4 (no advisory), Rocky Linux 8 streams other than php:7.4 and php:8.2 (no advisory found), Oracle Linux 9 streams other than php:8.2 and php:8.3 and Oracle Linux 8 streams other than php:7.4 and php:8.2 (no entry), AlmaLinux builds other than 10 php and php8.4, 9 php:8.3 and 8 php:7.4 (not confirmed), and Amazon Linux 2023 php8.1 and Amazon Linux 2 core php (“No Fix Planned”). Distro packages keep older version numbers because fixes are back-ported, so compare your installed package with the vendor’s fixed package version, not the upstream number. The fixed-versions table shows the latest status.

Why it matters

PHP’s own advisory says the flaws can allow unauthenticated remote code execution, and that all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed (php.net advisory). It rates the risk highest for mod_php. CERT-EU says initial proofs of concept have begun to circulate (CERT-EU 2026-018).

Red Hat labels its fix advisories Important (for example “Important: php security update”), and it lists fixed packages for most RHEL 8, 9 and 10 streams (see the table below; Red Hat CVE-2026-109618). That label is Red Hat’s own severity scale and does not change the php.net guidance: php.net says “only an update is a complete solution”. Its interim measures reduce exposure to specific attack paths but “do not make an installation safe”.

Fix status by distribution

Status as recorded on 22 Oct 2026. “Fixed package (or newer)” is the version-release from the vendor’s advisory. “Not confirmed” means we found no vendor advisory yet. It is not a statement about your system either way.

RHEL, AlmaLinux, Rocky Linux, Oracle Linux

Rocky Linux, Oracle Linux and AlmaLinux publish their own advisories, so their status can differ from Red Hat’s and from stream to stream, as in the table.

Amazon Linux

Remi repository

Remi’s repository has PHP builds dated 2026-10-21 for Enterprise Linux 8, 9 and 10 on the upstream fixed versions. Remi does not name the CVEs, so the fix is identified by the upstream version number. Module streams are php:remi-8.2 to php:remi-8.5 (EL 8/9) and the php82-php to php85-php packages.

The modular php package is named like php-8.4.27-1.module_php.8.4.el9.remi, which compares higher than the version in the table. Remi is a volunteer-maintained third-party repository, not a distro vendor. Source: Remi repository listing. The upstream numbers that count as fixed are the four in the short answer, from the php.net changelog.

Step 1: Identify what you run

cat /etc/os-release | head -n 3
dnf list installed 'php*'          # the last column shows the repo: appstream, remi, amazonlinux...
dnf module list --enabled php      # EL8/EL9 only: which stream is enabled

The repo column tells you which vendor’s advisory applies. Packages from appstream/baseos follow your distro; remi-* repos follow Remi.

PHP usually runs as PHP-FPM (service php-fpm) behind nginx or Apache. With Apache and mod_php, PHP runs inside httpd instead, and php.net rates that setup highest risk. Know which one you have, because it decides what to restart in step 4.

Step 2: Check whether a fixed package exists

Find your row in the tables above. Then, on the server, refresh the metadata and look at what is on offer:

sudo dnf clean expire-cache
sudo dnf check-update 'php*'      # on Amazon Linux 2023 add --releasever=latest (see below)

An empty result means no newer PHP package is available to you. That is expected for the streams marked “None yet” or “Not confirmed” in the tables. If a PHP package is listed, compare its version-release with the fixed package in your row (or confirm the vendor advisory names CVE-2026-109618 and CVE-2026-109619) before you treat it as the fix. An unrelated PHP update does not count.

Step 3: Update

Take a snapshot or backup first (VM snapshot, EBS snapshot or AMI on EC2). Do this above all if you are changing stream or major version.

RHEL, AlmaLinux, Rocky Linux, Oracle Linux 8 and 9

An update stays inside your enabled module stream. Where the table shows a fixed package for your stream, this is the fix:

sudo dnf upgrade --refresh 'php*'

Not every stream has a fix yet: RHEL 9 php:8.4 and Rocky Linux 9 php:8.4 have none, and neither do the Oracle Linux 9 streams other than php:8.2 and php:8.3. On Rocky Linux 8 and Oracle Linux 8 only php:7.4 and php:8.2 have an advisory; we found none for their other streams. AlmaLinux has published advisories for 9 php:8.3 and 8 php:7.4 only, so on its other AlmaLinux 8 and 9 streams (including 9 php:8.2, whose advisory lists no php package) we have no confirmed fix. On those, re-run the commands above each day. Moving to another stream means a different PHP version for your application, so switch only if you can test it first, for example from php:8.4 to a stream that has a fixed build on your distribution:

sudo dnf module list php
sudo dnf module switch-to php:8.3    # pick a stream with a fixed build in the table; read the plan before confirming

Moving off php:7.4 on RHEL 8 is worth planning anyway (upstream end-of-life since November 2022, per php.net/eol.php), but the fixed php:7.4 build in the table is Red Hat’s own back-port.

RHEL, AlmaLinux, Rocky Linux, Oracle Linux 10

Use package names rather than module streams. Both php (PHP 8.3) and php8.4 have fixed builds on RHEL, AlmaLinux, Rocky Linux and Oracle Linux 10:

sudo dnf upgrade --refresh 'php*'

Amazon Linux 2023

AL2023 locks each system to a release version, so a plain dnf upgrade can report nothing to do even when newer packages exist (AWS docs). Look at what the latest release would change, then apply it:

sudo dnf check-update --releasever=latest --security
sudo dnf upgrade --releasever=latest

AWS recommends installing the whole release rather than picking packages. If you must update only PHP, keep --releasever=latest and add the package names, for example sudo dnf upgrade --releasever=latest 'php8.3*'. That leaves the system-release package, and so your release lock, unchanged (AWS: selective update). AWS has published fixes for php8.2 to php8.5 (ALAS2023-2026-3301 to -3304). php8.1 has no fix: Amazon lists it as “No Fix Planned”, so plan a move to a newer PHP branch.

Amazon Linux 2

Only the amazon-linux-extras php8.2 stream has a fix (8.2.35-1.amzn2.0.1, ALAS2PHP8.2-2026-015):

sudo yum clean metadata
sudo yum update 'php*'

The PHP in the core AL2 repository is listed by Amazon as “No Fix Planned”, and Amazon gives no statement for the other extras streams. If you run either, plan a move to a PHP build that has a fix, such as the php8.2 extras stream or Amazon Linux 2023.

Remi repository (EL 8/9/10)

dnf module list php                  # EL8/EL9 only: [e] marks the enabled stream, e.g. php:remi-8.4
sudo dnf upgrade --refresh 'php*'

Remi’s wizard at rpms.remirepo.net/wizard gives the exact commands for your OS and PHP version. Remi’s multi-version installs name packages and services with the version in them, so adjust the php-fpm service name in the next step to match what systemctl list-units 'php*' shows. Remi’s package listing does not name the CVEs, so check the installed version against the Remi table above.

Step 4: Restart

An updated package does not protect you until the running processes are replaced.

sudo systemctl try-restart php-fpm httpd
systemctl is-active php-fpm httpd nginx    # confirm what is running

try-restart only restarts services that are already running. nginx does not need a restart for a PHP update when it talks to PHP-FPM. If PHP runs in a container, pull or rebuild the image and recreate the container instead.

Step 5: Verify

rpm -q php-fpm php-cli                               # names differ on AL2023 (php8.3-fpm) and Remi multi-version (php84-php-fpm)
rpm -q --changelog $(rpm -qa 'php*-common') \
  | grep -m5 -iE 'CVE-2026-10961[89]|8\.(2\.35|3\.36|4\.27|5\.12)'

• Compare the full version-release that rpm -q prints with the fixed version in the tables above or in the vendor advisory. That comparison is the authority, not php -v.
• A changelog hit naming the CVEs (or, for Remi, a build based on a fixed upstream version) is a quick second check. No hit does not prove you are vulnerable, but it means you have not confirmed a fix.
• Enter your distro release and package version in our checker to compare against the table, and see hosting status if you are on shared or managed hosting instead.

If your stream has no fixed package yet

This applies to the rows marked “No fixed package”, “Not confirmed” or “No Fix Planned” above.

• Run the update commands daily, or subscribe to your vendor’s security announcements, so you apply the fix when it ships.
• Read the interim measures on the php.net advisory. They reduce exposure only and are no substitute for the update.
• Keep SELinux and your firewall as they are. Do not loosen them while waiting.
• Building PHP from php.net source is possible, but you then own every later update and any breakage with your extensions. Do not do it just to get a version number. Distro fixes arrive as back-ports.

Need it done for your exact setup?

If you would rather not work out the right stream, repo and restart order yourself, there is a $49 personal patch plan: written steps for your exact setup by email within 24h. See the fix service.