The disclosure of the critical PHP2Shell vulnerabilities has prompted organisations worldwide to ask the question: how quickly can we determine our exposure and take action?

While the immediate priority is remediation, PHP2Shell highlights a much bigger shift. AI-assisted security research is accelerating the discovery of vulnerabilities, including flaws hidden in widely used software for decades. As a result, organisations may have less time to assess risk, prioritise responses and implement mitigations before attackers begin exploiting newly disclosed weaknesses.

In this article, Integrity360 CTO Richard Ford explains why PHP2Shell represents more than another high-profile vulnerability and what security leaders can do to prepare for an era of AI-driven vulnerability discovery.

What is PHP2Shell?

Tracked as  CVE-2026-109618 and CVE-2026-10961 , PHP2Shell refers to two critical vulnerabilities that can enable remote code execution across a broad range of PHP versions.

Integrity360's Threat Advisory highlighted the heightened risk for internet-facing applications, particularly deployments using mod_php. A working exploit became available shortly after disclosure, allowing unauthenticated code execution before application logic is processed.

Organisations running affected PHP versions, including those supporting platforms such as WordPress, Joomla and Magento, should prioritise patching, exposure assessment and compromise investigations.

Why PHP2Shell Matters Beyond Patching

The significance of PHP2Shell extends beyond the vulnerabilities themselves.

Historically, most software flaws have been uncovered through manual research, penetration testing, code reviews and bug bounty programmes. PHP2Shell demonstrates how AI-assisted analysis can identify exploitation paths that were previously considered too complex or impractical to discover.

As Richard explains:

“One of the underlying bugs reportedly dates back to 2004, and follows memory safety bugs raised but not addressed. This is in part because creating an exploit was not feasible and, in fact, a core PHP developer discovered the out-of-memory error involved in one of the vulnerabilities back in 2024. Although it was not considered humanly possible exploit, AI-assisted analysis working at machine speed well beyond human capability was able bridge the gap, and find the perfect chain of actions to make it reality. This shows how new technology can uncover weaknesses that have remained hidden for decades, and discover complex paths to exploit them.” 

The key lesson is that vulnerabilities once considered low risk, theoretical or effectively unexploitable may need to be reassessed. AI is increasing both the speed and depth of security research, allowing hidden weaknesses to surface far more rapidly than before.

For defenders, this means the timeline between discovery, disclosure and exploitation is shrinking.

What should organisations do about the critical PHP vulnerabilities?

If they haven’t acted already, organisations need to rapidly identify any affected PHP installations, prioritising internet facing systems and applying the relevant security updates as a matter of urgency. They also need to investigate whether any vulnerable systems have already been compromised.

Patches are available and should be installed asap but organisations slow to do this should consider temporarily taking internet facing applications offline until the patch can be implemented.

Richard advises that affected organisations conduct compromise assessments to look for indicators of exploitation such as unexpected shell invocation and outbound web requests.

The new exposure management challenge

When a critical vulnerability emerges, organisations must answer several questions immediately:

• Where are the affected technologies deployed?
• Which systems are externally exposed?
• What business services are impacted?
• Have compensating controls already reduced risk?
• Is there evidence of exploitation?

The challenge is no longer simply patching systems. It is understanding exposure quickly enough to make informed decisions.

Organisations with strong visibility across their assets, attack surface and technology stack will be significantly better positioned to respond when the next AI-discovered vulnerability appears.

What should organisations do about PHP2Shell?

Organisations should urgently:

1. Identify all affected PHP deployments.
2. Prioritise internet-facing systems.
3. Apply vendor patches immediately.
4. Implement temporary mitigations where patching is not possible.
5. Investigate potential indicators of compromise.
6. Confirm the status of third-party services and suppliers.

According to Richard, organisations should also conduct compromise assessments looking for signs such as unexpected shell execution, suspicious outbound connections and other indicators of post-exploitation activity.

In cases where patching cannot be completed quickly, temporarily removing vulnerable internet-facing applications from service may be the safest option.

How to determine whether you are exposed

Following the disclosure of PHP2Shell, many organisations faced the same challenge: they knew a critical vulnerability existed but did not know where it affected them.

Effective response starts with asset visibility. Security teams should be able to answer:

• Where is PHP running across the organisation?
• Which deployments are internet-facing?
• What PHP versions are currently in use?
• Is PHP embedded within third-party software?
• Have all vulnerable systems been remediated?
• Is there evidence of exploitation activity?

Without this visibility, organisations risk spending valuable time identifying impacted systems while attackers move much faster.

Why PHP2Shell is really an AI Story

Although the security community's immediate focus has been on remediation, PHP2Shell may ultimately be remembered as a milestone in AI-driven vulnerability discovery.

AI can analyse large codebases, identify unusual relationships and uncover exploit paths at a scale that would be difficult for human researchers alone. This capability is likely to accelerate the identification of long-standing vulnerabilities across widely deployed technologies.

For organisations, the question is no longer whether AI will change vulnerability management. It already has.

As vulnerability discovery becomes faster and more effective, security teams must ensure that asset management, attack surface monitoring, threat detection and remediation processes can keep pace.

There is also a proactive lesson for software development teams. The same AI technologies helping researchers uncover vulnerabilities can also be integrated into secure development practices to identify weaknesses earlier in the software lifecycle.

Is traditional Vulnerability Management enough?

PHP2Shell exposes the limitations of a purely reactive approach focused on patching disclosed CVEs.

Security teams need the ability to:

• Maintain accurate asset inventories.
• Continuously monitor attack surface exposure.
• Validate vulnerabilities before prioritisation.
• Assess evidence of compromise.
• Verify remediation effectiveness.

This aligns closely with Continuous Threat Exposure Management (CTEM), which emphasises ongoing exposure discovery, validation and risk reduction rather than periodic vulnerability assessments alone.

Five questions every security leader should be asking

PHP2Shell may be today's priority, but another critical vulnerability will inevitably follow.

Security leaders should ask:

1. Do we know where our most exposed technologies are?

Visibility is essential to rapid response.

2. Can we assess exposure quickly?

Knowing a vulnerability exists is different from knowing whether it affects your organisation.

3. Do we understand third-party risk?

Critical vulnerabilities often extend beyond directly managed infrastructure.

4. Can we detect signs of exploitation?

Monitoring must identify compromise as well as vulnerabilities.

5. Can we respond at the pace the threat requires?

The ability to patch, mitigate, investigate or temporarily isolate systems depends on having accurate exposure data from the outset.

The PHP2Shell vulnerabilty leaves organisations with a simple question:

When the next critical vulnerability is discovered, how quickly will you know whether you are exposed?

Understand your exposure

Knowing about a critical vulnerability is only the first step. Knowing where you're exposed, what needs to be prioritised and whether compromise has already occurred is what enables effective action.

Integrity360 can help organisations understand their attack surface, identify vulnerabilities, assess potential compromise and strengthen their approach to vulnerability and exposure management.

Talk to our cyber security experts to understand your exposure and prepare for what comes next.

FAQs

What is PHP2Shell?

PHP2Shell is the name given to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which can enable remote code execution on affected systems. The vulnerabilities impact a broad range of PHP versions and can create significant risk for internet-facing applications.

Why is PHP2Shell considered so serious?

Successful exploitation could allow an attacker to execute code on a vulnerable server remotely. Given PHP's widespread use across websites, web applications and business services, the potential attack surface is substantial.

What makes PHP2Shell different from previous vulnerabilities?

The vulnerabilities are notable not only because of their severity, but because AI-assisted research reportedly played a role in identifying flaws that had remained hidden in widely used software for many years. This highlights how AI is changing the speed and scale of vulnerability discovery.

Which systems could be affected?

Any application, service or platform running a vulnerable version of PHP may be at risk. This can include internally developed applications as well as popular platforms such as WordPress, Joomla and Magento where affected PHP versions are in use.

How do I know if my organisation is vulnerable?

Start by identifying where PHP is deployed across your environment, particularly on internet-facing systems. Security teams should determine:

• Which PHP versions are in use
• Which systems are externally accessible
• Whether PHP is embedded within third-party applications
• Whether affected systems have been patched
• Whether there is any evidence of attempted exploitation

Are managed service providers and software vendors affected?

Potentially. Many organisations rely on third-party suppliers whose products or services use PHP. It is important to engage vendors and confirm whether they are affected, what mitigations have been applied and whether patches are available.

Has exploitation been observed?

Given the public disclosure of the vulnerabilities and reports of proof-of-concept exploits, organisations should assume threat actors will attempt to exploit unpatched systems and monitor closely for signs of compromise.

What should organisations do immediately?

Organisations should:

1. Identify all affected PHP installations.
2. Prioritise internet-facing systems.
3. Apply vendor patches where available.
4. Implement compensating controls if patching cannot be completed immediately.
5. Review logs and security monitoring for signs of exploitation.
6. Assess third-party suppliers and externally hosted services.

Does PHP2Shell change how organisations should approach vulnerability management?

Yes. PHP2Shell highlights the growing importance of asset visibility, attack surface management and rapid remediation. As AI accelerates vulnerability discovery, organisations may have less time between disclosure and attempted exploitation.

What is the key lesson from PHP2Shell?

The most dangerous vulnerabilities are not always new vulnerabilities. Some may have existed for years, hidden in widely used software, until new technologies such as AI-enabled analysis make them easier to discover. Organisations that can quickly identify their exposure and respond will be best placed to manage this new reality.