PHP2Shell.fyi Check a site

PHP2Shell on RHEL, AlmaLinux and Rocky Linux

Red Hat, AlmaLinux and Rocky Linux fix PHP2Shell per release and per PHP stream. Many fixed builds keep an older PHP number, so php -v cannot tell you. Compare the rpm version with the row for your release and stream.

Last reviewed . Rules of .

Find your release and stream

# release
    cat /etc/redhat-release
    # enabled PHP module stream, marked [e] (version 8 and 9)
    dnf module list php
    # installed build
    rpm -q php-common php-fpm
    # PHP 8.4 on version 10 is a separate package
    rpm -q php8.4-common php8.4-fpm

Use rpm -q, not php -v. Then find your row below.

Red Hat Enterprise Linux

Source: Red Hat RHSB-2026-013, CVE-2026-109618, CVE-2026-109619 and the errata linked per row. Checked 2026-10-22.
ReleasePackage or streamFixed versionAdvisory
RHEL 10php (8.3)8.3.36-1.el10_2RHSA-2026:87070
RHEL 10php8.48.4.27-1.el10_2RHSA-2026:87071
RHEL 9php (8.0, default)8.0.30-8.el9_8.1RHSA-2026:87151
RHEL 9php:8.2 module8.2.35-1.module+el9.8.0+25111+a1450321RHSA-2026:87072
RHEL 9php:8.3 module8.3.36-1.module+el9.8.0+25109+6886e21aRHSA-2026:87079
RHEL 9php:8.4 moduleno fix yetRed Hat lists it as affected, with no fix available.
RHEL 8php:7.4 module7.4.33-8.module+el8.10.0+25117+30337ccaRHSA-2026:87080
RHEL 8php:8.2 module8.2.35-1.module+el8.10.0+25110+f67151d2RHSA-2026:87073

RHEL 7 and RHEL 6

Red Hat's sources disagree on 22 October 2026. The bulletin RHSB-2026-013, updated that day, lists RHEL 7 as affected by CVE-2026-109619 only, and says the code for CVE-2026-109618 is not present. Red Hat's CVE data marks RHEL 6 and 7 as not affected by CVE-2026-109619, and still under investigation for CVE-2026-109618. Neither lists a fix.

Our advice: treat RHEL 7 and 6 as affected, ask Red Hat support, and plan a move to a supported release. Watch the bulletin for changes.

Red Hat says to rebuild containers built on RHEL or UBI images when the base images are updated.

AlmaLinux

AlmaLinux fixed every PHP stream on AlmaLinux 8, 9 and 10. Most fixed builds are AlmaLinux's own backports. They keep older upstream numbers, such as 8.3.33, and end in .alma.1. A plain version check would call them unfixed.

Source: AlmaLinux announcement "php2shell (CVE-2026-109618, CVE-2026-109619): Patched PHP packages released", 2026-10-21. Checked 2026-10-22.
ReleaseStreamFixed version
AlmaLinux 10default (PHP 8.3)php-8.3.33-1.el10_2.alma.1
AlmaLinux 10php8.4php8.4-8.4.24-1.el10_2.alma.1
AlmaLinux 9default (PHP 8.0)php-8.0.30-8.el9_8.alma.1
AlmaLinux 9php:8.1php-8.1.32-1.module_el9.8.0+326+528679fc.alma.1
AlmaLinux 9php:8.2php-8.2.33-1.module_el9.8.0+327+37dfd4b4.alma.1
AlmaLinux 9php:8.3php-8.3.33-1.module_el9.8.0+328+1fdeb728.alma.1
AlmaLinux 8php:7.2 (default stream)php-7.2.24-1.module_el8.10.0+4315+7b734bf3.alma.1
AlmaLinux 8php:7.3php-7.3.20-1.module_el8.10.0+4316+90ea5fe5.alma.1
AlmaLinux 8php:7.4php-7.4.33-8.module_el8.10.0+4321+cf5fd4bb
AlmaLinux 8php:8.0php-8.0.30-1.module_el8.10.0+4319+26f10322.alma.1
AlmaLinux 8php:8.2php-8.2.33-1.module_el8.10.0+4320+c30d6dbb.alma.1

AlmaLinux says php:7.2, php:7.3 and php:8.0 on AlmaLinux 8, and php:8.1 on AlmaLinux 9, are past their life cycle. They got this fix, but future fixes are not guaranteed. AlmaLinux Kitten 10 gets the fix with its next regular PHP update. Advisory IDs are on errata.almalinux.org.

Rocky Linux

Source: Rocky Linux errata, linked per row. Checked 2026-10-22.
ReleasePackage or streamFixed versionAdvisory
Rocky 10php (8.3)8.3.36-1.el10_2RLSA-2026:87070
Rocky 10php8.48.4.27-1.el10_2RLSA-2026:87071
Rocky 9php (8.0, default)8.0.30-8.el9_8.1RLSA-2026:87151
Rocky 9php:8.2 module8.2.35-1.module+el9.8.0+40395+2f706e64RLSA-2026:87072
Rocky 9php:8.3 module8.3.36-1.module+el9.8.0+40396+4e680bb7RLSA-2026:87079
Rocky 8php:7.4 module7.4.33-8.module+el8.10.0+40393+c071e357RLSA-2026:87080
Rocky 8php:8.2 module8.2.35-1.module+el8.10.0+40394+d21b33fbRLSA-2026:87073

Rocky module builds have the same version and release as Red Hat, but a different build suffix. Compare against the Rocky string, not the Red Hat one.

CentOS Stream, Amazon Linux and other rebuilds

Our rules do not cover CentOS Stream, Amazon Linux, Oracle Linux or other rebuilds yet. Check your vendor's security notices, and compare the full package version, not php -v. If your PHP comes from a third-party repository, compare it with the fixed releases.

Install the update

sudo dnf upgrade 'php*'
    # PHP 8.4 on version 10
    sudo dnf upgrade 'php8.4*'

Your stream has no fix, or is past its life cycle? Switch to a supported stream. AlmaLinux gives this example for PHP 8.2 on version 8:

sudo dnf module list php
    sudo dnf module reset php
    sudo dnf module enable php:8.2
    sudo dnf distro-sync 'php*'

Test your app first. A new stream can change PHP behaviour.

Restart PHP

sudo systemctl restart php-fpm
    # Apache with mod_php, or Apache in front of PHP-FPM
    sudo systemctl restart httpd
    # does Apache load mod_php?
    httpd -M 2>/dev/null | grep -E 'mpm_|php'

If you run more than one PHP-FPM service, list them with systemctl list-units '*php*fpm*' and restart each one.

A running PHP process keeps the old code in memory until it stops. Restart Apache, every PHP-FPM pool and any long-running PHP workers, such as queue workers (php2shell.com). In a container, rebuild the image and recreate the container (our advice).

To see that PHP-FPM started after the update (our advice):

rpm -q --last php-fpm
    systemctl show -p ActiveEnterTimestamp php-fpm

php -v does not show the fix

Check your site

The php2shell.fyi checker reads the PHP version your site shows in public. A header is a hint, not proof. A distribution build often reports an old number, so confirm the package version on the server. A result never proves that a site is not exposed.

Sources