On 21 October 2026, two critical vulnerabilities in PHP, known collectively as PHP2Shell, prompted urgent security warnings from the UK’s National Cyber Security Centre (NCSC) and other cybersecurity authorities.
Tracked as CVE-2026-109168 and CVE-2026-109619, both vulnerabilities carry a CVSS v4.0 score of 9.2 and could allow unauthenticated attackers to execute malicious code remotely on vulnerable PHP servers.
With PHP widely used across websites, business applications and third-party products, organisations faced an immediate challenge: identifying affected infrastructure and deploying security updates before attackers could exploit the vulnerabilities.
For ThreatSpike customers, the response was already underway. Affected customer systems managed by ThreatSpike had been patched before their teams even arrived at work.
The PHP2Shell disclosure is a reminder that effective vulnerability management depends on more than identifying threats. It requires the visibility, operational control and ability to act quickly enough to reduce exposure.
What is PHP2Shell?
PHP2Shell is the collective name for two critical remote code execution (RCE) vulnerabilities affecting PHP, a widely used server-side scripting language. The vulnerabilities affect the PHP runtime itself rather than a specific website, plugin or application. Both flaws relate to how PHP handles memory and internal application state:
- CVE-2026-109618 – Out-of-Memory Corruption: Under certain conditions, PHP may incorrectly handle memory during an out-of-memory error, potentially creating an opportunity for remote code execution.
- CVE-2026-109619 – Stale Global State: PHP may retain references to memory that has already been freed, potentially allowing attackers to manipulate execution and achieve remote code execution.
Successful exploitation could allow an attacker to execute code remotely without authentication or gain access to sensitive information held in process memory.
As these vulnerabilities exist within PHP itself, affected environments can include applications built on PHP, regardless of whether the underlying application code contains its own vulnerabilities. This makes PHP2Shell particularly concerning for organisations with large, distributed or poorly documented IT environments.
Which PHP Version Are Affected By PHP2Shell?
The vulnerabilities affect unpatched PHP installations serving web requests, including environments using PHP-FPM, Apache mon_php and other PHP execution configurations.
The PHP project released fixes on 21 October 2026.
| PHP Version | First Fixed Upstream Release |
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
PHP 8.1 and older versions are no longer supported by the upstream PHP project. Organisations using these versions should migrate to supported release or verify whether their software vendor provides a maintained security fix.
Some vendors have issued security backports for older versions, so the installed version number alone may not establish whether a particular vendor-managed build has been patched. Organisations should check the version and security status of the PHP runtime actually serving their applications, not just the command-line installation.
PHP2Shell may also affect websites built using content management systems such as WordPress, Drupal and Joomla where the underlying server runs a vulnerable PHP version. Updating the application itself does not necessarily address a vulnerability in the underlying PHP runtime.
Why The PHP2Shell Vulnerabilities Pose A Significant Security Risk
The combination of widespread PHP deployment, critical severity and the potential for unauthenticated remote code execution makes PHP2Shell an urgent vulnerability management concern. Security researchers have demonstrated proof-of-concept exploitation, and NHS England’s National Cyber Security Operations Centre has assessed future exploitation as highly likely.
The potential consequences of successful exploitation include unauthorised code execution, access to sensitive information, service disruption and further compromise of connected systems. However, the challenge extends beyond the technical characteristics of the vulnerabilities. Many organisations operate across a mixture of internally managed infrastructure, cloud services, legacy applications and third-party platforms.
PHP may exist within systems that IT teams do not routinely associate with it. This introduces several challenges:
- Identifying every system running a vulnerable PHP installation.
- Understanding which affected systems are accessible from the internet.
- Determining who has responsibility for remediation.
- Coordinating updates across different environments and providers.
- Investigating whether exposed systems experienced suspicious activity before patching.
When IT operations and cybersecurity are managed separately, addressing these challenges can require multiple teams, tools and handovers. The longer it takes to move from vulnerability identification to verified remediation, the longer affected systems may remain exposed.
How ThreatSpike Responded to PHP2Shell
For ThreatSpike customers, the response to PHP2Shell provides a practical example of what continuously managed IT and security can achieve.
Following the disclosure, affected customer systems under ThreatSpike’s management were scheduled for patching before customer teams arrived at work, with groundwork for remediation already completed ahead of the official security updates.. Rather than beginning their day identifying vulnerable systems, coordinating emergency changes and assigning remediation tasks, those customers had already benefited from action taken through ThreatSpike’s managed operations.
Devon Connor, Head of SOC at ThreatSpike, explains how clearly our threat intelligence and unified approach to IT and security enabled our teams to act ahead of the wider industry response:
“Threat Intelligence gathered by the team allowed us to be ahead of mainstream news on this threat. This, alongside our unified approach, meant we could identify affected systems and enabled us to put forward the appropriate remediations and safeguards before the patches were released. Once the patches were released, we were in a position where everything was already scoped and ready to be updated.
By treating IT and Security as inseparable, we were able to turn a critical vulnerability into a routine patching exercise.
PHP2Shell made a particular splash in the news, but there are many that do not with equally serious implications. These are the kind of threats which ThreatSpike routinely identifies and addresses as part of our managed operations.”
Traditional vulnerability management often centres on identifying vulnerabilities, assigning severity ratings and generating remediation tasks. Those activities are necessary, but identifying a vulnerability does not remove the exposure.
Effective security operations must connect vulnerability identification with the operational ability to deploy updates, confirm successful remediation and investigate potential compromise where necessary. That requires visibility across infrastructure, clear ownership and the ability to act without unnecessary delays.
ThreatSpike’s approach combines managed IT, defensive security and offensive security within a single managed platform, reducing the separation between identifying security risks and taking action to address them.
The PHP2Shell response demonstrates the practical value of that approach. When a critical vulnerability emerges, customers should not have to assemble a response from multiple disconnected teams before remediation can begin.
What Organisations Should Do To Protect Against PHP2Shell
Organisations running PHP should assess their exposure and apply the relevant security updates as a priority. The immediate response should address both remediation and the possibility of earlier compromise.
1. Identify Vulnerable PHP Installations
Establish which systems are running PHP, including public-facing websites, internal applications and third-party software. Review software inventories, configuration information and vendor advisories to identify potentially affected installations. Pay particular attention to systems that may sit outside normal infrastructure management processes.
2. Prioritise Internet-Facing Systems
Assess which affected systems are directly accessible from the internet and prioritise remediation accordingly. Internet-facing applications may offer attackers a more accessible route to exploiting vulnerable PHP installations. However, internal systems should not be overlooked, particularly where they support sensitive business processes or can be reached through compromised infrastructure.
3. Apply and Verify Security Updates
Update vulnerable installations to the appropriate patched PHP release or verified vendor-maintained security build. After updating, confirm that the relevant PHP processes have restarted and that the runtime serving application requests is using the patched version. Simply installing an updated package may not be sufficient if services continue running an older PHP process.
4. Investigate Potential Exploitation
Patching a vulnerability prevents exploitation through the corrected flaw, but it does not automatically remove malicious activity that may already have occurred. Security teams should review relevant logs, unexpected processes, unauthorised access and other suspicious behaviour on systems that may have been exposed before remediation. Where compromise is suspected, incident investigation and containment should form part of the response.
5. Address Systems That Cannot Be Immediately Patched
Where updates cannot be applied promptly, organisations should assess the risk and consider temporarily isolating or taking vulnerable services offline. Temporary controls may reduce exposure, but they should not be considered equivalent to deploying a verified security fix.
6. Review Vulnerability Management Processes
Once immediate remediation has been completed, organisations should assess how effectively they responded. How quickly were affected systems identified? Were there gaps in infrastructure visibility? Did remediation require multiple teams or external providers? Could updates be deployed and verified promptly? The answers can reveal wider operational weaknesses that will affect responses to future vulnerabilities.
Why PHP2Shell Demonstrates The Need For Integrated IT and Security Operations
PHP2Shell is the latest example of a challenge organisations face repeatedly: critical vulnerabilities emerge, affected infrastructure must be identified and remediation needs to happen quickly.
Most organisations split a vulnerability across two teams that each see only half of it. Security can identify the flaw but rarely has the access or the authority to patch it. IT has the access, though not always the visibility to judge how serious the threat is or whether someone has already exploited it. Between the two sits a queue of handovers and approvals, and the system stays exposed for as long as that queue takes to clear.
Running IT and security as a single operation shortens that queue to almost nothing. Because the infrastructure is managed continuously, there’s no scramble to find where the vulnerable software lives; it’s already known, so the patch can go out straight away. Defensive monitoring covers the same estate, which means any trace of earlier compromise surfaces in the systems being fixed rather than in a separate investigation, and the findings of offensive testing decide which weaknesses get closed first. Finding a vulnerability and fixing it stop being separate jobs passed from one team to another.
Moving Beyond Reactive Vulnerability Management
PHP2Shell required organisations to respond to a critical security issue affecting technology used across countless applications and services. For many IT and security teams, the immediate priority was identifying vulnerable systems, coordinating updates and reducing the risk of exploitation.
For affected ThreatSpike customer systems under its management, patches had already been deployed before teams started their working day. That difference captures the value of moving beyond reactive vulnerability management.
Organisations cannot prevent every new vulnerability from being discovered, but they can improve how quickly those vulnerabilities are identified, assessed and addressed. The goal isn’t simply to know when something is vulnerable. It’s to have an IT and security operation capable of doing something about it.
Discover ThreatSpike and how our AI-managed IT and security platform brings infrastructure management, defensive security and offensive security together
