php2shell (CVE-2026-109618, CVE-2026-109619): Patches in progress

Jonathan Wright

Infrastructure SIG Lead & ALESCo Member

Wed Oct 21, 2026

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.

We are aware of these vulnerabilities, and our core team is actively backporting the fixes and building patched packages. We expect to release them to the testing repository later today, and we will update this post with package versions and testing instructions as soon as they are available. Until then, 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 will 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 not published fixed PHP packages. Our core team is backporting the upstream fixes first to every PHP stream that is still supported under the RHEL Application Streams life cycle:

AlmaLinux 8: the php:7.4 and php:8.2 streams
AlmaLinux 9: the default PHP 8.0, and the php:8.2 and php:8.3 streams
AlmaLinux 10: the default PHP 8.3, and PHP 8.4 (php8.4 packages)
AlmaLinux Kitten 10: the fix will ride along in the next regular PHP update, so no separate build is being made

We will ship these ahead of a CentOS Stream / RHEL update. That decision was made by our technical steering committee, ALESCo.

We expect the patched packages to be in the testing repository later today. After the community has helped verify them, we will release them to the production repositories. This post will be updated at each step.

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, so they are not part of this first round of patches. We may also backport the fixes to these streams later, and will update this post if we do. Don’t wait on that. If you are on one of them, the safest path is 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*'

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 they are available.

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, who are building patched packages for every supported stream right now, and to ALESCo for moving quickly to approve shipping ahead of upstream. And thank you in advance to everyone in the community who will help us test them. That’s the part that gets 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. We will update this post when the patched packages are available in the testing repository.

Changelog

2026-10-21 14:36 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.