php2shell (CVE-2026-109618, CVE-2026-109619): Patched PHP packages released

Key points

PHP has disclosed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known together as "php2shell". Either one lets an unauthenticated attacker run code on a web server, as the account PHP runs under, by sending crafted HTTP requests. AlmaLinux 8, 9 and 10 all ship affected PHP. Patched builds for every PHP stream reached the testing repository on 21 October and, after community testing, began rolling out to the production repositories at 21:15 UTC the same day, ahead of a RHEL update and with approval from the steering committee ALESCo.

The flaws

• PHP rates both 9.2 (Critical) on CVSS v4.0. Upstream fixed them on 2026-10-21 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The AlmaLinux packages fix both bugs.
• CVE-2026-109618: running out of the per-request memory limit can abort PHP mid-operation and leave memory half set up, which end-of-request cleanup then reads.
• An attacker can trigger CVE-2026-109618 with a crafted multipart upload, even within normal upload limits. PHP achieved full remote code execution against mod_php with default limits, before any application code runs.
• CVE-2026-109619: after a fatal error, including out-of-memory, some global state is left uncleared, and the worker's next request can use freed memory (use-after-free).
• One confirmed path for CVE-2026-109619 is warnings raised while applying per-directory or per-request settings (.htaccess, PHP_VALUE). Disabling error display or logging, or using @, does not stop it.
• The other confirmed path is session upload progress, which is on by default and active even in applications that never use sessions. PHP reached code execution this way on mod_php and on PHP-FPM, where it depends on an application operation the attacker can make fail.

Who is affected

• PHP-FPM, the default on every release, is affected. Code execution is confirmed through CVE-2026-109619. For CVE-2026-109618, PHP-FPM is considered susceptible, but no complete exploit has been shown.
• mod_php exists only on AlmaLinux 8 and loads only when Apache uses the prefork MPM. PHP considers this the highest-risk setup. AlmaLinux 9 and 10 do not ship mod_php.
• An AlmaLinux 8 system uses mod_php if this command shows mpm_prefork_module together with php_module or php7_module:

httpd -M 2>/dev/null | grep -E 'mpm_|php'

• The fixes cover only PHP from AlmaLinux repositories. Users of control panels, hosting providers or third-party repos should ask those vendors for their fixes and timelines.

Patched versions (this release or higher)

• AlmaLinux 8: php:7.2 php-7.2.24-1.module_el8.10.0+4315+7b734bf3.alma.1
• AlmaLinux 8: php:7.3 php-7.3.20-1.module_el8.10.0+4316+90ea5fe5.alma.1
• AlmaLinux 8: php:7.4 php-7.4.33-8.module_el8.10.0+4321+cf5fd4bb, a rebuild of Red Hat's update, released straight to production
• AlmaLinux 8: php:8.0 php-8.0.30-1.module_el8.10.0+4319+26f10322.alma.1
• AlmaLinux 8: php:8.2 php-8.2.33-1.module_el8.10.0+4320+c30d6dbb.alma.1
• AlmaLinux 9: default PHP 8.0 php-8.0.30-8.el9_8.alma.1
• AlmaLinux 9: php:8.1 php-8.1.32-1.module_el9.8.0+326+528679fc.alma.1
• AlmaLinux 9: php:8.2 php-8.2.33-1.module_el9.8.0+327+37dfd4b4.alma.1
• AlmaLinux 9: php:8.3 php-8.3.33-1.module_el9.8.0+328+1fdeb728.alma.1
• AlmaLinux 10: default PHP 8.3 php-8.3.33-1.el10_2.alma.1
• AlmaLinux 10: PHP 8.4 php8.4-8.4.24-1.el10_2.alma.1
• AlmaLinux Kitten 10 gets no separate build. The fix arrives with its next regular PHP update.

How to update

• The patches are now in the production repositories; the testing repo is no longer needed:

sudo dnf clean metadata && sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm

• mod_php users restart Apache with sudo systemctl restart httpd instead.
• Most mirrors sync every few hours; if the update is not there yet, try again later.
• To confirm, compare rpm -q php-common (or rpm -q php8.4-common) with the list above. php -v does not change, because the fixes are backported.
• Anyone who enabled the testing repo to help can turn it off with sudo dnf config-manager --disable almalinux-testing. Problems go to AlmaLinux chat or bugs.almalinux.org.

Retired streams

• php:7.2, 7.3 and 8.0 on AlmaLinux 8 and php:8.1 on AlmaLinux 9 are past RHEL end of life. They were patched this time, but future fixes are not guaranteed.
• php:7.2 remains the default stream on AlmaLinux 8. dnf module list php shows the enabled stream marked [e].
• To move to a supported stream, for example php:8.2, first check that your applications work with it, then run:

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

Mitigations until patched

• Only the update fully fixes the flaws. These measures from PHP's advisory reduce exposure, and PHP workers need a restart after each change.
• Disable session upload progress in php.ini, /etc/php.d/ or the FPM pool, not in ini_set() or .user.ini. PHP suggests keeping it off after updating if you don't need it. This blocks the confirmed session paths only:

echo 'session.upload_progress.enabled = 0' | sudo tee /etc/php.d/99-php2shell.ini
sudo systemctl restart php-fpm

• Remove per-directory or PHP_VALUE settings that produce warnings. Fix fatal errors and timeouts an attacker could trigger.
• Set php_admin_value[memory_limit] = -1 (pool file /etc/php-fpm.d/www.conf by default), make sure nothing restores a finite limit, and use a container or cgroup limit as a backstop. Do not use RLIMIT_AS or RLIMIT_DATA.
• Keep post_max_size low: 8M without uploads, 32M with them. Keep upload_max_filesize below it, and consider request limits at the web server or proxy.
• mod_php users can switch back to the event MPM with PHP-FPM.

Summary by DistroNews, based on the original post.