In short: Many PHP2Shell tips that are circulating in forums and on social networks right now do not protect or even do harm: blocking requests with a session cookie, hiding error messages, setting values via .user.ini or updating only the CMS. php.net is unambiguous: there are no complete interim measures; the PHP update with a restart of all processes is the only safe route.
Why bad advice is dangerous in this situation
With a critical vulnerability that attracts great attention, a market for quick fixes emerges. Advice is shared, shortened and passed on, often without the restrictions of the original source. With PHP2Shell, in addition, details reportedly became known before the official date and the situation was confusing in the first few days.
A wrong tip does harm twice over. It leaves the vulnerability open and creates the feeling of having done something. This very feeling leads to the actual update being left undone. Some pieces of advice additionally paralyse your own website.
Nine pieces of advice fact-checked
The following table summarises what we have often read in recent days and sets it against the statements of the primary sources.
| Circulating tip | Why it does not hold up | What applies instead |
|---|---|---|
Block all requests with PHPSESSID |
Expressly rejected by specialist authors; paralyses logins and shopping carts | Update PHP |
session.upload_progress.enabled=0 is enough |
According to specialist reports, does not close both vulnerabilities | Sensible interim measure, update remains mandatory |
Set values via ini_set() or .user.ini |
php.net expressly advises against it | Server-side in php.ini, FPM pool or server configuration |
| Hide error messages | According to php.net, error_reporting, display_errors or @ do not help |
Update; still do not show error output publicly |
Limit memory via RLIMIT_AS or RLIMIT_DATA |
php.net warns that this very measure can trigger the vulnerable situation | Limit via container or cgroup |
| Update WordPress or plugins | The vulnerability is in the PHP interpreter, not in the CMS | Update the PHP runtime |
| Cloudflare or another WAF is enough | Protection only for traffic through the service; directly reachable servers remain open | WAF as an additional layer, not as a replacement |
| Reload the service instead of restarting | According to Red Hat, a reload is not enough; existing workers can keep the old state | Restart all workers completely |
| Patched means clean | A patch does not remove malware planted beforehand | Preserve logs from 20 October and check for traces |
The three most common misconceptions explained in more detail
The cookie ban
The tip to reject all requests with the session cookie PHPSESSID sounds technical and decisive. Specialist authors expressly reject it. In practice, it breaks everything that needs a session: customer accounts, shopping carts, admin areas, forms with forgery protection. It is not a protection against the vulnerability.
The one setting that solves everything
session.upload_progress.enabled=0 is in the php.net recommendations and is the named remedy against CVE-2026-115560. In some articles this became "PHP2Shell switched off". According to specialist reports, however, this setting alone does not close both vulnerabilities. According to php.net, memory_limit=-1 also only removes the controllable trigger; a memory error at a deeper level can still reach the vulnerable path. On PHP 8.5, according to php.net, fatal_error_backtraces=0 only blocks the confirmed route via backtraces.
How to set the setting correctly and permanently anyway is described in the article Disabling session.upload_progress. The complete list of interim measures is under Immediate measures without a patch.
The shield in front
By its own account, Cloudflare has had protection rules active since 21 October, including for customers on the free plan. But Cloudflare itself points out limits: the protection only applies to traffic that runs through Cloudflare. If the origin server is directly reachable, it is bypassed. In addition, Cloudflare also checks the server's response, because the request alone is not always enough. Why a WAF does not replace the update is explained in the article WAF or update.
A tip with risk: filtering upload requests at the edge
Not every inconvenient piece of advice is wrong. Specialist authors suggest, as a temporary, unofficial measure, blocking multipart/form-data requests outside genuine upload paths at the proxy or in the WAF. This can reduce the attack surface but breaks forms and uploads if the list of permitted paths is incomplete.
Anyone who goes this way should test it beforehand in a test environment, coordinate it with the specialist departments and document it as a time-limited measure. It is not a replacement for the update either.
Many WAF solutions offer an observation mode for this, in which rules initially only log instead of blocking. Let a new rule run like this for a few days and evaluate which legitimate requests would be affected. Only then switch to blocking. That way you avoid application forms, customer portals or image uploads in the shop failing unnoticed.
How to check a tip before you implement it
Four questions separate usable from dangerous advice:
- Source: Does the recommendation come from php.net, your distribution, the BSI or a named specialist author?
- Claim: Is the measure described as a stopgap or as a solution? With PHP2Shell, only the update is a solution.
- Side effect: What breaks when the measure takes effect? A tip without a note on side effects is incomplete.
- Place of implementation: Is the setting applied on the server side and in a way that cannot be overridden, followed by a restart of all workers?
Record which interim measures you applied and when. That way you can review them specifically later and see whether a supposed protection delayed the actual update.
How does PHP SOS help?
- We check the measures that have already been implemented at your end and separate the effective from the ineffective.
- We install the PHP update, restart all processes and document the status.
- Where an update is not yet possible, we apply interim measures per php.net on the server side, with documentation.
- With WAF and virtual patching, we add protection at the edge without replacing the update.
Frequently asked questions
Does blocking requests with PHPSESSID protect?
No. Specialist authors expressly reject this circulating tip. It paralyses logins, shopping carts and forms without closing the vulnerability in the interpreter.
Is session.upload_progress.enabled=0 enough against PHP2Shell?
No. The setting is one of several interim measures and, according to specialist reports, does not close both vulnerabilities. It is sensible but does not replace the PHP update.
Does it help to switch off display_errors?
Not for PHP2Shell. php.net points out that hiding diagnostics via error_reporting, display_errors or the @ operator does not help. In production, display_errors should be off anyway for other reasons.
How do I recognise a trustworthy tip?
A trustworthy tip names its source, describes its limits and labels interim measures as such. Anyone who promises that a single setting makes the update unnecessary is wrong about PHP2Shell.