PHP2Shell Mitigation If You Can't Patch Yet

Upgrading PHP is the only complete fix for PHP2Shell. The measures below, taken from the official disclosure, can reduce exposure to some attack paths while you prepare the update. None of them covers every variant.

Test each change against your application. Some affect uploads, stability or performance.

1. Consider disabling the finite memory limit

Setting memory_limit = -1 blocks some attack paths that rely on PHP's memory-limit handling. Memory exhaustion is then handled by the operating system, so workers may be killed and requests interrupted. Contain it with Linux cgroup v2 memory.max or an equivalent. Do not use RLIMIT_AS or RLIMIT_DATA as replacement limits. The PHP advisory warns they can trigger the same vulnerable paths.

2. Reduce attacker-controlled memory pressure

post_max_size = 8M            ; as low as your uploads allow
max_input_nesting_level = 32  ; as low as your forms allow
session.upload_progress.enabled = 0

3. Turn off error display

display_errors = 0
fatal_error_backtraces = 0    ; where supported

This closes an extra information-disclosure path and the demonstrated fatal-backtrace mechanism. Other triggers remain.

4. Recycle PHP-FPM workers more often

Lowering pm.max_requests limits how long corrupted state survives across requests. It costs performance and does not stop single-request attacks.

5. Constrain the impact

SELinux or AppArmor policies can limit what a compromised worker can execute. They can reduce the impact of an attack but will not prevent every exploit or memory leak.

6. Use your WAF or CDN rules

Cloudflare, Akamai, Imperva, Fastly, AWS and others prepared detections and temporary rules. Turn them on, but keep in mind the disclosure's warning: a protective rule is not a substitute for updating PHP.

Signs to investigate

Unexpectedly large or malformed PHPSESSID cookies in responses.
Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses.
Unexplained PHP worker crashes or restarts.

These are not proof either way. Some attacks leak memory without running any code, and application logs may show little because the vulnerable paths run below the application.

Which PHP2Shell mitigation fits your setup

Setup	Exposure	Start with
Apache with mod_php	Highest. CVE-2026-109618 can fire before any application code runs, with default settings.	Patch first. Until then: WAF rules, lower `post_max_size`, `session.upload_progress.enabled = 0`, `display_errors = 0`.
Nginx or Apache with PHP-FPM	RCE confirmed through application-level code paths.	The php.ini settings above, plus a lower `pm.max_requests` to recycle workers.
Shared hosting	Depends on the host's PHP build.	Switch to a fixed PHP version in the panel or ask support. Use your CDN's managed rules.
Docker / Kubernetes	Same as the server type inside the image.	Rebuild on a fixed base image. Mitigations only buy time until the rollout.

How to apply PHP2Shell mitigation settings

Find the php.ini that the web server actually loads. Create a temporary phpinfo page or run php --ini. The CLI and FPM often use different files, for example /etc/php/8.3/fpm/php.ini and /etc/php/8.3/apache2/php.ini on Debian and Ubuntu.
Edit the settings, or drop them into a separate file in the conf.d directory so they are easy to remove after patching.
Restart PHP-FPM or Apache. php.ini changes do nothing until the workers restart.
Test uploads, large forms and any page that uses upload progress bars.
Write down what you changed. After the PHP2Shell patch, revert memory_limit = -1 and review the rest.

On shared hosting you may only be able to change some of these values through a "PHP options" or "MultiPHP INI Editor" screen. That is fine. The PHP update is still the part that matters.

PHP2Shell mitigation FAQ

Is there a complete PHP2Shell workaround?

No. The official disclosure says upgrading PHP is the only complete remediation. Every measure on this page covers only some exploitation paths.

Does setting memory_limit = -1 make my server safe?

It blocks some paths that rely on PHP memory-limit handling, but not application-specific large allocations or triggers unrelated to memory. It also lets workers use memory until the operating system kills them, so contain it with cgroup limits.

Does hiding the PHP version with expose_php = 0 help?

It hides the version from headers, which is good hygiene, but it does not fix anything. Attackers do not need to know your version to try the exploit.

Is Cloudflare's free plan enough?

Cloudflare says its PHP2Shell rules are live on all plans, including Free. That helps against known payloads, but a WAF rule is not a substitute for updating PHP. Variants appeared within hours of the leak.

When you are ready, follow the PHP2Shell patch guide and confirm with the PHP2Shell checker.