Is there a workaround for CVE-2026-109618 and CVE-2026-109619?
Only partial ones, and none of them is a fix. PHP’s advisory says: “while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.” For CVE-2026-109619, the GitHub advisory adds that there is “no complete generic configuration mitigation”. Use these settings only to buy time until you install the PHP2Shell patch.
What are the official stopgaps?
| Setting | For | What it blocks | Side effects |
|---|---|---|---|
memory_limit=-1 (so applications can’t override it) | CVE-2026-109618 | The controllable PHP memory-limit failure. An underlying allocation failure can still reach the vulnerable code. | PHP processes can use unlimited memory; watch server resources. |
Low post_max_size: 8M if you don’t need uploads, 32M if you do | CVE-2026-109618 | Reduces how much request data can be pushed into PHP | Larger uploads and forms fail. |
session.upload_progress.enabled=0 | CVE-2026-109619 | The confirmed session paths, not other variants | Upload progress features may stop working. |
fatal_error_backtraces=0 (PHP 8.5 only) | CVE-2026-109619 | The confirmed fatal-backtrace path only | Less diagnostic detail in error logs. |
Every one of these settings needs a restart of all PHP workers to take effect. PHP also warns: don’t substitute RLIMIT_AS or RLIMIT_DATA limits, which can trigger the vulnerable allocation failure, and hiding errors with error_reporting, display_errors or @ does not help.
How do I apply the session.upload_progress workaround correctly?
The setting must take effect before PHP parses the request:
- Set
session.upload_progress.enabled=0inphp.ini, the PHP-FPM pool configuration or the web server configuration. - Don’t use
ini_set()in code or an FPM.user.inifile; those apply too late. - Restart every PHP worker (all PHP-FPM pools, or Apache for mod_php). Workers that didn’t restart still run the old settings.
On shared hosting you usually can’t change these settings; ask your host, or install the patch through them.
Is “no upload feature on my site” a workaround?
No. The attack paths are in PHP’s request handling, not in your site’s upload form, so a site without an upload feature isn’t automatically safe. That’s why the official setting is a server-level PHP option, not an application switch.
Does a WAF like Cloudflare count as a workaround?
No. It’s an extra layer, not a fix. Cloudflare deployed WAF rules automatically on all plans with WAF, including Free, about nine hours before disclosure, and reported attackers mutating payloads to get around them. A WAF only filters traffic that passes through it, and your server’s PHP stays vulnerable.
Does a maintenance-mode plugin work as a workaround?
Not reliably. A WordPress maintenance page is itself served by PHP, and some attack paths happen before application code runs. To stop exposure without patching, block requests before they reach PHP or take the site offline, as several national agencies advised for sites that can’t be updated.
How long can I rely on a workaround?
Only until you can update, ideally a matter of days. The fixes and technical write-ups are public, and Sansec expects mass exploitation. Plan the update now. Check where you stand with the PHP2Shell checker, and read CVE-2026-109618 and CVE-2026-109619 for the details of each flaw.
Which sources support this page?
- The PHP Group: security advisory with mitigations
- GitHub advisory GHSA-w8hw-w9fx-j79w
- GitHub advisory GHSA-6wmf-4rv5-p3rp
- Cloudflare: WAF protections
- Sansec: PHP2Shell research
Check your PHP for PHP2Shell
Enter the version your website reports. We compare it with the first fixed release for its branch and tell you what to do next.
PHP2Shell checker →Sources
The core facts on this page (fixed versions, CVE details, vendor packages and agency warnings) come from official sources. Research, news and community posts are labelled as such.
- Security advisory: Critical remote code execution vulnerabilities, update nowOfficial The PHP Group
- RCE via OOM corruptionOfficial The PHP Group
- RCE via stale global stateOfficial The PHP Group
- Cloudflare deploys protections against php2shell vulnerabilityCDN vendor Cloudflare
- PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)Research Sansec