v3.2.49.2 & CVE-2026-109618 + CVE-2026-109619

CVE-2026-109618 is a RCE via OOM corruption. PoC exploits exist for mod_php. Mitigation techniques involve setting post_max_size above upload_max_filesize. This is a default setting in the platform.

It is feasible to achieve root when mod_php is used; with PHP-FPM, the threat is limited to the pool owner reported under Web > PHP Pools. Unless modified, this user is an unprivileged system user “apache” local to the account.

Source analysis suggests PHP-FPM is vulnerable, although no such exploit exists yet.

Verifying mod_php presence
Use the Scope: cpcmd scope:get php.fpm. If the value is 1, PHP-FPM is used instead of mod_php. Alternatively, query Apache directly: httpd -t -DDUMP_MODULES 2>&1 | grep php. php_module (or a variation of phpX_module) will report present if embedded in Apache. Setting cpcmd scope:set php.fpm 1 will disable it.

CVE-2026-109619 is a RCE via global state corruption. Session upload progress is the most accessible vector to leverage this exploit. Invalid .htaccess values before startup trigger this vulnerability as well.

A similar risk assessment is present in mod_php: root can be gained. For PHP-FPM, because mod_proxy_fcgi is required, and ProxyFCGISetEnvIf cannot be selectively disallowed in .htaccess context, it too carries the same risk assessment. An attacker would require local file access to inject a corrupted PHP_VALUE, e.g. ProxyFCGISetEnvIf "true" PHP_VALUE "auto_detect_line_endings=1".

As with most exploits, some chaining is required for ini corruption.


v3.2.49.2 will be re-released later today once all odds and ends are tightened up. If you’re using PHP-FPM, don’t panic. If mod_php, I would switch over to PHP-FPM ASAP.