PHP2Shell mitigations when you cannot patch yet

Start with the network, not php.ini

The most effective stop-gap is not a PHP setting. It is making the server unreachable to the people who would attack it. CERT.LV's guidance is explicit: systems that cannot be updated to a safe PHP version must have their access from the internet restricted, and should not be publicly reachable until the risk is removed. Latvia applied that principle to its own state services: on 21 October access to affected systems was limited to Latvian IP addresses while patches were rolled out, and the shared state and municipal website platform was switched off for an evening until it had been updated.

• Put administrative and internal PHP applications behind a VPN or an IP allow-list.
• Put public sites that cannot be closed behind a WAF or CDN that has published PHP2Shell rules, and make sure the origin accepts traffic only from that service. A rule in front does nothing if the origin's own IP address answers requests.
• Where a site is not business-critical, take it offline until it is patched. A maintenance page costs less than a rebuilt server.

How to apply PHP settings so they actually work

Several of the attack paths run while PHP is still parsing the request, before your application starts. A setting applied too late is no setting at all. The PHP advisory is specific about where the session setting must go: in php.ini, an FPM pool, or server configuration that applies before request parsing. Settings an application applies with ini_set(), and PHP-FPM .user.ini files, take effect too late.

• For PHP-FPM, set values in the pool file with php_admin_value or php_admin_flag, which applications cannot override.
• For Apache mod_php, use php_admin_value or php_admin_flag in the server or virtual host configuration.
• Restart every worker afterwards. A running FPM child or Apache process keeps its old configuration.
• Check the effective value with a phpinfo() page served through the web server, then delete the page.

; PHP-FPM pool, e.g. /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M

# Apache with mod_php, server or virtual host configuration
php_admin_flag session.upload_progress.enabled off
php_admin_value post_max_size 8M

Against CVE-2026-109619: stale global state

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

This flaw needs PHP to run out of memory at the wrong moment. The measures either remove PHP's own memory-limit failure, or make it harder for one request to consume that much memory.

What these measures leave open

The PHP advisory for CVE-2026-109619 says there is no configuration-based mitigation that covers every operation, because an application, extension or server path can leave stale state behind or use it without a predictable log entry. The fixes in the released versions address the underlying failure pattern; the settings above address the paths that have been demonstrated. Treat a mitigated server as still vulnerable, with fewer known ways in.

After you patch

Do not simply revert everything. The PHP advisory for CVE-2026-109618 still recommends a conservative post_max_size, limits on decoded request size at the front end, and bounds on input variables, multipart parts and nesting depth, because they reduce the risk of the new hard memory limit being hit and of denial of service. Revisit any temporary memory_limit=-1 once the fixed release is running: the fix introduces a hard memory limit above the normal one that kills a worker outright, without shutdown functions or destructors.