In short: Anyone who wants the PHP vulnerability PHP2Shell closed today needs four things: the right update, a restart of all PHP processes, a check for malicious code that has already been planted, and proof. Affected? Call us. We help. We handle it remotely, from the first message.
Do not delete anything and do not rebuild anything right now. When patching, too, the rule is: secure first, then change. If something has already got in, we need the state of files and logs. Report an emergency and we will work out the order with you.
Why the Vulnerability Cannot Wait
The two vulnerabilities CVE-2026-109618 and CVE-2026-109619 are in PHP itself and allow remote malicious code without logging in. The BSI (German Federal Office for Information Security) has declared warning level 3 (orange) and recommends updating immediately. If that is not possible right away, web servers should be taken offline temporarily. According to media reports, the first attack attempts were observed even before the patches were released on 21 October 2026. Cloudflare observed attempts and rolled out protective rules, but warns that rules based on request data alone are not enough.
Important for operators: a CMS update does not close the PHP vulnerability. According to reports, WordPress.org does not plan an update against it either, because the flaw is in the interpreter. It is only closed at the PHP level, that is, in what your server actually runs.
What to Do Right Now
- Know the target version. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are fixed. PHP 8.2 reaches end of support on 31 December 2026, so factor that in.
- Record all systems. Including test servers, container images and legacy systems reachable from the internet.
- Clarify responsibility. With hosting packages and managed servers, the provider handles it. Ask in writing about the version and the restart.
- Keep the logs. From 20 October 2026 onward, according to trade press.
- Agree a time window. A restart briefly interrupts running requests. Set a time when someone can make decisions.
- Do not wait if it is exposed. If patching is not possible right away, work with us on isolating the system or on interim measures.
How Does PHP SOS Help?
- Assess the situation: We record systems, PHP versions, operating modes, hosts and reachability, and set the order: the most exposed systems first.
- Secure and close: We secure the current state, apply the update or bring the hosting to the demonstrably patched state, and restart all processes. For containers we rebuild the image and roll it out.
- Check and clean up: Because a patch does not remove malicious code, we check for signs of an earlier break-in and clean up if needed.
- Harden and report: You receive written proof per system and recommendations so that the next update goes faster. The scope of service is described by the PHP patch service.
Update, Restart, Proof: What Matters
The most common mistake is an update without a restart. As long as old processes are running in memory, the vulnerable code stays active even though the files are new. The instructions are on the page Restarting PHP-FPM and all workers. The second mistake is believing the display: distributions and hosts often ship backports, in which case the version number stays the same. What is conclusive is the package changelog with the CVE numbers; on the Debian family use apt-get changelog <package>.
In addition, according to the PHP manual, the new directive memory_hard_limit_percent has existed since the security releases. A PHP version that does not know it is affected. The test is short:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
It has to be run per version and operating mode, because the command line can use a different PHP version than the web server. At the end we record the result so that you can show it to your host, insurer or client.
If the Update Is Not Possible Right Away
There are reasons why an update is not possible today: an old application that does not run on newer PHP versions, a host that has not released it, a container image in a fixed pipeline. For these cases php.net names interim measures that are explicitly not complete protection: set memory_limit=-1 so that applications cannot override it, limit post_max_size, session.upload_progress.enabled=0 and, on PHP 8.5, fatal_error_backtraces=0, each with a restart. In addition there are protective rules at the edge, which do not replace an update. A tip going around to block all requests with PHPSESSID is expressly rejected by expert authors.
Which measures suit your system and what they can break, we discuss beforehand. You will find more on the page Immediate measures if you cannot patch yet and under WAF and virtual patching. PHP 8.1 and older is a situation of its own, described under PHP 8.1 and older: what applies now.
What You Should Send Us
- A list of servers and hosts, as far as available
- The output of
php -vper system and a note on the operating mode - Whether containers, Plesk, cPanel or a managed offering are in use
- The desired time window and a contact person for restarts
- Any irregularities noticed since 17 October 2026
Why PHP SOS
We work Made in Germany and, together with our partner network of cyber professionals, have specialized in IT security for over 25 years. You have one contact who accompanies the update, checks the restart and delivers the proof. We work remotely, with no travel, and document every step. We do not promise miracles: a patch closes the vulnerability, but it does not prove that nothing happened beforehand, and we will tell you exactly that.
Affected? Call Us. We Help.
Do not leave the vulnerability open any longer. Call us or write to us on WhatsApp. We take over from the first message and stay with you until the incident is closed and documented. Report an emergency now.
Frequently asked questions
Can I close the PHP vulnerability myself or do I need help?
An update is doable for admins but error-prone: it has to apply to the version that actually serves your site, and all processes must restart. Anyone with several servers, container images or a host with quirks saves time and mistakes with support.
Does PHP have to be restarted after the update?
Yes. New files alone are not enough as long as old PHP processes are still running in memory. All workers or processes must be restarted, and with mod_php the web server.
What if there is no update yet for my PHP version?
For PHP 8.1 and older, the PHP project no longer ships official updates. In that case you need a provider's backport that is demonstrably patched, a migration to a maintained version, or interim measures, which do not offer complete protection.
Is it enough to set session.upload_progress.enabled to 0?
No. According to expert reports, that setting alone does not close both vulnerabilities; the PHP update remains mandatory. Set it only in php.ini, the FPM pool or the server configuration, not via ini_set() or .user.ini.
How do I know that the vulnerability is really closed afterward?
Through proof on the running system: the version or package changelog, a test for the new directive memory_hard_limit_percent, and confirmation that all processes were restarted after the update.