# Immediate Measures If You Cannot Patch Yet

> Workaround for the PHP vulnerability PHP2Shell: the interim measures from php.net, set correctly, with their limits and notes on the road to the patch.

Source: https://phpsos.de/en/php2shell/sofortmassnahmen-ohne-patch/  
As of: 25/10/2026  
Provider: PHP SOS, PHP emergency help and server security. Immediate help via WhatsApp: https://wa.me/491736494914?text=Hello%20PHP%20SOS%2C%20we%20need%20help%20with%20our%20PHP%20server.%20Company%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**In short:** A workaround for the PHP vulnerability PHP2Shell can lower the risk but does not replace the update. For this, php.net lists fixed memory and upload limits, disabling session upload progress and, on PHP 8.5, `fatal_error_backtraces=0`. If even that is not possible at short notice, the BSI recommends taking the web server off the network temporarily.

## What a workaround can and cannot do

The interim measures from php.net are meant to make the conditions under which the vulnerabilities CVE-2026-109618 and CVE-2026-109619 can be exploited harder to meet. They are explicitly **not full protection**. The vulnerabilities are only fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or in a confirmed backport from your provider.

The measures make sense when the update cannot yet be applied for a concrete reason: a maintenance window is still pending, an application has to be tested first, or you operate PHP 8.1 or older, for which there is no official update any more. They are then a bridge, not a destination.

So plan the update at the same time as the workaround: who carries it out, in which maintenance window, and who checks afterwards that all workers have been restarted? A transition without an end date threatens to become a permanent state.

## Option 1: Take the server off the network temporarily

The BSI has declared warning level 3 (orange) and recommends taking affected web servers off the network temporarily if the update is not immediately possible. Some providers have done so as a precaution; this does not mean that those sites were hacked.

For many companies, an outage of the shop or portal is expensive. A trade-off can make sense: access only via VPN or approved IP addresses, a static maintenance page instead of the PHP application, or switching off individual, unneeded websites on the server. The less PHP is reachable from outside, the smaller the attack surface.

It is important to make the decision consciously and record it: who decided when to leave the server online, and with which protective measures? This helps later towards insurers, data protection and management.

## The interim measures from php.net

| Measure | Value | Note |
|---|---|---|
| `memory_limit` | `-1`, not overridable | then set a memory limit via container or cgroup |
| `post_max_size` | `8M` without uploads, `32M` with uploads | keep `upload_max_filesize` below it |
| Memory limit | via container/cgroup | not via `RLIMIT_AS` or `RLIMIT_DATA` |
| `session.upload_progress.enabled` | `0` | in php.ini, pool or server configuration, not via `ini_set()` or `.user.ini` |
| `fatal_error_backtraces` | `0` | PHP 8.5 only |

The setting `session.upload_progress.enabled=0` is at the same time the remedy for the vulnerability [CVE-2026-115560](https://phpsos.de/en/php2shell/cve-2026-115560/) reported on 23 October.

## Setting the workaround for the PHP vulnerability correctly

The place is decisive. The values must be set so that an application cannot override them. Paths and service names differ by distribution; the examples assume PHP 8.3.

**PHP-FPM, in the pool** (e.g. `/etc/php/8.3/fpm/pool.d/www.conf`):

```ini
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5 only:
; php_admin_flag[fatal_error_backtraces] = off
```

**Apache with mod_php,** in the server configuration or in the VirtualHost:

```apache
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
```

**Memory limit via cgroup,** here via systemd for the FPM service. You adjust the value to your server:

```ini
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
```

Then restart all workers, otherwise none of it takes effect: `systemctl restart php8.3-fpm` or, with mod_php, Apache. How to check that no old process is still running is described at [Restarting PHP-FPM and all workers](https://phpsos.de/en/php2shell/php-fpm-neustart/). General hardening of the configuration is covered in [Configuring php.ini securely](https://phpsos.de/en/ratgeber/php-ini-sicher-konfigurieren/).

> **Important:**
> Test uploads and large forms after the change. A `post_max_size` that is too tight can block orders, application forms or media uploads. That is one reason not to postpone the update for long.

## Additional protection layers

A web application firewall or virtual patching can help as a further layer. Cloudflare has rolled out protection rules but itself warns that rules based on request data alone are not sufficient. A WAF is therefore a supplement, not a replacement. More at [WAF and virtual patching](https://phpsos.de/en/leistungen/waf-virtuelles-patching/).

Also preserve the server logs from 20 October onwards. According to media reports, a first attack attempt was already observed on 17 October; the logs are the basis if you later have to clarify whether something happened before the patch.

## How does PHP SOS help?

- **Clarify the situation:** We check whether an update is possible at short notice or whether a transition is needed, and discuss with you the option of taking parts off the network.
- **Apply the measures:** We enter the php.net values at the right place, set the cgroup limit and restart all workers.
- **Test function:** We check forms, uploads and order processes after the change.
- **Lead to the patch:** Through the [PHP patch service](https://phpsos.de/en/leistungen/php-patch-service/), we plan the update and then roll back the interim values in a controlled way where they cause problems.


## Frequently asked questions

**Does the workaround fully protect against PHP2Shell?**  
No. php.net explicitly describes the measures as a transition and not as full protection. They reduce the risk until the update is installed. The BSI (German Federal Office for Information Security) recommends taking servers without the patch off the network temporarily.

**Can I set the values via .htaccess or .user.ini?**  
For session.upload_progress.enabled, php.net explicitly rules out ini_set() and .user.ini. For memory_limit too, the value must be set so that the application cannot override it. That works in php.ini, in the FPM pool with php_admin_value or in the Apache server configuration.

**Is a web application firewall enough as a workaround?**  
As an additional layer it can help. Cloudflare has rolled out protection rules but itself points out that rules based on request data alone are not sufficient. A WAF replaces neither the update nor the interim measures on the server.

**What do I do if I only have shared hosting?**  
Then php.ini and the restart are in the hosting provider's hands. Ask specifically whether the update has been installed or the interim measures applied, and whether all PHP processes have been restarted.

## Sources

- [php.net: Security announcements](https://www.php.net/)
- [BSI: German Federal Office for Information Security](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)