Mitigating CVE-2026-109618 and CVE-2026-109619 (PHP2Shell) on Rocky Linux 8, 9, 10, and LTS Variants

cve cve-2026-109618 cve-2026-109619 security php rocky linux lts mitigation remote code execution

Arsalan Zaidi
Customer Support Engineer

Oct 21, 2026

Introduction

CVE-2026-109618 and CVE-2026-109619 are two critical remote code execution (RCE) vulnerabilities in PHP core, disclosed on 2026-10-21. Both are rated CVSS v4.0 9.2. The vulnerabilities allow an unauthenticated remote attacker to execute arbitrary code on any web server running PHP. Multiple public exploits exist, and large-scale exploitation is considered likely.

CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) is a remote code execution via an out-of-memory (OOM) condition during RFC 1867 input parsing. RFC 1867 governs multipart form data and file upload handling. An attacker can trigger an OOM condition in PHP's input parser, causing memory corruption that leads to arbitrary code execution.
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) is a remote code execution via global state corruption after a fatal error. When PHP encounters a fatal error under certain conditions, internal global state is not properly cleaned up, allowing an attacker to exploit the corrupted state for code execution.

Both vulnerabilities can be triggered with a simple HTTP POST request to any PHP endpoint that processes input. No authentication, special configuration, or file upload functionality is required.

These CVEs affect all PHP installations from version 5 onward. Official patches have been released for supported PHP branches (8.2, 8.3, 8.4, and 8.5). The PHP project has also released dedicated fix branches for end-of-life versions 7.4, 8.0, and 8.1 as minimal mitigations. PHP versions 5.x, 6.x, and 7.0 through 7.3 will not receive any fix.

Problem

Rocky Linux ships PHP as a core AppStream package. The PHP versions shipped across Rocky Linux releases are all within the affected range:

Rocky Linux Version	PHP Version Shipped	Upstream Fix Status
Rocky Linux 10 (el10)	PHP 8.3.x	Fix available (PHP 8.3.36)
Rocky Linux 9 (el9)	PHP 8.0.30	EOL fix branch available (PHP-8.0-CVE-2026-109618-109619)
Rocky Linux 8 (el8)	PHP 7.2, 7.4, 8.0 (module streams)	EOL fix branch for 7.4 and 8.0; no fix for 7.2

Rocky Linux 10 ships PHP 8.3, which is in a supported upstream branch. The fix lands in PHP 8.3.36.

Rocky Linux 9 ships PHP 8.0.30, and Rocky Linux 8 ships PHP 7.2, 7.4, and 8.0 as module streams. All of these are end-of-life upstream. The PHP project has released dedicated fix branches for 7.4, 8.0, and 8.1 containing minimal mitigations, but these are source-only releases without official binaries. Distribution maintainers must build packages from these branches. PHP 7.2 and 7.3 (available as el8 module streams) have no fix branch and are unmitigated at the source level.

Both vulnerabilities can be triggered by a simple POST request to any PHP endpoint. The attack is remote, unauthenticated, and requires no special configuration on the target server. Any system running PHP to serve web traffic (via php-fpm, mod_php, or php-cgi) is directly exposed. This makes the risk profile significantly different from local privilege escalation CVEs: internet-facing PHP servers are exploitable from the network with no local access required.

Treat the following as affected until running a patched PHP version:

RLC Pro 10 and CIQ SIG/Cloud Next 10
RLC Pro 9 and CIQ SIG/Cloud Next 9
RLC Pro LTS 9.2 and 9.6
RLC Pro FIPS variants
RLC Pro Hardened variants
RLC Pro 8 and CIQ SIG/Cloud Next 8
RLC Pro LTS 8.6, 8.8, and 8.10
CIQ Bridge / CentOS 7.9 (if running PHP)

Rocky Linux community releases are also affected. CIQ does not publish patched packages for community Rocky Linux editions. For community release patching status, refer to Rocky Linux Errata.

Status

Patched PHP packages are not yet available for CIQ variants. CIQ engineering is tracking the upstream fixes and the EOL fix branches. Patched PHP packages will be released for all supported variants. This section will be updated as packages become available.
Recommended immediate action: Apply the interim mitigations described below to reduce exposure while waiting for patched packages. Internet-facing PHP servers should be treated as highest priority.
PHP has released EOL fix branches for versions 7.4, 8.0, and 8.1 at github.com/php/php-src. These contain minimal mitigations and are available for distribution maintainers to build from.
Open a support case if you need help assessing PHP exposure across your fleet or tracking patched package availability for a specific CIQ variant.

Patched Packages

No patched PHP packages are available for CIQ variants as of 2026-10-21.

Variant	Patched PHP Version	Repo	Released
RLC Pro 10	Pending	Pending	Pending
RLC Pro LTS 9.6	Pending	Pending	Pending
RLC Pro LTS 9.2	Pending	Pending	Pending
RLC Pro 9	Pending	Pending	Pending
RLC Pro 8	Pending	Pending	Pending
RLC Pro LTS 8.6	Pending	Pending	Pending
CIQ Bridge	Pending	Pending	Pending

CIQ updates this table as tested packages become available for each variant.

Confirm the installed PHP version on a given system with:

php -v
rpm -q php

Interim Mitigation

Unlike kernel vulnerabilities where no interim measure may exist, PHP's position in the application stack provides several options to reduce exposure before patched packages are available. Apply one or more of the following based on your environment.

⚠️ The PHP security team warns that updating to a patched release is the only reliable mitigation. There is no complete generic configuration workaround, because an application, extension, or server path may publish stale state or consume it without a predictable log entry. The measures below reduce exposure but do not eliminate the vulnerability.

Configuration measures published by PHP

Apply these through php.ini, an FPM pool, or server configuration that takes effect before request parsing, then restart every worker. Do not rely on ini_set() or an FPM .user.ini, because those are applied too late.

For CVE-2026-109618:

memory_limit = -1
post_max_size = 8M

Set memory_limit with php_admin_value so applications cannot override it, and confirm no pool, directory, or application setting puts a finite limit back. Use post_max_size = 32M where applications need file uploads, and keep upload_max_filesize below it. Setting memory_limit = -1 removes the predictable per-request limit but is not a complete fix: mmap() or other underlying allocation failures can still trigger the vulnerable longjmp() path even with no PHP memory limit.

⚠️ Do not use RLIMIT_AS or RLIMIT_DATA to bound memory. The PHP security team warns that both can cause the allocation failure that reaches the vulnerable code path. Use a container or cgroup limit instead, and if using cgroups, give each worker its own group.

For CVE-2026-109619:

session.upload_progress.enabled = 0
fatal_error_backtraces = 0

session.upload_progress.enabled = 0 blocks the confirmed session paths but not other variants. fatal_error_backtraces = 0 applies to PHP 8.5 and blocks only the confirmed fatal-error path.

CVE-2026-109619 exploits stale global state that survives from one request to the next on the same worker. If performance allows, setting pm.max_requests = 1 in the PHP-FPM pool configuration forces each worker to exit after a single request, preventing the producer/consumer sequence across requests. This has a significant performance cost and is not practical for high-traffic applications.

Disable PHP on systems that do not need it

Systems where PHP is installed but not actively used should have it stopped and disabled:

sudo systemctl stop php-fpm
sudo systemctl disable php-fpm

For Apache with mod_php, disable the PHP module:

sudo sed -i -E 's/^([[:space:]]*)(LoadModule php)/\1# \2/' /etc/httpd/conf.modules.d/*php*.conf
sudo systemctl restart httpd

Block multipart POST requests at the reverse proxy

CVE-2026-109618 targets PHP's RFC 1867 multipart form parser. If your application does not require file uploads or multipart form submissions, blocking Content-Type: multipart/form-data requests at the reverse proxy layer removes the primary trigger for this CVE:

# nginx example: block multipart POST requests to PHP endpoints
if ($content_type ~* "multipart/form-data") {
    return 403;
}

Check the configuration and reload nginx so running workers pick up the change:

sudo nginx -t && sudo systemctl reload nginx

This is a targeted measure for CVE-2026-109618 specifically and does not mitigate CVE-2026-109619. It also breaks any legitimate file upload or multipart form functionality. Only apply this if your PHP application does not use file uploads.

⚠️ Do not narrow this rule to POST. PHP 8.4 added request_parse_body(), which parses multipart bodies on other methods, so a POST-only rule can be stepped around.

Verify mitigation

Confirm PHP-FPM is not running on systems where it was disabled:

systemctl is-active php-fpm

Confirm the interim settings are present in the configuration that the web runtime reads, not just on the CLI:

grep -rE "memory_limit|post_max_size|upload_progress|fatal_error_backtraces" /etc/php.ini /etc/php.d/ /etc/php-fpm.d/

Installing the Update

Once patched PHP packages are available for your variant, install the update and restart PHP services:

sudo dnf update php*
sudo systemctl restart php-fpm

If running Apache with mod_php instead of php-fpm:

sudo dnf update php*
sudo systemctl restart httpd

For CIQ Bridge (CentOS 7) systems, use yum instead of dnf:

sudo yum update php*
sudo systemctl restart php-fpm

A full system reboot is not required for PHP package updates, but all PHP processes must be restarted. Any long-running PHP CLI processes should also be restarted.

If the update does not appear, confirm that the appropriate depot channel is enabled for your product:

sudo depot enable lts-9.6      # RLC Pro LTS 9.6
sudo depot enable rlc-pro-9    # RLC Pro 9
sudo depot enable rlc-pro-10   # RLC Pro 10

Verification

After installing the patched PHP package and restarting services, confirm the running PHP version:

php -v
rpm -q php

The output should show a version equal to or newer than the patched version listed in the Patched Packages table for your variant.

Reverting the Mitigation

If you applied any interim mitigation, revert those changes after installing the patched PHP packages.

To re-enable php-fpm:

sudo systemctl enable php-fpm
sudo systemctl start php-fpm

To restore the interim php.ini settings, remove the memory_limit, post_max_size, session.upload_progress.enabled, and fatal_error_backtraces overrides added above, then restart every worker.

To restore the Apache PHP module (if disabled):

sudo sed -i -E 's/^([[:space:]]*)# (LoadModule php)/\1\2/' /etc/httpd/conf.modules.d/*php*.conf
sudo systemctl restart httpd

To remove the multipart POST block (if applied in nginx):

Remove the if ($content_type ~* "multipart/form-data") block from your nginx configuration and reload:

sudo nginx -t && sudo systemctl reload nginx

Notes

Remote code execution, not local privilege escalation. Unlike the kernel CVEs documented in prior CIQ security advisories, these PHP vulnerabilities are remotely exploitable via a simple POST request. Any internet-facing PHP installation is directly at risk without requiring local access. Prioritize internet-facing systems above internal-only PHP installations.
Exposure varies by SAPI. The PHP server API (SAPI) determines how PHP runs and affects the exploitability of both CVEs. Apache mod_php is the most exposed: both CVEs have confirmed, validated RCE against mod_php with default configurations. php-fpm is conditionally exposed: CVE-2026-109618 has no complete FPM exploit demonstrated, and CVE-2026-109619 depends on a suitable application operation. FPM exits the child when startup fails, which limits one attack path. FrankenPHP and LSAPI are modeled as likely susceptible but have not been fully validated. All SAPIs should be patched regardless, but mod_php deployments are at the highest immediate risk.
PHP 8.0 and earlier are EOL upstream. Rocky Linux 8 ships PHP 7.2/7.4/8.0 and Rocky Linux 9 ships PHP 8.0, none of which are in supported upstream branches. The PHP project has released dedicated fix branches for 7.4, 8.0, and 8.1 with minimal mitigations. CIQ will build patched packages from these branches for supported variants. Systems running PHP 7.2 or 7.3 have no upstream fix available at any level and should migrate to a supported PHP version.
No reboot required. Unlike kernel patches, PHP package updates take effect after restarting PHP services (php-fpm, httpd). A full system reboot is not necessary.
PHP CLI usage is also affected. Systems that use PHP only as a CLI tool (cron jobs, batch processing) and not for web serving are affected by the vulnerability but are not remotely exploitable unless an attacker has local access or can control input to the CLI process. These systems are lower priority than internet-facing PHP servers but should still be patched.
Public exploit tooling exists. An exploit tool called PHP2Shell has been published. The NCSC (Netherlands) considers large-scale exploitation likely in the short term. Treat internet-facing PHP systems as actively at risk.
Third-party software bundles PHP. Many applications and appliances bundle their own PHP runtime. These will need vendor-specific updates. The NCSC (Netherlands) maintains an inventory of PHP-dependent software at github.com/NCSC-NL/php2shell.
CIQ Bridge / CentOS 7.9: Bridge systems with PHP installed are also affected. CIQ will release a patched PHP package for Bridge. In the interim, apply the mitigations above or isolate PHP services from the network.