Two critical vulnerabilities affecting PHP have prompted an urgent security alert. Disclosed on 21 October 2026, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell, could allow unauthenticated attackers to execute code remotely on vulnerable servers. Both vulnerabilities have a CVSS v4.0 score of 9.2 out of 10, placing them in the critical severity category. Successful exploitation could allow attackers to compromise affected systems, potentially access sensitive information or disrupt services. The PHP development team has released security updates. Organisations should identify affected systems, prioritise internet-facing infrastructure and apply the appropriate fixes as soon as possible.
What is PHP and why does it matter?
PHP, which stands for PHP: Hypertext Preprocessor, is a widely used server-side scripting language. It runs on web servers to generate dynamic website content, interact with databases and handle the processes that allow websites and applications to function. It supports popular content management systems, including WordPress, Joomla and Drupal, as well as many other websites and business applications. This means organisations do not need to develop software themselves to be affected. PHP may be running behind a company website, within a third-party application or as part of a service provided by a hosting company or technology supplier. Understanding which technologies underpin your digital services is an important part of identifying potential security risks.
What are the PHP2Shell vulnerabilities?
The two vulnerabilities affect how PHP handles memory and internal request data. Under certain conditions, both could allow an unauthenticated attacker to execute code remotely on an affected server.
CVE-2026-109618 involves an out-of-memory error. During certain error-handling circumstances, PHP may leave internal request data improperly initialised. Subsequent cleanup operations can then interact with that data incorrectly, potentially leading to memory corruption and remote code execution.
CVE-2026-109619 involves internal state that can continue to reference memory after it has been freed. If that stale state is subsequently used, it can lead to memory corruption and potentially remote code execution.
Both vulnerabilities are particularly concerning because exploitation does not necessarily require an attacker to log in first. The consequences of a successful attack depend on the affected system, its permissions, its configuration and the security controls in place. The PHP security advisory identifies PHP installations serving web requests as being at risk. This includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team identifies mod_php as a particularly high-risk configuration because a demonstrated exploit can trigger the vulnerability before application code executes. Organisations should therefore check the PHP runtime itself, rather than assuming that updating a website or application automatically resolves the issue.
How does AI fit into the story?
The disclosure of PHP2Shell has also drawn attention to the changing role of artificial intelligence in vulnerability research. AI-assisted techniques can help researchers investigate complex software, analyse code and identify potential weaknesses. These capabilities can support legitimate security research, but similar advances may also help attackers investigate vulnerabilities and develop exploits more quickly. It is important, however, not to suggest that AI independently discovered the PHP vulnerabilities or that its involvement alone explains the risk.
Dr Rebecca Johnson, an AI evaluation and governance expert at the University of Sydney, makes this distinction clear:
“AI didn’t find the PHP flaw on its own. A security researcher knew where to look, drew on decades of earlier work, and used AI to investigate.”
Her point highlights the combination of human expertise and emerging tools behind modern vulnerability research. AI can accelerate parts of the process, but context, experience and technical understanding remain important.
Dr Shaanan Cohney, Senior Lecturer in the Faculty of Engineering and IT at the University of Melbourne, also points to the wider implications for cybersecurity:
“AI has changed things, and this means that now the world has to rethink how we handle the disclosure process of vulnerabilities.”
For organisations responsible for securing their systems, the practical concern is the time between a vulnerability becoming known, a usable exploit emerging and protective updates being applied. As the tools available to researchers and attackers evolve, organisations need to maintain visibility over their technology and be prepared to respond quickly when serious vulnerabilities are disclosed.
What should organisations do now?
Organisations must identify systems running PHP, prioritise internet-facing systems, apply available security updates, monitor for malicious activity and check for updates to third-party products that may include PHP.
The following steps provide a practical starting point.
1. Identify systems running PHP
Establish where PHP is installed or included across your environment. Check public-facing websites, web servers, business applications, hosting environments, containers and third-party products. Do not restrict checks to systems managed directly by your internal IT team. PHP may be bundled into an appliance, application or hosted service, meaning its presence may not be immediately obvious. Create an inventory of affected systems and record their PHP versions, exposure and remediation status.
2. Apply the relevant security updates
The PHP development team released the following fixed versions on 21 October 2026:
| PHP branch | Fixed version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Update to the appropriate fixed release, following the instructions from your PHP distributor, hosting provider or software vendor. After updating, verify that the affected systems are running a fixed version and that the relevant services have restarted where necessary. Test applications and confirm that remediation is complete. Updating a content management system alone may not update the underlying PHP runtime. Similarly, patching PHP on a host will not necessarily update a separate runtime bundled into a third-party application.
3. Review older PHP versions
PHP 8.1 and earlier versions are no longer supported by the PHP project and do not receive routine security updates directly from it. Some operating system distributors and long-term support providers may supply backported fixes. Organisations running older versions should confirm with their supplier whether an appropriate fix is available and whether it has been applied. Where necessary, plan a migration to a supported PHP release. PHP 8.2.35 contains the fixes for these vulnerabilities, but PHP 8.2 reaches end of life on 31 December 2026. Organisations using this branch should plan their next upgrade rather than treating the current security update as a long-term solution.
4. Speak to your managed service provider (MSP)
If an MSP manages your infrastructure, websites, servers or security services, contact them to establish whether any systems they manage are affected. Request confirmation of the affected systems, actions taken and any outstanding risks. Do not assume that responsibility for patching PHP automatically sits with your MSP; responsibilities vary according to the services and support arrangements in place. If your MSP does not manage the relevant systems, work with the website owner, hosting provider or software supplier instead.
5. Reduce exposure if immediate patching is not possible
If an affected system cannot be updated immediately, assess the risk and follow the official PHP and NCSC guidance. Depending on the circumstances, temporary measures may include restricting access or isolating the affected system from public networks. The NCSC advises considering taking systems offline if immediate remediation is not feasible. PHP also documents temporary mitigation measures for certain attack paths. However, there are no complete mitigations that replace applying the security updates. Any interim controls should be assessed against the affected configuration and treated as temporary.
6. Monitor for signs of compromise
Patching is the priority, but organisations should also assess potentially affected systems for suspicious activity. Review relevant web server, application, authentication and endpoint logs. Investigate unexpected processes, commands, file changes, accounts or outbound connections associated with PHP or web server services. Follow your incident response procedures if compromise is suspected. A lack of obvious warning signs does not prove that a system has not been compromised. Monitoring should complement remediation, not delay it.
7. Check third-party software and dependencies
PHP may be included in products and services that your organisation does not manage directly. Contact relevant suppliers to establish whether their products contain affected versions and when fixes are available. Keep track of supplier responses, outstanding updates and any systems that remain exposed. Where a supplier provides a backported fix for an older PHP version, verify that the fix specifically addresses both vulnerabilities. This is particularly important for organisations that rely on hosted platforms, managed infrastructure or specialist business applications.
The key takeaway
PHP2Shell highlights the importance of knowing which technologies support your business and having a clear process for responding to critical vulnerabilities.
Organisations should identify affected systems, apply the appropriate security updates, verify remediation and investigate potential signs of compromise. Where systems are managed by third parties, including MSPs, confirm who is responsible for each action and obtain clear evidence that it has been completed.
For the latest technical details and remediation instructions, refer to the official PHP security advisory and the NCSC alert.