TLTR
Two critical vulnerabilities affecting the PHP programming language potentially allow an unauthenticated remote attacker to execute code on an exposed server. Patches are available: organizations must identify their PHP applications, apply the patched versions and restart the affected services without delay.
PHP2Shell: two critical vulnerabilities allow remote code execution
PHP has just released patches for two critical vulnerabilities affecting the core programming language: CVE-2026-109618 and CVE-2026-109619. Dubbed PHP2Shell by several researchers, these vulnerabilities can allow remote code execution without authentication, especially on PHP servers exposed to the Internet.
The corrected versions are available now. It is recommended that all users update their installations immediately: the risk is considered to be particularly high for Apache mod_php environments, where exploitation before application code execution has been demonstrated by researchers.
Consult the official PHP notice
What are the corrected versions?
The following versions include security patches:
PHP Branch | Corrected 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 |
Installations in PHP 8.1 and earlier are no longer supported by the standard PHP project security support. Patches may however be proposed by some publishers, Linux distributions or long-term support providers. Otherwise, a migration to a supported branch must be scheduled quickly.
PHP 8.2 remains fixed in this release, but this branch is scheduled to reach end of life on December 31, 2026. An upgrade to a more recent version is therefore expected.
Security notices issued by PHP assign these vulnerabilities a CVSS v4.0 score of 9.2, corresponding to a critical criticality level.
Advisory CVE-2026-109618 · Advisory CVE-2026-109619
Why is this alert so important?
PHP is used by a very large number of websites, business portals and applications exposed on the Internet. The risk is not just for a particular framework or CMS: any application running on a vulnerable PHP engine can be exposed. In particular, WordPress, Drupal and Joomla environments have been used in demonstration scenarios. Thus, updating the CMS is not necessarily enough: it is indeed the underlying PHP application that must be identified and corrected.
According to the CERT Orange Cyberdefense report provided as part of this analysis, exploitation attempts were observed after the technical details were disclosed. The availability of public proofs of concept and the presence of several million exposed PHP services can accelerate attack campaigns in the coming days.
Potential consequences include:
- executing commands with web process privileges;
- installation of malware or webshells;
- access to secrets in memory, such as passwords, tokens or API keys;
- modifying the content of applications;
- access to the data processed by the server;
- a bounce to other components of the information system.
What actions should be taken immediately?
Affected organizations must treat this alert as a priority remediation operation.
1. Identify all exposed PHP installations
Inventory should cover internet servers, cloud environments, containers, hosting platforms and facilities used by business applications. It is important to identify:
- the exact version of PHP;
- the execution mode used: mod_php, PHP-FPM, CGI, FrankenPHP or LiteSpeed;
- Apache servers and applications accessible from the Internet;
- end-of-life PHP branches;
- any installations not referenced in the central inventory.
2. Update to a corrected version
PHP recommends migrating to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, depending on the compatibility of the application and distribution used.
After the update, it is also necessary to restart the components that load the PHP engine, notably:
- Apache;
- PHP-FPM;
- persistent PHP workers;
- the containers or services concerned.
3. Process older versions
For PHP 8.1 and older branches, check the availability of a patch with the Linux distribution, publisher or support provider. If no reliable patches are available, migration to a supported version must be accelerated.
4. Temporarily strengthen controls
PHP documents several exposure reduction measures for organizations that cannot update immediately.
These measures are temporary and incomplete. According to PHP, the update constitutes the only complete remediation. They must therefore not delay the installation of the corrected versions.
5. Look for signs of exploitation
Security teams must examine web logs, Apache, PHP-FPM, detection systems, and process-related events to identify:
- unusually large or repeated requests;
- unusual fatal errors;
- frequent restarts of workers;
- unexpected file creations or modifications;
- child processes launched by web services;
- unusual outbound connections from PHP servers;
- suspicious access to configuration files or secrets.
The absence of a visible alert does not rule out a compromise. Investigations must consider log retention and available visibility on affected servers.
The role of threat intelligence in facing this vulnerability
In this type of crisis, the speed of response depends as much on the availability of the patch as on the ability to quickly identify the affected assets, exploitation attempts and possible compromise signals.
CERT Orange Cyberdefense can support organizations in:
- their exposure assessment;
- prioritizing vulnerable assets;
- qualification of PHP versions and configurations;
- proactive search for signs of compromise;
- monitoring of exploitation campaigns;
- coordination between infrastructure, application and security teams;
- the implementation of detection and response measures.
Need help assessing your exposure to PHP? CERT Orange Cyberdefense can help you identify affected environments, prioritize remediation actions and look for possible signs of compromise. Contact our teams: cert-contact.ocd@orange.com
Q&A
Are these vulnerabilities just for WordPress?
No. They affect the PHP engine itself. WordPress, Drupal, Joomla and other applications may be exposed when running on a vulnerable version of PHP.
Is updating my CMS enough?
No. You need to update the PHP runtime and restart the affected services. The CMS update does not automatically fix the installed PHP engine on the server.
Is PHP-FPM affected?
PHP states that all PHP installations that serve web queries must be evaluated, including PHP-FPM. The level of exposure depends in particular on the configuration, the front-end server and the execution paths used.
Is there a sufficient temporary measure?
No. PHP specifies that exposure reduction measures do not constitute a complete remediation. Installing a corrected version remains the only definitive solution.
Are PHP 8.2 and earlier supported?
PHP 8.2 still receives the patch in version 8.2.35, but this branch is scheduled to reach end of life on December 31, 2026. Versions 8.1 and earlier are no longer covered by standard PHP security support.