In short: PHP2Shell is a pair of critical vulnerabilities in PHP itself that let attackers execute malicious code without logging in. If you need quick help with this PHP vulnerability, we take over the inventory, the patching or an interim measure, the restart of all PHP processes and an initial search for traces, all remotely. At the end you receive a written record of the current state.
Help with the PHP vulnerability: why you need to act now
On 21 October 2026 at 16:00 German time, the PHP project published patches for CVE-2026-109618 and CVE-2026-109619. Both vulnerabilities are rated 9.2 on CVSS v4.0 and allow remote code execution without anyone having to log in. The usual operating modes are affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
The BSI (German Federal Office for Information Security) has issued warning level 3 (orange). It recommends updating immediately and, if that is not possible right away, taking web servers off the network temporarily. Palo Alto Networks (Unit 42) counted more than 22.6 million exposed, potentially vulnerable instances. According to the BSI, confirmed successful attacks at scale were not known at first, but Cloudflare had already reported attack attempts.
For management and owners, this means: every publicly reachable PHP server is a candidate until proven otherwise. You will find an understandable explanation of the vulnerability at What is PHP2Shell?.
Who is the PHP2Shell emergency help for?
For companies, agencies and public bodies that run PHP applications and cannot, or do not want to, work through the situation in the necessary depth on their own. This applies to dedicated root servers and virtual servers as much as to servers with Plesk or cPanel, container environments and managed servers where responsibility is unclear.
Even if you have a hosting provider, you often need support. Many providers apply backports; Plesk, for example, then keeps showing 8.2.34 although the package version is patched. Conversely, a new version number may be displayed while old PHP processes are still running in memory. Which versions count as fixed is listed at Which PHP versions are affected?.
How does PHP SOS help?
- Inventory: We record all PHP installations, operating modes and versions on your servers, including package version and running processes. The result is a list of which systems are affected, fixed or unclear.
- Patch or interim measure: Where possible, we install the fixed versions (8.5.12, 8.4.27, 8.3.36, 8.2.35) or the packages of your distribution. If that is not possible right away, we apply the interim measures described by php.net and say openly that they do not offer full protection.
- Restart and verification: We restart all PHP workers and processes and then check that no old process is still running. New files alone do not close the vulnerability.
- Initial search for traces: We preserve the server logs from 20 October onwards and look for anomalies such as new PHP files, unknown cron jobs or unusual processes. Because there are no published, confirmed indicators of compromise, this check relies on behavioral analysis.
- Record and next steps: You receive a written report. If compromise is suspected, we recommend the appropriate follow-up steps, such as malware removal or a forensic investigation.
A patch does not remove malware that has already been planted and does not prove that nothing happened beforehand. That is why emergency help always includes a look at the period since 17 October 2026.
What you get from us
- an overview of all servers checked, with PHP version, package version, operating mode and patch status
- documentation of the updates installed or the interim measures applied
- proof that all PHP processes have been restarted
- an assessment of the search for traces, separated into proven, probable and unknown
- a list of open items, for example systems running PHP 8.1 or older
You can pass this report on to management, data protection officers or insurers. It does not provide a legal assessment.
What we need from you
- Access: SSH or panel access with sufficient rights, or alternatively your permission for your hosting provider to give us information
- Contact person: someone who is allowed to make decisions, for example about a brief offline period or a restart
- Overview: which websites, shops and applications run on which servers
- Maintenance window: your requirements for when restarts may take place
- Backups: information on where current backups are stored
For admins who would like to check on their own beforehand, this harmless look at the current state is often enough:
php -v
# Debian/Ubuntu: installed PHP packages with version
dpkg -l | grep -i php
# running PHP processes and their start time
ps -eo pid,lstart,cmd | grep -i php
What we do not promise
We do not promise absolute security, nor a statement that your server was never attacked if the evidence does not support it. We work on the incident until it is closed and documented. Whether a notification duty under the GDPR applies or your insurer needs to be informed is something you should clarify with your data protection officer, lawyer or insurer. We supply the technical facts for that.
If you only need the update with proof, our PHP patch service is the right fit. If there are already signs of an attack, the emergency help for a hacked website is the right starting point.
Frequently asked questions
Is it enough if my hosting provider has updated PHP?
It can be, if the provider confirms the package version in writing and all PHP processes have been restarted. The displayed version number alone is no proof, because distributions apply backports. And a patch does not answer whether the server was attacked beforehand.
Does my website have to go offline for the emergency help?
Not necessarily. The BSI (German Federal Office for Information Security) recommends taking web servers off the network temporarily if the update cannot be applied immediately. Whether that is necessary in your case, we decide together after the inventory.
Does a WordPress or Shopware update protect against PHP2Shell?
No. PHP2Shell is in PHP itself, not in the CMS. A CMS update remains sensible, but it does not close this vulnerability.
What happens with PHP 8.1 or older?
The PHP project no longer provides official updates for these versions, only minimal source backports for 7.4, 8.0 and 8.1. We secure the server on an interim basis and plan the move to a supported version with you.