On 21 October 2026, the PHP development team released security updates addressing two critical vulnerabilities that could allow attackers to execute code on affected web servers without authentication.
The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, have been grouped under the name PHP2Shell. Both carry a CVSS 4.0 severity score of 9.2 out of 10.
This is not simply another reminder to keep WordPress plugins updated. The underlying problems exist in PHP itself, the runtime that processes requests and executes application code on the server.
That distinction matters. A website can have a carefully maintained codebase, updated dependencies and sensible access controls, yet remain exposed if the PHP runtime underneath it has not received the appropriate security fixes.
For developers, hosting providers and anyone responsible for a production website, the immediate priority is to establish which PHP installations are affected and apply the appropriate updates.
Official advisory: PHP security announcement.
What exactly is PHP2Shell?
PHP2Shell refers to two related vulnerabilities in PHP's request-processing and memory-management behaviour. Under certain conditions, an attacker can exploit these flaws to corrupt process memory and potentially achieve remote code execution.
In practical terms, remote code execution means an attacker may be able to make a vulnerable server execute instructions of their choosing. Depending on the privileges available to the PHP process and the server's isolation boundaries, the consequences could include unauthorised access to application data, modification of website files, installation of malicious code or further compromise of the hosting environment.
The two vulnerabilities have different technical causes.
1. CVE-2026-109618: Out-of-memory handling and memory corruption
PHP sometimes encounters an out-of-memory condition while processing a request. An application or request may exceed a configured memory limit, or a memory allocation may otherwise fail.
The vulnerability arises when PHP encounters this condition while internal request data is only partially initialised. Subsequent cleanup can treat that incomplete data as if it were valid.
This creates an opportunity for memory corruption, which researchers demonstrated could be exploited to achieve remote code execution in vulnerable configurations.
The important detail is that the problem occurs inside PHP's request handling. It is not necessarily caused by an application calling a dangerous function or making an obvious programming mistake.
2. CVE-2026-109619: Stale internal state after memory has been freed
The second vulnerability involves internal state that can retain references to request memory after that memory has been released.
If a later request handled by the same worker uses that stale state before it has been correctly reset, the result can be unsafe memory access and potentially exploitable memory corruption.
This is particularly relevant to long-running server processes, where a worker may handle multiple requests during its lifetime.
Both issues concern the integrity of PHP's internal state. The PHP security team has released fixes for both, and the official advisory provides the authoritative technical details.
Technical references:
Why this is more serious than an ordinary application vulnerability
Many web vulnerabilities depend on a particular application feature, an exposed endpoint, a missing permission check or an unsafe way of processing user input.
PHP2Shell is different because the affected behaviour is part of the runtime responsible for processing requests in the first place.
Security researchers at Wiz reported successful demonstrations against WordPress, Drupal and Joomla deployments. These examples illustrate the potential impact; they do not mean that each platform independently introduced the underlying flaw.
The distinction is important for anyone managing a content management system. Updating WordPress core, changing a theme or removing a vulnerable plugin will not, by itself, repair a vulnerable PHP runtime.
The PHP team specifically identifies Apache's mod_php integration as the highest-risk deployment scenario because a demonstrated attack can be triggered before application code executes.
Other PHP-serving environments are also affected, including PHP-FPM, php-cgi, FrankenPHP and LiteSpeed.
The precise exposure depends on the runtime build, deployment configuration and relevant attack path. It would be incorrect to assume that every server can be exploited in exactly the same way.
Source: PHP's official security advisory.
Which PHP versions are affected?
The PHP team has published security releases for the supported 8.x branches listed below.
PHP branch |
Fixed 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 |
Installations running earlier releases within these branches should be assessed and updated.
PHP 8.1 and older versions are also affected. The upstream PHP project no longer provides ordinary security updates for these older branches, although certain operating-system distributions and long-term-support vendors may supply backported fixes. PHP has also published limited source-level backports for PHP 7.4, 8.0 and 8.1.
If an older PHP version is still required by a legacy application, check with the relevant vendor whether a verified fix is available. Do not assume that an old version is protected simply because its version number differs from those in the table.
PHP 8.2 also reaches its upstream end of life on 31 December 2026. Although version 8.2.35 addresses these vulnerabilities, organisations should plan their migration to a maintained branch rather than treating this patch as a long-term support strategy.
Sources: PHP 2026 security archive and Canadian Centre for Cyber Security advisory.
What developers and website owners should do now
The first task is to establish what is actually running in production. It is easy to check the PHP version on a development machine and assume the production server uses the same release. In practice, shared hosting, containers, control panels, background workers and separate application environments can all run different PHP builds.
1. Identify every PHP installation
Start by inventorying PHP across your infrastructure.
For a server or container where you have shell access, run:
php -v
This reports the version of the PHP CLI binary available in that shell. It does not prove that the PHP version serving web requests is identical.
For a fuller assessment:
Check the PHP version configured for each production website in your hosting control panel.
Inspect the PHP-FPM pools, Apache modules or other PHP-serving processes in use.
Identify PHP runtimes bundled inside Docker images, appliances and third-party applications.
Verify the version actually deployed after any update.
Ask your hosting provider to confirm the security status of the web-serving runtime if you do not administer the server yourself.
Remember that a patched CLI binary does not automatically mean the web server or every application container has been patched.
2. Apply the appropriate security update
Upgrade to a fixed release supported by your deployment or install the corresponding security package supplied by your operating-system or hosting vendor.
For a project using containers, updating a local PHP installation is not enough. Update the image or base image used in production, rebuild it, deploy the replacement and verify the running container.
For example, a project that explicitly pins an official PHP image should review its image reference rather than assuming that a rebuild will automatically retrieve a patched release.
# Example only: use a verified, patched image reference
FROM php:8.4.27-apache
This is an illustrative version pin, not a complete production deployment specification. A real deployment should use the appropriate image variant, confirm the vendor's available security fixes and preferably pin the verified image digest in accordance with its release process.
For operating-system packages, follow the distribution's security advisory. Package versions can differ from upstream PHP version strings when a vendor backports a fix.
After deployment, verify the actual web-serving runtime and restart or replace the relevant services and workers as required by the vendor's instructions.
3. Treat temporary mitigations as temporary
The PHP team has documented measures that can reduce exposure to particular attack paths when an immediate update is not possible.
These include carefully configured request-size limits, changes to certain PHP settings and disabling specific vulnerable code paths where applicable.
However, these measures are not a substitute for installing the security fix. Some controls address only a particular exploitation path, and others depend on the server's configuration and the application.
Do not copy configuration changes blindly into production. For example, memory-limit changes can affect application resource consumption, while request-size restrictions may break legitimate uploads or other functionality. Test any emergency configuration change and ensure that it is applied at the correct server or worker level.
The complete guidance is maintained in the official PHP security advisory.
If an internet-facing system cannot be patched or adequately mitigated, consider isolating it from public access until the risk is addressed.
4. Investigate possible compromise
Installing a patch closes the known vulnerability, but it does not undo an attack that may already have occurred.
Security teams should review relevant logs and monitoring data for suspicious activity, including:
Unexpected processes or outbound network connections associated with PHP or web-server services.
Unexplained changes to application files, scheduled tasks or system configuration.
New accounts, unexpected authentication activity or altered permissions.
Unusual requests, application errors or worker crashes around the period of exposure.
Unfamiliar files that could indicate a web shell or other persistence mechanism.
No single log entry proves that an attack succeeded, and the absence of obvious indicators does not guarantee that a server is clean.
If there is credible evidence of compromise, follow an incident-response process. Preserve relevant evidence, contain the affected system, investigate the scope of access and restore from a trusted source where necessary. Do not treat a routine patch installation as a complete incident response.
The UK National Cyber Security Centre's guidance recommends checking for signs of compromise where systems could not be updated or disabled immediately.
5. Include third-party software in the review
A website owner may not manage the PHP installation directly. Managed hosting, third-party appliances and packaged applications can all introduce dependencies that are invisible from the application's own source repository.
Ask the responsible vendor to confirm:
Whether the product includes an affected PHP runtime.
Which product update contains the relevant fix.
Whether the runtime update requires a service restart or replacement of a container or appliance.
Whether additional action is needed for older or unsupported product versions.
Do not assume that a vendor has already patched its product merely because the upstream PHP release is available.
What if the website uses WordPress, Drupal or Joomla?
The same principle applies to all three platforms: check the PHP runtime as well as the application.
Updating a CMS and its extensions remains important for general security, but those updates are separate from patching the underlying PHP engine.
For a typical CMS deployment, the immediate checklist is:
Determine which PHP version and serving configuration the production site uses.
Confirm that the host or server vendor has applied the appropriate fix.
Verify the runtime after the update.
Review the CMS, extensions and other bundled components for any separate security advisories.
Investigate suspicious activity if the site was exposed while vulnerable.
If the website is on shared hosting, contact the provider rather than assuming that changing a PHP version selector in the control panel will necessarily update every relevant component. Request confirmation that the web-serving runtime is patched.
A lesson for software teams: runtime security is part of application security
PHP2Shell illustrates a point that is easy to overlook during routine development: the security of an application depends on more than the code maintained in its repository.
An application can have a clean dependency audit and a disciplined review process while relying on a runtime that contains a critical vulnerability. The same principle applies to operating-system packages, container images, web servers, database engines and other infrastructure components.
A practical security process should therefore include a maintained inventory of production runtimes, an update process for security releases, a way to verify deployed versions and an incident-response plan for systems that may have been exposed.
For teams using automated deployment pipelines, this is an opportunity to make runtime updates a defined part of the release process rather than an occasional manual task. Image versions should be reviewed, rebuilds should use verified patched bases, and deployment checks should confirm what is actually running.
Security is not only about preventing mistakes in application code. It also means maintaining the components that execute that code.
Final thoughts
The PHP2Shell vulnerabilities deserve immediate attention because they affect PHP's core request-processing behaviour and can, under vulnerable conditions, allow unauthenticated remote code execution.
The PHP team has released fixes, and the recommended response is clear: identify affected installations, update the runtime or its vendor-provided security package, verify the deployed fix and investigate signs of compromise where appropriate.
Do not assume that a CMS update alone is sufficient, that a patched command-line binary proves the web server is patched, or that temporary mitigations eliminate the risk.
For website owners who depend on a hosting provider, the next step is straightforward: ask for confirmation that the PHP runtime serving your site has been updated against CVE-2026-109618 and CVE-2026-109619.
For developers and infrastructure teams, the more durable lesson is to make runtime inventory, security patching and post-deployment verification routine parts of operating production software.
Top comments (0)