In short: Virtual patching for PHP bridges the time until the real update is installed. For this we combine the rules of a web application firewall with the interim measures that php.net has published for PHP2Shell, and we set the path to the regular patch right away. This does not offer full protection, but it reduces the risk during the transition period.
When virtual patching for PHP makes sense
For PHP2Shell, the BSI (German Federal Office for Information Security) recommends updating immediately and, if that is not possible, taking web servers off the network temporarily. For many companies neither is feasible right away: a shop has to stay reachable, a custom development needs testing before the update, or the server runs PHP 8.1 or older, for which there are no official updates any more.
In these cases, virtual patching is a bridge. It does not replace the decision of whether going offline would be more appropriate. You make that judgment; we provide the technical assessment.
Why a WAF alone is not enough
Cloudflare reported observed attack attempts and has rolled out protection rules, but warns that rules based on request data alone are not sufficient. The reason lies in the nature of the vulnerabilities. With CVE-2026-109618, an out-of-memory condition can interrupt PHP while request data is only partly initialised. With CVE-2026-109619, internal state can persist after memory is freed and be used by a later request in the same worker. Such flaws depend on the state of the server, not only on the content of a single request.
That is why we rely on several layers: WAF rules in front of the server, interim measures in PHP itself and closer monitoring of the server. Each layer catches part of the problem; none is sufficient alone. Together they buy you the time to install the update in an orderly way.
The interim measures according to php.net
php.net lists several settings that reduce the risk, explicitly without full protection. It is important that applications cannot override these values. An example for a PHP-FPM pool with uploads:
; interim measures for PHP2Shell (no full protection), then restart all workers
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5 only:
php_admin_flag[fatal_error_backtraces] = off
Without uploads, php.net recommends post_max_size = 8M. Because memory_limit is lifted, a memory limit at the level of the container or cgroup is part of the setup, not via RLIMIT_AS or RLIMIT_DATA. The setting session.upload_progress.enabled=0 belongs in php.ini, the FPM pool or the server configuration, not in ini_set() or .user.ini. It is also the remedy for the advisory on CVE-2026-115560. All measures at a glance are at Immediate measures if you cannot patch yet.
Interim measures only take effect after all PHP workers have been restarted. And they only protect against future attacks: they do not answer whether someone got in beforehand.
When going offline is the better choice
Virtual patching is not the right answer in every situation. In some constellations we advise following the BSI and taking the web server off the network temporarily until it is patched:
- the server runs Apache and mod_php, where the PHP team rates the risk highest and an exploit was demonstrated before any application code even runs
- the server holds data that is particularly worth protecting, such as health, client or payment data
- there is no way to set the interim measures firmly in the server configuration, for example with certain shared hosting packages
- there are already signs that the server has been attacked
A temporary offline period does not mean that your website was hacked. Some providers took websites offline out of caution. A short, factual notice page for visitors is then usually a better solution than an unexplained outage.
How does PHP SOS help?
- Assess the situation: We record PHP versions, operating modes and existing protection layers such as CDN, WAF or reverse proxy. With mod_php, we point out the elevated risk that the PHP team sees there.
- Build the layers: We activate or extend WAF rules, set the interim measures firmly in the server configuration and limit memory via container or cgroup. For Nginx setups, we follow Securing Nginx with PHP-FPM.
- Restart and test: All PHP processes are restarted, then we check uploads, forms, login and checkout.
- Monitor: During the transition period we pay closer attention to worker crashes, memory spikes and unusual processes.
- Plan the patch: We set when and how the regular update will happen and carry it out through the PHP patch service.
What you get, what we need and what we do not promise
You get documentation of all rules and settings applied, with the reasoning, the test results and a schedule and action plan for the real patch. From you we need server or panel access, access to the CDN or WAF if there is one, a technical contact person and details of the upload functions in your applications.
We do not promise that virtual patching prevents an attack. It lowers the risk for a limited time. For PHP 8.1 and older it is not a permanent state; here the migration to a supported version belongs in the plan.
Frequently asked questions
What is virtual patching?
Virtual patching means shielding a known vulnerability in front of the application instead of changing the code itself. This is usually done through a web application firewall or configuration changes. It is a stopgap, not a replacement for the update.
Is the WAF of my CDN provider enough against PHP2Shell?
On its own, usually not. Cloudflare has rolled out protection rules but itself warns that rules based on request data alone are not sufficient. The WAF is an additional layer alongside interim measures and the patch.
How long may I rely on virtual patching?
As briefly as possible. It is meant to bridge the time until the regular update, for example until a maintenance window is free or an application has been tested. For PHP 8.1 and older, a migration plan is part of it.
Can the interim measures disrupt my website?
Yes, that is possible. Smaller upload limits can prevent large file uploads, and switching off session upload progress affects progress indicators during uploads. We test the most important functions after every change.