In short: Whether you are affected by PHP2Shell depends on three things: the PHP version, the operating mode, and whether and how patching was done. If you are unsure, get in touch now. Affected? Call us. We help. We clarify this remotely on the server itself, not by gut feeling, and close the vulnerability if it is open.
Do not delete anything and do not rebuild anything right now. Even if you only want to find out whether you are affected: if the server may already have been attacked, we need files and logs unchanged. Report an emergency and we will go through the check together.
Are You Affected? These Cases Belong on the Checklist
PHP2Shell is two critical vulnerabilities in PHP itself (CVE-2026-109618 and CVE-2026-109619, both with the top rating of 9.2 under CVSS v4.0). They allow remote malicious code without logging in. All operating modes can be affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Check each of these systems:
- own servers, virtual servers and root servers running PHP
- hosting packages and managed servers, even if you have no access to the configuration
- containers and platform services that ship a PHP image
- test systems, staging environments and forgotten legacy systems reachable from the internet
- NAS devices, appliances or service provider software that use PHP internally
Forgotten systems in particular are the risk. According to Unit 42 there are more than 22.6 million exposed, potentially vulnerable instances, and the BSI (German Federal Office for Information Security) expected rapid, large-scale exploitation.
What to Do Right Now
- Create an inventory. Write down all servers, domains and hosting contracts on which PHP runs, and who is responsible for each.
- Determine the PHP version per system. On servers use
php -v. Note that the command line can use a different version than the web server. - Clarify the operating mode. Does PHP run as PHP-FPM, as mod_php or via LiteSpeed? With mod_php the PHP team rates the risk highest.
- Ask your host and service providers. In writing: which version is running, was the fix applied, were all processes restarted?
- Keep the logs. Trade press advises keeping logs from 20 October 2026 onward.
- Do not wait long. If a system is exposed and the patch is not immediately possible, the BSI recommends temporarily taking the web server offline.
How Does PHP SOS Help?
We clarify exposure remotely and with evidence.
- Assess the situation: We have you describe your inventory and sort the systems by reachability and risk.
- Secure and close: Where a system is exposed, we first secure its state and then close the vulnerability with an update including a restart. Where that is not immediately possible, we put interim measures in place that are not complete protection.
- Check and clean up: We check whether the vulnerability was exploited before the patch and clean up if necessary. We keep two questions clearly apart: whether a server is affected, and whether it may already have been attacked.
- Harden and report: You receive a list per system: version, operating mode, patch evidence, open items.
How to Prove You Are Affected
A version number alone is not enough, because providers backport fixes. Ubuntu 24.04, for example, reportedly still shows 8.3.6 even after the update. Three approaches are reliable:
| Approach | What it shows | Limit |
|---|---|---|
| Compare the version against the fixed releases | 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or higher is fixed | applies only to original versions, not to backports |
Test for memory_hard_limit_percent |
bool(false) means the directive is unknown, so affected |
run separately for each version and operating mode |
| Search the package changelog for CVE numbers | proves backports in distributions | the source is the provider's security archive |
The test looks like this:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
How to check version and patch status properly is covered on the page Checking the PHP version and patch status correctly. An overview of the branches is given in Which PHP versions are affected?. Why the display can look old despite a patch is explained in the post php -v shows an old number.
Affected and No Longer Patchable: PHP 8.1 and Older
For PHP 8.1 and older there are no official updates from the PHP project any more, only minimal source backports for 7.4, 8.0 and 8.1. Anyone using such a version usually has two options: a provider with a proven backport, or migration to a maintained version. Commercial long-term support offers exist; whether and when they cover PHP2Shell must be confirmed in writing by the provider. We help with the assessment under PHP 8.1 and older: what applies now and with implementation in the PHP patch service.
What You Should Send Us
- A list of your servers, domains and hosts
- The PHP version per system, as far as known
- The operating mode and web server, as far as known
- Whether Cloudflare or another protection layer sits in front and whether the origin server is directly reachable
- Replies from your host, if you have already asked
- A contact person for approvals and restarts
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 get one contact who goes through your inventory and backs up every statement with evidence instead of just reading off version numbers. We work remotely, with no travel, and document what we have checked. We give a statement such as "secure" only to the extent that it can be substantiated. For larger environments, the PHP2Shell emergency response may be appropriate.
Affected? Call Us. We Help.
If you do not know whether you are affected, that is reason enough to get in touch now. Call us or write to us on WhatsApp. We take over from the first message and clarify it with you on the server. Report an emergency now.
Frequently asked questions
Am I affected by PHP2Shell if I only use WordPress or a shop?
Possibly yes. The vulnerabilities are in PHP, not in the CMS. What matters is which PHP version and operating mode actually serve your site; a WordPress update does not change that.
Is the version number enough to know whether I am patched?
Not always. Distributions and hosts sometimes apply fixes as a backport, in which case the number stays the same. What is conclusive is the package changelog listing the CVE numbers or written confirmation from your provider.
Is there a quick test to see whether my PHP version contains the fix?
According to the PHP manual, a version that does not know the directive memory_hard_limit_percent is affected. The test has to be run separately for each PHP version and operating mode, because the command line can use a different version than the web server.
Are older PHP versions such as 7.4 or 8.0 affected too?
According to trade press, almost all versions back to PHP 5.4 are affected. For 8.1 and older there are no official updates from the PHP project any more, only minimal source backports. Whether a provider has applied them must be confirmed by that provider.
Does Cloudflare protect me if I am affected?
Partly. Cloudflare has rolled out protective rules, but itself warns that they do not replace the update. If your origin server is directly reachable, the protection is bypassed.