Mitigations

Can't Patch Yet? Temporary Mitigations for PHP2Shell

Published 21 October 2026 · 6 min read · by PHP2Shell Scanner

Updating PHP is the only complete fix for PHP2Shell. But if you genuinely can't patch this minute, these partial mitigations reduce the attack surface. Treat every one as a stopgap.

1. Block multipart/form-data at the web server

Every known trigger is a multipart/form-data request. Blocking it at the web server (not the app) stops the vector — but breaks file uploads and most checkout/login forms.

# nginx
if ($content_type ~* multipart/form-data) { return 403; }

# Apache 2.4
<If "%{CONTENT_TYPE} =~ /multipart\/form-data/">
  Require all denied
</If>

2. Allow only GET and HEAD

If going fully offline isn't an option, restricting to GET/HEAD keeps your catalog/content browsable while disabling the POST-based attack path (and, unavoidably, logins and forms).

3. php.ini hardening

session.upload_progress.enabled = Off
fatal_error_backtraces = 0        ; PHP 8.5 only

Restart PHP-FPM/Apache afterward. These close named early-consumer paths for CVE-2026-109619 but are not a full fix.

Some writeups suggest memory_limit = -1 to avoid the OOM trigger. This is risky: it lets a single request consume all server memory (a DoS in itself). Only consider it with active memory monitoring.

4. A static maintenance page

Serving a static HTML page (at the web-server level) for the duration is safer than an application “maintenance mode,” because PHP still parses every request that reaches it — so app-level maintenance does not protect you.

What does NOT work

WordPress/Magento maintenance mode or security plugins (run after vulnerable PHP code).
Relying only on a WAF: multipart-parser inconsistencies have historically allowed WAF bypasses, so a determined attacker may slip past.

Best mitigation: just patch

Confirm whether you're still exposed.

Scan my site