If some of your PHP servers can’t take the PHP2Shell update today, the layers in front of PHP can close the confirmed attack paths while you wait. The usual reasons are a vendor appliance, a frozen release window or an application pinned to an old branch nobody patched. None of these mitigations replaces the patch. PHP’s own advisory says only an update is a complete fix for CVE-2026-109618 and CVE-2026-109619, and every mitigation below leaves something open, so each section says what it stops, what it costs and what it misses.
Every config change shown here was tested on the layer where it runs, from the PHP-FPM pool and Apache with mod_php to nginx and the host firewall. Everything here was built in October 2026 on Ubuntu 26.04, 24.04 and 22.04 and Rocky Linux 9 lab VMs, so the status codes, ini values and log lines below are the ones those servers returned. Three of the settings fail silently when written the obvious way, and we show all three failures.
What Each PHP2Shell Mitigation Stops
The two CVEs reach PHP through different doors, so no single control covers both of them. CVE-2026-109618 needs PHP to run out of memory while it parses a request body, and multipart uploads are the confirmed trigger. CVE-2026-109619 needs state left behind by one request, and the confirmed producers are session upload progress and, on PHP 8.5, fatal error backtraces. This is how the mitigations line up against them:
| Layer | Mitigation | What it stops | What it costs |
|---|---|---|---|
| PHP config or pool | session.upload_progress.enabled = 0 | The confirmed 109619 session path | Upload progress bars, which few applications use |
| PHP config or pool (8.5 only) | fatal_error_backtraces = 0 | The confirmed 109619 backtrace path | Backtraces in fatal error messages |
| PHP pool | Keep post_max_size low | Shrinks the 109618 memory budget for requests that declare their length | Large uploads fail |
| Web server | Body size limit and a multipart/form-data block | The confirmed 109618 trigger, including bodies sent without a length | The block breaks every file upload on the site |
| Cloudflare | Managed WAF rules | Request patterns the rules know | Nothing, if traffic actually goes through Cloudflare |
| Host firewall | Origin accepts only Cloudflare | Attackers who skip the WAF by hitting the server’s IP | DNS-only hostnames on the server stop loading |
In practice this means there are three controls almost every site can run today (upload progress off, backtraces off on 8.5, and the origin lockdown behind a WAF) and one that only suits sites with no uploads at all. The rest of this guide sets each one up and proves it took effect from the web, not from the shell.
Upload Progress Off Before Request Parsing
Turning off session upload progress is the cheapest mitigation, and the one most often applied to the wrong file. PHP’s advisory asks for it in php.ini, an FPM pool or server configuration, followed by a restart of every worker. ini_set() can’t help here at all, because session.upload_progress.enabled and post_max_size are INI_PERDIR settings that a running script cannot change. These are the places that work:
- Ubuntu and Debian, PHP-FPM: a drop-in under
/etc/php/<version>/fpm/conf.d/, which only the FPM service reads. - Ubuntu and Debian, Apache mod_php: a drop-in under
/etc/php/<version>/apache2/conf.d/, a separate tree that FPM never sees. - RHEL family:
/etc/php.d/99-php2shell.ini, read by the CLI, PHP-FPM and mod_php alike. - Locked settings:
php_admin_valuein the FPM pool, orphp_admin_flagin the Apache configuration, which no.user.inior.htaccesscan override.
The Ubuntu split is the trap, and it is worse than a CLI-versus-FPM mismatch. On our Ubuntu 24.04 VM, php -v reported 8.4.27 from the ondrej PPA while nginx passed every request to the 8.3 pool. A path built from the CLI version would have put the drop-in into a tree no website reads. We write the file into every FPM and mod_php tree that exists instead. The second line only matters on PHP 8.5, and older branches ignore it, as our PHP 8.1 test confirmed:
for d in /etc/php/*/fpm/conf.d /etc/php/*/apache2/conf.d; do [ -d "$d" ] && printf 'session.upload_progress.enabled = Off\nfatal_error_backtraces = Off\n' | sudo tee "$d/99-php2shell.ini" >/dev/null && echo "wrote $d/99-php2shell.ini"; doneOn the Ubuntu 22.04 VM, which runs PHP-FPM behind nginx and mod_php behind Apache side by side, the loop found both trees:
wrote /etc/php/8.1/fpm/conf.d/99-php2shell.ini
wrote /etc/php/8.1/apache2/conf.d/99-php2shell.iniReload every running FPM service, then restart Apache. A mod_php setting lives inside the Apache processes, so they have to be replaced too, and try-restart only acts when Apache is running, which makes the line safe on an nginx-only box (sudo apache2ctl -M | grep -i php tells you whether mod_php is loaded at all):
for u in $(systemctl list-units --no-legend --state=running 'php*-fpm.service' | awk '{print $1}'); do sudo systemctl reload "$u"; done
sudo systemctl try-restart apache2Check the value through the web server, because the CLI reads its own tree and will keep reporting the old value. A one-line probe in the document root is enough, and you should delete it once you have read it:
echo '<?php var_dump(ini_get("session.upload_progress.enabled"));' | sudo tee /var/www/html/p2s-check.php >/dev/null
curl -s http://127.0.0.1/p2s-check.phpAn empty string means Off. We got it from nginx with PHP-FPM on port 80 and from Apache with mod_php on port 8080, while the CLI on the same box still said 1:
string(0) ""On Ubuntu 26.04, php-fpm8.5 -i showed both fatal_error_backtraces => Off => Off and session.upload_progress.enabled => Off => Off after the reload. On Ubuntu 24.04 a 1 MB test upload still went through with err=0, so ordinary uploads keep working. If you would rather keep the Apache side in Apache’s own config, php_admin_flag session.upload_progress.enabled off in a file under /etc/apache2/conf-available/, enabled with a2enconf, gave the same result on the 22.04 VM after a restart.
The RHEL family needs only one file, because the CLI, PHP-FPM and mod_php all read /etc/php.d/. On PHP 8.5, add the fatal_error_backtraces = Off line to the same file:
echo 'session.upload_progress.enabled = Off' | sudo tee /etc/php.d/99-php2shell.ini
sudo php-fpm -t
sudo systemctl reload php-fpmOn the Rocky Linux 9 VM that single drop-in changed the CLI and the pool at once, and a 1 MB upload through nginx still returned err=0. Restart httpd as well if it loads mod_php. Remi’s parallel SCL builds keep a separate tree, so a server running php81-php-fpm next to the base PHP needs the same file in /etc/opt/remi/php81/php.d/ and a reload of php81-php-fpm. We tested that on the same VM, where the SCL’s own php-fpm -i then reported session.upload_progress.enabled => Off => Off.
Locked Values in the FPM Pool
On shared or multi-tenant servers we’d reach for the pool instead of a drop-in, and our lab showed why. A drop-in sets a default that any site can override with a .user.ini in its document root, while php_admin_value cannot be overridden at all. The pool also carries the request-size limits from the next section, and those must only ever go down, so read the current values before you write anything:
sudo php-fpm -i | grep -E '^(post_max_size|upload_max_filesize) 'Both of our stock VMs, Rocky Linux 9 and Ubuntu 24.04, reported the php.ini-production defaults, and on the Ubuntu box a 3 MB upload was refused with err=1 before we changed anything:
post_max_size => 8M => 8M
upload_max_filesize => 2M => 2Mphp-fpm -i reads only php.ini and its drop-ins, though, so it misses limits set inside a pool. Check the pool files as well, /etc/php-fpm.d/*.conf on the RHEL family:
grep -E 'post_max_size|upload_max_filesize' /etc/php-fpm.d/*.confOn our Rocky Linux 9 VM, which an earlier test had left with upload values in the pool, the pool file disagreed with the 8M that php-fpm -i had just printed, and the pool is what the website gets:
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 16MOn Ubuntu and Debian, run php-fpm8.3 -i for the branch your nginx socket names and grep /etc/php/*/fpm/pool.d/*.conf, which found nothing on our 24.04 VM. The probe page further down reads the served value directly and settles any doubt. Pasting a 32M limit onto a stock server would raise the body size an attacker can send by four times. So the block below locks the stock values in place, which is also the advisory’s figure for sites with no uploads. Only where your current limit is already higher and the site needs uploads should you write post_max_size = 32M and upload_max_filesize = 16M instead. Open the pool that actually serves the site, which on the RHEL family is /etc/php-fpm.d/www.conf:
sudo vim /etc/php-fpm.d/www.confAdd these three lines at the end. On a PHP 8.5 pool, add php_admin_value[fatal_error_backtraces] = 0 as a fourth line, which our Ubuntu 26.04 pool then reported as "0" from the web; older branches have no such setting:
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 2MTest the configuration and reload, which replaces every worker:
sudo php-fpm -t
sudo systemctl reload php-fpmOn Ubuntu and Debian the pool file is /etc/php/8.3/fpm/pool.d/www.conf for PHP 8.3, the test is sudo php-fpm8.3 -t and the service is php8.3-fpm. Take the version from the socket in your nginx fastcgi_pass line, not from php -v. On our 24.04 VM the same lines in the 8.3 pool, written with the 32M upload values, came back from the web as upload_progress='0' and post_max_size=32M.
A probe page that prints both values is the quickest way to read what the pool really serves. This is the one we used on Rocky Linux 9, where the nginx document root is /usr/share/nginx/html and SELinux needs the file relabelled:
echo '<?php header("Content-Type: text/plain"); echo "upload_progress=", var_export(ini_get("session.upload_progress.enabled"), true), "\npost_max_size=", ini_get("post_max_size"), "\n";' | sudo tee /usr/share/nginx/html/p2s-probe.php >/dev/null
sudo restorecon /usr/share/nginx/html/p2s-probe.php
curl -s http://127.0.0.1/p2s-probe.phpWith the three lines above in the pool, it printed the locked values:
upload_progress='0'
post_max_size=8MTo test the lock, we set the pool to the 32M upload values, then did what a tenant or a plugin installer might do and dropped a .user.ini into the document root that tries to turn both values back up:
printf 'session.upload_progress.enabled = 1\npost_max_size = 1G\n' | sudo tee /usr/share/nginx/html/.user.iniThe probe, read through nginx after a reload, showed the pool values winning:
upload_progress='0'
post_max_size=32MThen we moved the same setting out of the pool and into an /etc/php.d/ drop-in, left the .user.ini in place and asked again. This time the tenant won, and upload progress came back on with a 1G body limit:
upload_progress='1'
post_max_size=1GThat is the silent failure on shared hosting: the drop-in looks right in every config file, and a single file in one customer’s web root undoes it for that site. PHP caches .user.ini for user_ini.cache_ttl seconds (300 by default), so a change made that way can take five minutes to appear, which makes it easy to miss during a quick check. Delete the test .user.ini and the probe page when you are done.
Request Size Limits
CVE-2026-109618 needs PHP to hit its memory limit while it parses a request, so the smaller the body PHP accepts, the harder an attacker has to work. PHP’s advisory gives concrete values that map onto the pool lines above, and it adds a warning that changes where the real limit belongs. The 109618 advisory notes that a multipart request without a usable declared length may pass PHP’s first post_max_size check, so the web server has to enforce a limit too:
post_max_size = 8M: the stock value, and the right one for sites that accept no uploads at all.post_max_size = 32M: only for sites that need uploads and already run a higher limit, withupload_max_filesizeset below it.- PHP’s own counters:
max_input_vars(1000),max_input_nesting_level(64) andmax_multipart_body_parts(-1, which PHP derives frommax_input_varsplusmax_file_uploads) cap fields, nesting and parts. All three areINI_PERDIR, sophp_admin_valuein the pool can lock them. - nginx:
client_max_body_sizecaps the body nginx reads before it passes anything to PHP, so set it no higher thanpost_max_size. - Apache:
LimitRequestBodycaps the body in bytes andLimitRequestFieldscaps the header count, which defaults to 100.
Neither web server can count multipart parts or input nesting depth natively, and the advisory lists both. PHP’s counters apply only once PHP is already parsing the body, so if you want such requests stopped earlier, that is a job for a WAF rule or a load balancer that inspects bodies, which is one more reason the Cloudflare section below matters.
The advisory also suggests memory_limit = -1 set through php_admin_value, so the predictable per-request limit disappears. We did not apply it in production and would not on a shared host, because one runaway request can then take the whole server’s memory, and PHP itself notes that an underlying allocation failure can still reach the vulnerable code. If you want a ceiling, use a container or cgroup limit, and know what systemd does with it. Every FPM worker runs in the service’s one cgroup (/system.slice/php-fpm.service on our Rocky VM), so MemoryMax= on the unit caps the whole pool rather than each worker, and the default OOMPolicy=stop stops the entire service when the kernel kills a single worker. Setting OOMPolicy=continue in a drop-in for the unit should keep the master running so it replaces the worker, although we did not trigger a real OOM kill to confirm that. Never use RLIMIT_AS or RLIMIT_DATA, because PHP’s advisory warns those can cause the very allocation failure the attack needs.
pm.max_requests = 1 is the last pool option, and it costs the most. It forces each worker to exit after one request, so state from one request can never reach the next, which breaks the 109619 producer and consumer pattern. The price is a fork per request, so we’d keep it for low-traffic admin pools rather than a public site.
A Multipart Block at nginx
If a site never accepts file uploads, refusing multipart/form-data at nginx removes the confirmed 109618 trigger before PHP ever sees the request. We match on the content type rather than the method, and that is our own reasoning rather than the advisory’s. PHP 8.4 added request_parse_body(), which parses multipart bodies on PUT and other methods, so a POST-only rule could be walked around on an application that calls it. Open the site’s server block, which lives in /etc/nginx/sites-available/ on Ubuntu and Debian. On the RHEL family it is the server block in /etc/nginx/nginx.conf or a file under /etc/nginx/conf.d/:
sudo vim /etc/nginx/sites-available/defaultPlace this above the PHP location, so it runs before any request is passed on:
if ($content_type ~* "multipart/form-data") {
return 403;
}Test and reload nginx, then wait a moment before you check it:
sudo nginx -t
sudo systemctl reload nginxThe pause matters, because our first test ran immediately after the reload and every request still came back 200 while the old workers were answering. After a two-second wait the same four requests showed the rule doing exactly what it should, blocking both multipart forms and passing everything else:
| Request | Status |
|---|---|
curl -F [email protected] (multipart POST) | 403 |
| multipart PUT | 403 |
curl -d a=1 (urlencoded POST) | 200 |
| plain GET | 200 |
Login forms and most APIs post urlencoded or JSON bodies, so they keep working. Media libraries, contact forms with attachments and plugin uploaders all break, which is why this rule suits brochure sites and APIs rather than a CMS.
The Same Block in Apache
Apache can do the same with an <If> block, and the obvious way to write it fails silently. In Apache’s expression language, %{CONTENT_TYPE} is the content type of the response, not the request. We wrote the rule with it first, apache2ctl -t said “Syntax OK”, and every multipart upload still returned 200. The request header has to be read with %{HTTP:Content-Type}:
sudo vim /etc/apache2/conf-available/php2shell-block-multipart.confThe working rule is three lines:
<If "%{HTTP:Content-Type} =~ m#^multipart/form-data#i">
Require all denied
</If>Enable it, test the syntax and reload. On the RHEL family, put the same three lines in /etc/httpd/conf.d/php2shell-block-multipart.conf instead and reload httpd:
sudo a2enconf php2shell-block-multipart
sudo apache2ctl -t
sudo systemctl reload apache2With the header variable, our Ubuntu 22.04 Apache returned 403 for both the multipart POST and the multipart PUT, kept 200 for urlencoded and GET requests, and logged each refusal as an authorization denial you can alert on:
[authz_core:error] [pid 47242] [client 127.0.0.1:54772] AH01630: client denied by server configuration: /var/www/html/p2s.phpEach blocked upload produces one of those lines, so a sudden burst of them is worth an alert while the rule is in place.
Cloudflare in Front, and the Bypass Behind It
Cloudflare shipped an emergency WAF release on 21 October 2026 that added seven block rules, labelled Generic Rules - Anomalous Execution, to both the Free Managed Ruleset and the Cloudflare Managed Ruleset. The release notes name the rules without referencing any CVE, so treat them as generic hardening rather than confirmed PHP2Shell signatures. Free zones run the Free Managed Ruleset by default, while the Cloudflare Managed Ruleset covers Pro, Business and Enterprise zones only once it is deployed. Cloudflare’s managed rules documentation covers deploying it. Either way the WAF inspects only requests that travel through Cloudflare, and an attacker who knows your origin IP can send the exploit straight to the server.
That is not a theoretical gap. On a production web server we looked after during the disclosure, a request to the origin IP with the right Host header returned the WordPress login page with a 200, which meant the WAF was never in the path. Closing it means the origin accepts web traffic only from Cloudflare’s published ranges, and that has costs you should check before you run a single command:
- DNS-only hostnames: any site on the server that is not proxied through Cloudflare stops loading the moment the rules apply, so list your grey-cloud records first.
- Certificates: HTTP-01 on proxied hostnames still reaches the origin through Cloudflare’s ranges, so only DNS-only hostnames, or any validation that goes straight to the origin, need DNS-01 or Cloudflare origin certificates.
- Open ports: a port opened with
--add-port=80/tcpis not removed by--remove-service, so remove it with--remove-portas well. - Docker: published container ports skip firewalld’s input rules entirely, so publish them on
127.0.0.1behind the host’s web server, or filter them in theDOCKER-USERchain. - Range changes: the ipsets are static, so refresh them whenever Cloudflare publishes new ranges.
This section is firewalld only, the RHEL-family default, and that is the only firewall we tested it on. Ubuntu and Debian servers usually run ufw or plain nftables, which need their own rules. The commands below change the default zone, so first confirm the public interface sits in it:
sudo firewall-cmd --get-active-zonesOur Rocky Linux 9 VM had a single active zone holding the only interface. If yours lists the web-facing interface under another zone, add --zone= with that name to every command that follows:
public
interfaces: eth0Then check that no web port was opened by number, which would survive the lockdown:
sudo firewall-cmd --list-portsOn our VM it printed an empty line, so services were the only way in. If yours lists 80/tcp or 443/tcp, take them out first with sudo firewall-cmd --permanent --remove-port=80/tcp --remove-port=443/tcp. Next, load Cloudflare’s ranges into ipsets, which keep the range list out of the rule definitions:
curl -fsS https://www.cloudflare.com/ips-v4 -o /tmp/cf4.txt
curl -fsS https://www.cloudflare.com/ips-v6 -o /tmp/cf6.txt
sudo firewall-cmd --permanent --new-ipset=cf4 --type=hash:net
sudo firewall-cmd --permanent --new-ipset=cf6 --type=hash:net --option=family=inet6
sudo firewall-cmd --permanent --ipset=cf4 --add-entries-from-file=/tmp/cf4.txt
sudo firewall-cmd --permanent --ipset=cf6 --add-entries-from-file=/tmp/cf6.txtThen allow HTTP and HTTPS only from those sets and remove the open services, so the new rules are the only way in. SSH is untouched, so you will not lock yourself out:
for svc in http https; do
sudo firewall-cmd --permanent --add-rich-rule="rule family=\"ipv4\" source ipset=\"cf4\" service name=\"$svc\" accept"
sudo firewall-cmd --permanent --add-rich-rule="rule family=\"ipv6\" source ipset=\"cf6\" service name=\"$svc\" accept"
done
sudo firewall-cmd --permanent --remove-service=http --remove-service=https
sudo firewall-cmd --reloadCount what actually loaded before you trust it. wc -l on the downloaded files reported 14 and 6 ranges, because Cloudflare’s lists have no trailing newline and wc counts newlines, not lines. firewalld read the last line anyway:
sudo firewall-cmd --ipset=cf4 --get-entries | wc -l
sudo firewall-cmd --ipset=cf6 --get-entries | wc -lBoth sets held the full lists:
15
7A request from another lab host straight to the server’s IP was refused (curl exit code 7), while traffic through Cloudflare kept flowing on the production server.
Refreshing the sets later is where a careless loop can lock out every visitor. If the download fails or returns a page instead of a range list, a plain swap would empty the allow list on the next reload. We put the refresh in a script that checks every download before it touches anything:
sudo vim /usr/local/sbin/cf-ipset-refresh.shThe script fetches both lists and validates both before it touches either set: each needs at least five CIDR lines, and any line that is neither blank nor a CIDR aborts the run. Only then does it swap the permanent entries and reload, and set -euo pipefail stops it at the first failed command:
#!/bin/bash
set -euo pipefail
base="${CF_IPS_URL:-https://www.cloudflare.com/ips-v}"
tmp=$(mktemp -d)
trap 'rm -rf "$tmp"' EXIT
for v in 4 6; do
curl -fsS "${base}${v}" -o "$tmp/cf$v.txt"
n=$(grep -cE '^[0-9a-fA-F:.]+/[0-9]{1,3}$' "$tmp/cf$v.txt" || true)
if [ "$n" -lt 5 ]; then
echo "ips-v$v returned $n ranges, leaving the ipsets alone" >&2
exit 1
fi
if grep -vqE '^([0-9a-fA-F:.]+/[0-9]{1,3})?$' "$tmp/cf$v.txt"; then
echo "ips-v$v has a line that is not a CIDR, leaving the ipsets alone" >&2
exit 1
fi
done
for v in 4 6; do
firewall-cmd --permanent --ipset=cf$v --get-entries > "$tmp/cf$v.old"
firewall-cmd --permanent --ipset=cf$v --remove-entries-from-file="$tmp/cf$v.old" >/dev/null
firewall-cmd --permanent --ipset=cf$v --add-entries-from-file="$tmp/cf$v.txt" >/dev/null
done
firewall-cmd --reload >/dev/null
echo "cf4=$(firewall-cmd --ipset=cf4 --get-entries | wc -l) cf6=$(firewall-cmd --ipset=cf6 --get-entries | wc -l)"Make it executable for root only and run it once by hand:
sudo chmod 0750 /usr/local/sbin/cf-ipset-refresh.sh
sudo /usr/local/sbin/cf-ipset-refresh.shA good run prints the counts it loaded:
cf4=15 cf6=7We then broke it on purpose through the CF_IPS_URL override. A made-up path on cloudflare.com answered with a 301 and an empty body, which curl -f does not treat as an error, and the range check caught it with “ips-v4 returned 0 ranges, leaving the ipsets alone” and exit code 1. An unresolvable host made curl itself fail with exit code 6. A crafted list with all 15 real ranges plus one junk line, served through a file:// URL, stopped with “ips-v4 has a line that is not a CIDR, leaving the ipsets alone” before any set was touched. After all three failures the permanent and running sets still held 15 and 7 entries. The script is short enough to run from a weekly timer, which costs nothing and keeps a new Cloudflare range from turning into a partial outage.
What None of This Covers
Every control above targets a confirmed path, and PHP’s advisory is explicit that other variants exist. Upload progress off blocks the session producer for CVE-2026-109619 but not every stale-state consumer, and backtraces off closes only the confirmed 8.5 backtrace path. The advisory also asks you to remove invalid or deprecated per-request INI settings that emit diagnostics before initialization, and notes that hiding those diagnostics with error_reporting, display_errors or @ does not help. The multipart block stops the confirmed 109618 trigger, but memory can run out in other parsing paths too, and a WAF only blocks the request patterns it knows.
CISA’s alert is blunter than any of this: organizations that can’t update immediately, or still run PHP 8.1 or older, should take PHP systems offline until they are patched. It had not observed exploitation at publication, and it says a WAF may provide some protection in the meantime. We’d stay online behind these layers only where taking the site down costs more than the risk and the patch is days away, not weeks. If a fixed build exists for your platform, the per-distro guides in the PHP2Shell check and patch guide take minutes. Red Hat shipped AppStream errata for its supported PHP streams on 21 October, and the RHEL-family patch guide covers those plus the Remi builds for streams Red Hat did not fix.
Undoing the Mitigations After You Patch
Some of these settings cost you something, so once the fixed PHP is running and verified, decide which ones to keep. We kept the cheap ones and removed the ones that break features or hurt performance:
- Upload progress off: keep it. The 109619 advisory says it might be prudent to disable this hardly-used, hardly-tested feature if you don’t need it, and few applications notice.
- Backtraces off on 8.5: keep it on production servers, where a backtrace in a fatal error helps whoever triggered it more than it helps you.
- Lower
post_max_size: keep the lowered limit if the sites still work. - Multipart block: remove it, because it breaks every upload.
memory_limit = -1: set a real limit again, because the fixed PHP adds a hard limit derived from it.pm.max_requests = 1: return it to your old value.- Origin lockdown: keep it. It protects you from the next WAF bypass, not only this one.
For the multipart block on nginx, delete the if block, then run sudo nginx -t and reload. On Apache, sudo a2disconf php2shell-block-multipart followed by a reload takes it out without touching the file, so you can switch it back on in seconds if another PHP advisory lands. The hard memory limit explainer covers what the patched PHP does when a worker crosses the new ceiling.
