Beyond the Application: Why PHP2Shell Is a C-Suite Test of Enterprise Cyber Resilience

AI-assisted automated scanning and shrinking patch windows are reshaping enterprise risk across the Middle East. With thousands of hosts across the UAE running vulnerable software and global exploitation attempts targeting one in ten organizations, the race to secure critical digital infrastructure has accelerated. From third-party hosting blind spots to taking exposed portals offline, Alex Spokoiny, Chief Security & Trust Officer at Check Point Software Technologies Ltd., speaks to Dubai Diaries about the operational realities of the PHP2Shell vulnerability, what regional metrics reveal about local exposure, and the essential questions business leaders must ask their IT teams today.

1. What has your threat research revealed about PHP2Shell so far? Are you observing scanning, exploitation attempts or confirmed compromises? Please share any available figures and the period they cover. 

In our October 22 update, we reported exploitation attempts against systems at approximately one in ten organizations worldwide since details of the vulnerabilities became public. These figures reflect attempted attacks; they do not establish whether those attempts resulted in a compromise. 

The pattern is familiar: when a widely used software component is vulnerable, organizations need to identify affected systems and act quickly. What has changed is the pace. AI can help accelerate vulnerability analysis and exploit development, while automated scanning allows attackers to find exposed systems at scale. 

Organizations should identify exposed systems, reduce immediate risk and apply the relevant PHP updates in parallel. Internet-facing systems and critical services should be prioritized. Where patching takes longer, mitigation measures should be implemented and verified while remediation efforts continue until the necessary updates can be applied. 

2. Have you observed activity targeting organisations in the UAE or wider GCC? If so, which sectors are affected, and how does the regional activity compare with global trends? 

The regional figures we can share are exposure figures, rather than evidence of attacks. CPR research identified 4,065 UAE hosts advertising PHP; 853 were running end-of-life versions. These are hosts, not organizations, and their geographic attribution does not necessarily indicate the servers’ physical location. 

Globally, our October 22 findings showed exploitation attempts against 20% of telecommunications organizations—twice the overall rate. That points to the potential impact on services many businesses and customers rely on. 

Organizations across the UAE and GCC should identify which customer-facing and operational services depend on PHP, including those managed by third parties. They should then confirm which systems are affected, who is responsible for updating them, and how quickly they can be protected. 

3. Where successful exploitation has been confirmed, what are attackers doing after gaining access? What evidence is available about their objectives and methods? 

A remote code execution vulnerability can allow an attacker to execute commands or run malicious code on the affected server, potentially without legitimate access to the system. From there, the impact depends on the privileges of the compromised process, the data available to the server, and its connectivity to other systems. An attacker may be able to steal or modify sensitive data, deploy malware, obtain credentials, disrupt services, or use the compromised server as a foothold to move deeper into the organization.  
 
The business risk therefore goes well beyond the vulnerable application itself. A public-facing server with access to customer data, credentials, databases, cloud services, or internal systems could become an entry point for a broader breach. 
 
Applying the security update prevents exploitation of the vulnerability going forward, but it does not determine whether exploitation has already occurred. Organizations should review relevant logs and system activity for signs of compromise and, where compromise is suspected or confirmed, assess the scope and initiate the appropriate incident response and recovery process.  
 

4. From your work with customers, what is proving to be the biggest obstacle to addressing PHP2Shell? Are there any anonymised examples that illustrate where businesses are struggling? 

The main obstacle is often identifying exactly where the vulnerable component is running and who is responsible for updating it. An organization may know which website or business application it uses without having a complete inventory of the software underneath it. In this case, updating the website or its plugins alone is not enough: the vulnerability is in PHP itself. 

Even when affected systems are identified, legacy infrastructure and complex dependencies can make patching a larger project. For example, updating a critical customer portal may require coordination between the application team, infrastructure team and an external provider. While compatibility is being tested, the organization also needs to reduce exposure. 

That work should proceed in parallel wherever possible. Clear ownership, testing processes and automation help teams move faster without losing sight of business continuity. 

5. For businesses that outsource their websites or hosting, where are the gaps in responsibility most likely to arise? What evidence should they request before accepting a provider’s assurance that they are protected? 

Gaps can arise when different parties manage the website, hosting environment and connections to internal systems, but no one is clearly accountable for the full service. Before an incident, organizations should establish who identifies affected components, leads remediation and verifies that the fix is complete. 

Businesses should ask their provider for a status they can verify: whether the service is affected, what actions have been taken, how the fix was validated and what remains outstanding. If remediation is still in progress, the provider should explain which mitigation measures are in place, what their limitations are and when the update will be completed. 

Even when a service is managed by a third party, the business impact of a compromise remains the same. Organizations should ensure they receive clear and verifiable information about affected systems, remediation progress and any remaining exposure 

6. Under what circumstances would you advise a business to take an affected website or customer portal offline rather than continue operating with temporary protections? Could you illustrate this with a practical example? 

That decision depends on the sensitivity of the information, the importance of the service and how much risk the organization can reduce while patching is under way. If a service contains sensitive information and cannot be patched promptly, restricting access or temporarily taking it offline may be appropriate—particularly if effective interim protections cannot be confirmed. 

In our testing, Check Point WAF in Prevent mode blocked the published proof-of-concept exploit and several variants without a PHP2Shell-specific rule or configuration change. This illustrates how an existing protection layer can help reduce exposure while remediation is under way. It does not replace updating the underlying PHP infrastructure. 

The decision should be made with the business owner. Teams should agree on the temporary risk they are willing to accept, how customers will be served and what conditions must be met before restoring normal operations. 

7. What is the most important question business leaders should be asking their IT teams about PHP2Shell—and what would a reassuring, verifiable answer look like? 

The most important question is: Where are we still exposed, what does that mean for the business, and what will it take to close those gaps? 

A useful answer should identify the affected services, what has been fixed, what remains open, who owns each action and when it is due. It should also flag any decisions required from leadership, such as prioritizing resources or temporarily restricting a service. The picture should include systems managed by external providers. 

Once the immediate response is under control, leaders should ask what it revealed about the organization’s readiness: how quickly affected systems were identified, whether responsibilities were clear and whether teams could deploy protections and patches promptly. Any gaps should become a concrete improvement plan with owners and deadlines.