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

Jonathan Wright

Infrastructure SIG Lead & ALESCo Member

Wed Oct 21, 2026

Update: Patched PHP packages are now in production

2026-10-21 21:15 UTC: The patched PHP packages are now rolling out to the production repositories for every PHP stream on AlmaLinux 8, 9, and 10. You no longer need to enable the testing repo to get them. Just run:

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

If you use mod_php on AlmaLinux 8, restart Apache with sudo systemctl restart httpd instead. Most mirrors sync every few hours, so if the update is not available to you yet, try again a little later. Confirm you are running a patched build with rpm -q php-common (or rpm -q php8.4-common for PHP 8.4 on AlmaLinux 10) against the patched package versions.

If you enabled the testing repo to help us test, you can disable it again:

sudo dnf config-manager --disable almalinux-testing

The testing-repo instructions further down in this post remain for reference but are no longer the recommended path. Thanks to everyone who helped verify these packages. Community testing got them into production faster than we could have managed alone.

Two critical vulnerabilities in PHP, nicknamed php2shell, were disclosed by PHP today: CVE-2026-109618 and CVE-2026-109619. Either one can let an unauthenticated attacker run code on a web server, as the account PHP runs under, by sending it crafted HTTP requests. PHP rates both 9.2 (Critical) on CVSS v4.0. AlmaLinux 8, 9, and 10 all ship affected PHP versions.

Patched packages for every PHP stream AlmaLinux ships are now in the production repositories. If you can’t update right away, the mitigations below reduce your exposure.

More information about the vulnerabilities:

PHP security advisory: https://www.php.net/archive/2026.php#2026-10-21-5
CVE-2026-109618 advisory (remote code execution via out-of-memory corruption): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
CVE-2026-109619 advisory (remote code execution via stale global state): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
PHP’s advance notice on oss-security: https://www.openwall.com/lists/oss-security/2026/10/20/34

Summary

php2shell is the nickname the pair has picked up. PHP’s advisory refers to them by CVE number. PHP shipped the fixes on 2026-10-21 in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The two flaws are separate bugs, but PHP’s advisories each tell readers to follow the other’s advice too, and the patched AlmaLinux packages fix both.

CVE-2026-109618: out-of-memory corruption

When a request runs out of PHP’s per-request memory limit, PHP aborts it by jumping straight out of whatever it was doing. In a few places, PHP has request memory that is only half set up at that moment, and the abort leaves it in a broken state. The cleanup code that runs at the end of the request then reads that broken memory.

An attacker can cause the out-of-memory condition on purpose with a crafted file upload (multipart) request, for example a part with a huge number of headers or many empty file fields, while staying within PHP’s normal upload limits. PHP confirmed full remote code execution over HTTP against Apache’s built-in PHP module (mod_php) with default limits, before any application code runs at all. The upstream fix stops PHP from aborting in the middle of an operation when memory runs out. It now stops the request at the next safe point instead.

CVE-2026-109619: stale state between requests

A PHP worker process handles many requests, one after another. PHP keeps some global state (about errors, sessions, and extensions) that points into the memory of the current request, and that state has to be cleared before the request’s memory is freed. If a request is cut short by a fatal error, including running out of memory, some of it is never cleared. On the next request handled by the same worker, a few things run before PHP’s normal setup, and they can use that stale state after its memory has been freed (a use-after-free).

PHP confirmed two of these early paths:

Warnings raised while applying per-directory or per-request PHP settings, such as .htaccess settings with mod_php, or PHP_VALUE settings that nginx or Apache pass to PHP-FPM. Turning off error display or logging, or using @, does not prevent this.
PHP’s session upload progress feature, which is enabled by default and works even if the application never uses sessions.

PHP validated remote code execution through the session upload progress path against both mod_php and PHP-FPM. The PHP-FPM case depends on the application having a suitable operation that an attacker can make fail.

Impact

AlmaLinux 8, 9, and 10 all ship PHP versions in the affected range. According to PHP’s advisory, every PHP installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, and php-cgi, and PHP considers the risk highest for mod_php.

PHP-FPM (FastCGI Process Manager), the default on every AlmaLinux release. The Apache and nginx configurations that ship with AlmaLinux’s PHP packages both hand PHP requests to PHP-FPM. PHP confirmed remote code execution against PHP-FPM through CVE-2026-109619. For CVE-2026-109618, PHP’s analysis says PHP-FPM is susceptible, but no complete exploit against it has been shown.
Apache mod_php, on AlmaLinux 8 only, and not the default. AlmaLinux 8 still ships mod_php, but it only loads if Apache has been switched to the prefork multi-processing module (MPM). That is the setup where PHP confirmed exploitation of both flaws without relying on the application at all. AlmaLinux 9 and 10 do not ship mod_php.

To check whether an AlmaLinux 8 system is using mod_php, run:

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

If the output includes mpm_prefork_module and php_module or php7_module, that system is running mod_php.

Our packages only update PHP installed from AlmaLinux’s own repositories. If you get PHP from somewhere else, such as a web hosting control panel, a hosting provider, or a third-party repository, check with that vendor for their fixes and timeline.

Patching ahead of our upstream

Security is a top priority at AlmaLinux. Unauthenticated remote code execution in PHP is something that needs to be handled with urgency, and PHP is urging every user to update immediately. At the time of writing, Red Hat has released a fix only for the php:7.4 stream on RHEL 8. Our core team has backported the upstream fixes to every other PHP stream AlmaLinux ships, including streams that are past the end of their RHEL Application Streams life cycle. The decision to ship ahead of a CentOS Stream / RHEL update was made by our technical steering committee, ALESCo.

These packages were first released to the testing repository on 2026-10-21 for community verification, and are now rolling out to the production repositories. The php:7.4 stream on AlmaLinux 8 went directly to production, since its fix is a rebuild of Red Hat’s update.

Retired streams

php:7.2, php:7.3, and php:8.0 on AlmaLinux 8, and php:8.1 on AlmaLinux 9, have reached the end of their RHEL life cycle. Given the severity of these flaws, we have patched them too, but future fixes for retired streams are not guaranteed. If you are on one of them, plan to move to a supported stream.

php:7.2 is still the default stream on AlmaLinux 8, so if you installed PHP there without choosing a stream, that is what you have. Check which stream is enabled (marked [e]) with:

dnf module list php

To move to a supported stream, for example php:8.2, after checking that your applications work with that PHP version:

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

Patched package versions

Install the version listed for your release and stream, or higher.

AlmaLinux 8

php:7.2 stream: php-7.2.24-1.module_el8.10.0+4315+7b734bf3.alma.1
php:7.3 stream: php-7.3.20-1.module_el8.10.0+4316+90ea5fe5.alma.1
php:7.4 stream: php-7.4.33-8.module_el8.10.0+4321+cf5fd4bb (Red Hat’s update, released directly to production)
php:8.0 stream: php-8.0.30-1.module_el8.10.0+4319+26f10322.alma.1
php:8.2 stream: 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
php:8.1 stream: php-8.1.32-1.module_el9.8.0+326+528679fc.alma.1
php:8.2 stream: php-8.2.33-1.module_el9.8.0+327+37dfd4b4.alma.1
php:8.3 stream: 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
PHP 8.4 (php8.4 packages): php8.4-8.4.24-1.el10_2.alma.1

AlmaLinux Kitten 10

The fix will ride along in the next regular PHP update, so no separate build is being made.

Installing from the testing repository (historical, for reference)

These instructions are preserved from when the packages were in testing. The packages are now in production, so the dnf upgrade command at the top of this post is the recommended path.

sudo dnf install -y almalinux-release-testing
sudo dnf upgrade 'php*' --enablerepo=almalinux-testing
sudo systemctl restart php-fpm

If you use mod_php on AlmaLinux 8, restart Apache instead with sudo systemctl restart httpd. If you are on the php:7.4 stream on AlmaLinux 8, you don’t need the testing repository: sudo dnf upgrade 'php*' picks up the fix from production.

Confirm with rpm -q php-common (or rpm -q php8.4-common for PHP 8.4 on AlmaLinux 10) against the versions above. Don’t rely on php -v: our fixes are backported, so the upstream PHP version number doesn’t change.

If you do not want the testing repo enabled afterwards (and on a production box you almost certainly do not), disable it once you have updated:

sudo dnf config-manager --disable almalinux-testing

If you run into anything, please let us know in AlmaLinux chat or on bugs.almalinux.org.

Mitigations until you can update

An update is the only full solution. The measures below come from PHP’s advisory. Each one reduces exposure to specific attack paths. After changing a PHP setting, restart every PHP worker with sudo systemctl restart php-fpm (or sudo systemctl restart httpd if you use mod_php).

For CVE-2026-109619 (stale state between requests)

Turn off session upload progress. Few applications use the feature, and PHP suggests leaving it off even after updating if you don’t need it. Set it in php.ini, a file in /etc/php.d/, or a PHP-FPM pool, not with ini_set() or a .user.ini file, which take effect too late:

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

This blocks the confirmed session paths, but not other variants. Beyond that:

Remove invalid or deprecated PHP settings applied per directory or per request (in .htaccess, or passed from your web server as PHP_VALUE) that produce warnings. Hiding the warnings with error_reporting, display_errors, or @ does not help.
Fix fatal errors and execution timeouts an attacker could trigger, including in callbacks, upload or import processing, and cleanup code.

For CVE-2026-109618 (out-of-memory corruption)

Set memory_limit = -1 in a way applications can’t override, such as php_admin_value[memory_limit] = -1 in your PHP-FPM pool (/etc/php-fpm.d/www.conf by default), and check that no pool, directory, or application setting puts a finite limit back. This removes the attacker-controllable failure, though an underlying allocation failure can still reach the vulnerable code.
Set a low post_max_size: 8M if your applications don’t need file uploads, or 32M if they do, and keep upload_max_filesize below it. Consider also enforcing request size limits at your web server or proxy.
Use a container or cgroup memory limit as a backstop, ideally one that kills only the affected worker, since PHP no longer limits memory per request. Do not use RLIMIT_AS or RLIMIT_DATA instead, as these can trigger the vulnerable path.

If you run mod_php on AlmaLinux 8, PHP considers it the highest-risk setup. Switching back to the default event MPM with PHP-FPM removes the paths PHP confirmed against mod_php that don’t depend on the application.

Install the patched packages as soon as you can.

Thanks

Thanks to the researchers who found and reported these flaws (credited in PHP’s advisories), to Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka, and Nora Dossche for developing the fixes, and to the PHP security team for coordinating the release.

Thanks to the AlmaLinux core team for turning around patched builds for every PHP stream we ship on disclosure day, and to ALESCo for moving quickly to approve shipping ahead of upstream. And thank you to everyone in the community who helped test these packages. That’s the part that got them safely into production.

Stay informed

Remaining aware of these vulnerabilities and acting quickly can keep your systems and data safe. Follow the AlmaLinux Blog, join the Mattermost Community Chat, and subscribe to the Announce and Security mailing lists to stay informed.

Changelog

2026-10-21 21:15 UTC: Patched PHP packages rolling out to the production repositories for every PHP stream on AlmaLinux 8, 9, and 10. Update notice added at the top of the post, and the post title and header image updated.
2026-10-21 17:50 UTC: Patched PHP packages available in almalinux-testing for every PHP stream on AlmaLinux 8, 9, and 10, including retired streams. The php:7.4 fix on AlmaLinux 8, a rebuild of Red Hat’s update, released directly to production. Added package versions and testing instructions, and updated the post title.
2026-10-21 15:11 UTC: Initial post published. Patches in progress, with testing releases expected later today.
2026-10-21 12:59 UTC: PHP published its security advisory along with the fixed releases, PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.