In short: What PHP2Shell and Log4Shell have in common is that they are critical vulnerabilities in a very widely used basic component through which attackers can execute code without logging in. They differ in visibility, in rating and in the situation regarding known attacks. The most important lesson from Log4Shell applies unchanged today: anyone who knows where the affected component runs acts in hours instead of weeks.
Why the comparison is appearing everywhere right now
In December 2021, Log4Shell kept the IT world on edge for weeks. At the time, the BSI (German Federal Office for Information Security) declared the highest warning level, red. Almost five years later, the same name comes up in many articles on PHP2Shell, often with the question: "Will this be as bad again?"
The comparison is an obvious one, and it is useful if it is drawn correctly. It shows which patterns repeat themselves and which experiences companies can use directly today. How the BSI rates the current situation is explained in the article BSI warning level orange.
PHP2Shell and Log4Shell compared directly
| Feature | Log4Shell (2021) | PHP2Shell (2026) |
|---|---|---|
| Affected software | Java library Log4j | the PHP runtime itself |
| Identifier | CVE-2021-44228 | CVE-2026-109618, CVE-2026-109619 |
| Rating | CVSS 10.0 (v3) | CVSS v4.0 9.2 |
| Effect | code execution without login | code execution without login |
| BSI warning level | 4 / red | 3 / orange |
| Situation at the time of the warning | compromises known according to reports at the time | attack attempts reported, according to the BSI initially no confirmed successful attacks on a broad scale |
| Visibility | often hidden deep inside applications | visible on the server, but patch level hard to read because of backports |
| Follow-up announcements | several further CVEs within a few weeks | notice on CVE-2026-115560 on 23 October |
What the two vulnerabilities have in common
One basic component, countless applications. Log4j was built into Java software of every kind, and PHP carries WordPress, Shopware, TYPO3 and countless custom developments. In both cases it is not one product that is affected but a foundation.
No login needed. Both vulnerabilities allow code to be executed remotely without logging in. That makes them attractive for automated attacks.
The patch is not the end. With Log4Shell it emerged that many systems had already been attacked before the update. The same applies to PHP2Shell: a patch does not remove malware that has been planted. According to media reports, a first attack attempt was observed as early as 17 October.
Follow-up announcements. After Log4Shell, further CVEs for Log4j appeared within a few weeks. With PHP, the notice on CVE-2026-115560 came two days after the patches. Why further announcements are likely is explained in After PHP2Shell: why further announcements are likely.
Where the comparison falls short
The biggest difference lies in visibility. Log4j was often built in as part of an application, sometimes nested several times over. Many operators simply did not know they were using it. PHP, by contrast, is no secret on a web server. Instead, PHP2Shell brings a different kind of uncertainty: distributions and hosting providers install fixes as a backport, and the displayed version number stays the same. You can see PHP, but not immediately whether it is patched.
A second difference is the starting position for the update. With Log4Shell, vendors of specialist applications often had to supply new versions first. With PHP2Shell, updates are available for all supported branches. It gets difficult with PHP 8.1 and older, for which the PHP project no longer publishes official updates.
A third difference concerns the place of the attack. With Log4Shell, any place where an application logged input could be dangerous, including internal systems that only indirectly received data from the internet. With PHP2Shell, the web server, which accepts requests directly, is at the centre. This makes the search for affected systems somewhat clearer: first come all publicly reachable PHP services, then internal applications.
Finally, the situation regarding exploitation differs. For Log4Shell, simple attack tools circulated early, and compromises were already known at the time of the warning according to reports at the time. With PHP2Shell, Cloudflare and Patchstack report attack attempts, watchTowr says it reproduced one of the vulnerabilities, and the BSI initially did not report confirmed successful attacks on a broad scale. That may change. But it is one reason why the comparison is no use as a forecast.
Use the experience from Log4Shell in your own organisation: Which lists, processes and contacts helped back then? Much of it can be reused directly for PHP2Shell.
Five lessons from Log4Shell that help today
- Inventory before patch: Anyone who had an up-to-date list of their systems in 2021 was faster. The same is true today. A guide is offered by the article Inventory of all websites and servers.
- Know your dependencies: A parts list of software components, SBOM for short, answers the question "Where do we use this?" in minutes. For PHP applications, a look into Composer helps, as described in Checking Composer dependencies.
- Keep logs: After Log4Shell, many companies could no longer establish whether they had been affected because logs were missing. For PHP2Shell, the trade press advises preserving logs from 20 October onward.
- Check retrospectively: A patch does not answer what happened beforehand. A check for traces is part of it.
- Be prepared for follow-up announcements: The first update is rarely the last. Anyone who has set up the update path cleanly once repeats it quickly.
How does PHP SOS help?
- Inventory: We determine where PHP runs in your company, in which version and operating mode.
- Patch and restart: We install updates and document the status for each system.
- Trace check: We preserve logs and check for anomalies since 17 October.
- Ongoing monitoring: We keep your systems in view so that follow-up announcements do not start from zero again.
What ongoing monitoring looks like is described in Security monitoring for web servers.
Conclusion
PHP2Shell is not Log4Shell, but it rhymes. Both hit a foundation, and both need more than a patch. Companies that took inventory, log retention and update paths with them from 2021 are at an advantage today. For everyone else, now is the time to catch up.
Frequently asked questions
Is PHP2Shell as bad as Log4Shell?
Both are critical vulnerabilities in very widely used software through which attackers can execute code without logging in. The BSI rated Log4Shell red in 2021 and PHP2Shell orange. One important difference: with Log4Shell, according to reports at the time, compromises were already known when the warning was issued, whereas with PHP2Shell, according to the BSI, there were initially no confirmed successful attacks on a broad scale.
What was Log4Shell?
Log4Shell was a critical vulnerability in the Java library Log4j that became known in December 2021 and is tracked as CVE-2021-44228. Log4j was built into a very large number of applications as a component, often without operators knowing.
Will further vulnerabilities follow after PHP2Shell?
That is possible. After Log4Shell, further CVEs for Log4j followed within a few weeks. With PHP, there was already a notice on 23 October about CVE-2026-115560, which only applies with an unusual configuration. Plan for follow-up announcements.
What is an SBOM?
A software bill of materials is a parts list of all the software components that make up an application. With it, you can quickly establish where an affected component is used when a new vulnerability appears.