When the PHP2Shell vulnerabilities became public, my thoughts went back to Log4Shell.
Five years ago, Log4Shell showed how difficult it can be to respond to a critical vulnerability in software used across countless applications and services. PHP2Shell presents a similar challenge. The technical details are different, but the need to quickly understand where you’re exposed and take action is very familiar.
I believe we should expect more incidents like this. AI is making it possible to discover vulnerabilities in widely used software at a speed and scale we haven’t seen before. As these capabilities become more accessible, we are likely to see more critical vulnerabilities come to light.
The question is how well prepared we are to deal with them.
The first challenge: Knowing where you’re exposed
That preparation starts with understanding what software you’re running and where.
PHP powers a significant portion of the web, including many applications and services. The PHP2Shell vulnerabilities affect the PHP runtime itself, not necessarily the applications built on top of it.
Knowing which business applications you operate is not enough. You need to understand the underlying infrastructure and software components they depend on, where those components are running, and who is responsible for maintaining them.
The challenge also extends to SaaS applications and externally managed services. We may not control their underlying infrastructure, but we still need to understand whether they are affected and what actions their providers are taking.
Check Point Research has reported PHP2Shell-related activity affecting 10% of organizations worldwide, rising to 14% in Europe. The scale of the activity shows why understanding exposure becomes so urgent when vulnerabilities emerge in widely used technologies.
AI is changing the timeline
PHP2Shell became public ahead of its planned coordinated disclosure. Even though not all technical details were available, the disclosure itself gave attackers a starting point.
Once a vulnerability is known, even with limited technical information, AI can help analyze the affected code, identify the underlying weakness, and develop potential exploits. What previously required significant manual investigation can now be accomplished much faster.
Once an exploit becomes available, automated platforms can quickly scan internet-facing systems, identify vulnerable targets, and attempt exploitation at scale. These capabilities have existed for many years, but faster exploit development, combined with automated attacks, further reduces the time defenders have to react.
During Log4Shell, we saw how quickly a newly disclosed vulnerability could turn into a global security challenge. Today, that process has the potential to move even faster.
For defenders, this means knowing where we’re exposed, finding vulnerabilities before attackers do, and deploying new protections as soon as they become available, while working on permanent fixes.
Responding on multiple fronts
At Check Point, we ran several activities in parallel from the first hours of the PHP2Shell disclosure. We started by mapping where PHP was running across our environment and identifying which systems could potentially be exposed. Rather than waiting for patches, we immediately took steps to reduce risk, including restricting access to certain services and validating that others had appropriate security protections in place.
We also contacted the SaaS providers we rely on to understand their exposure and remediation plans. In parallel, we began working with the owners of our systems to deploy the necessary patches, a process that is still ongoing and will take time. The immediate mitigations are essential, but they only buy us time. Ultimately, the underlying vulnerabilities need to be fixed.
As Check Point’s first customer, we use our own security products to protect our infrastructure. We verified that the relevant products were not vulnerable and applied the necessary mitigations in the first hours of the incident.
Within hours of notification, Check Point’s product teams delivered new IPS protections across relevant security products. We deployed these protections internally while making them available to customers. Check Point also published security advisories and technical guidance to help customers understand their exposure and take appropriate action.
The important lesson from our experience is that these activities cannot wait for one another. Understanding exposure, reducing immediate risk, deploying protections, and preparing permanent fixes must happen in parallel.
Four capabilities that make a difference
Looking at PHP2Shell through the experience of Log4Shell, I believe four capabilities deserve particular attention.
- Know your infrastructure and who owns it
An accurate asset inventory is important, but it needs to go beyond a list of applications and servers. Organizations need to understand the technologies running across their infrastructure, their dependencies, and who is responsible for maintaining them.
Continuous Threat Exposure Management (CTEM) helps organizations continuously identify, prioritize, and validate exposure, so response teams can focus first on weaknesses that are both reachable and consequential.
- Find weaknesses before attackers do
We cannot rely only on discovering vulnerabilities after they become public.
Continuous Threat Exposure Management (CTEM) helps organizations continuously identify, prioritize, and validate their exposure.
Agentic scanning takes this further. AI agents can explore environments, look for previously unknown weaknesses, and investigate potential attack paths. This complements traditional vulnerability scanning and gives defenders an opportunity to discover and address weaknesses before attackers exploit them.
These capabilities must operate safely, with clear boundaries on what scanning agents can do, particularly in production environments.
- Deploy protections as soon as they become available
Patching remains essential, but it takes time. IPS, WAF, segmentation, and other security controls can reduce exposure while the underlying vulnerabilities are being fixed.
The important part is ensuring these technologies are properly configured, continuously updated, and protecting the relevant infrastructure and services. New protections should be deployed as soon as they become available, without waiting for the full patching process.
- Make your infrastructure patchable
Having spent years managing enterprise IT, I know that patching is not always straightforward. Legacy systems, complex dependencies, and accumulated technical debt can turn a security update into a major project.
Security teams can identify and prioritize vulnerabilities, but they depend on infrastructure and application teams to implement the fixes.
Making infrastructure patchable requires ongoing investment in modernization, automation, testing, and clear ownership. It is something organizations need to work on continuously, not only when a critical vulnerability is disclosed.
The ability to deploy security updates quickly is just as important as the ability to identify vulnerabilities.
Preparing for the next Log4Shell
We don’t yet know whether PHP2Shell will have anything close to the impact of Log4Shell. But the operational challenge is familiar, and AI is changing how quickly it can develop.
My main takeaway is that preparation must translate knowledge into action: knowing what runs in the environment, who owns it, which weaknesses matter most, and how quickly mitigations and permanent fixes can be deployed. We cannot control when the next critical vulnerability will be discovered or disclosed. But we can control how prepared we are to respond.
And with AI accelerating both vulnerability discovery and exploitation, that preparation will increasingly determine how well we can protect our organizations.
