PHP Releases Emergency Fixes for Critical PHP2Shell Flaws as Exploitation Attempts Are Detected

The PHP project released PHP2Shell emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The flaws may enable unauthenticated remote code execution (RCE) on web installations. AWS said its MadPot telemetry detected an exploitation attempt as early as October 17, before the fixes were publicly disclosed.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Administrators of publicly accessible PHP services should address the update urgently and check for possible signs of activity dating back at least to October 17, 2026.

PHP2Shell emergency fixes for PHP web modes

According to the PHP project, both flaws affect installations that process web requests. The affected modes are PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. This is therefore not an issue tied to a specific content management system, framework, or application, but vulnerabilities in the PHP runtime itself.

The practical impact is particularly significant for web services exposed to the internet. Application authentication may not stop an attack if the malicious request is processed before application code is executed. PHP describes updating as the only complete solution.

The following fixed versions are available for supported branches:

• PHP 8.5.12,
• PHP 8.4.27,
• PHP 8.3.36,
• PHP 8.2.35.

Older versions have limited support

Standard upstream updates are no longer released for PHP 8.1 and older versions. However, the project provided minimal source backports for the 7.4, 8.0, and 8.1 branches. Operators obtaining PHP through a Linux distribution, hosting provider, or another supplier should verify the availability of a fixed package directly with their provider.

This check is also important for PHP embedded in appliance products. The availability of a fix and the timing of its deployment may vary among suppliers. The existence of a source backport alone does not mean that an updated package is already available for a specific environment.

AWS records attempts before and after disclosure

In its security blog, AWS said MadPot recorded an exploitation attempt on October 17 and additional attempts on October 21. Based on differences in the payloads used and anonymization infrastructure, AWS attributes the activity to multiple actors, but the technical analysis is still ongoing.

Based on the available information, it has not yet been independently established that the recorded attempts resulted in the compromise of production systems. The presence of attempts nevertheless means administrators should not wait to deploy the fixes for a possible exploit to be published or for more information about the campaigns.

What administrators should do

The priority is to deploy a fixed PHP version or a supplier package containing the fix. After updating, it is advisable to verify that the web server and PHP runtime are actually using the new version, especially in environments with multiple installations or separate PHP-FPM pools.

Operators should also review relevant web server, PHP-FPM, and security-tool logs dating back to October 17. AWS says temporary configurations and AWS WAF rules may help reduce exposure, but they do not replace fixing PHP.

In the coming days, it will be important to monitor announcements from Linux distributions, hosting companies, and appliance manufacturers. Further technical indicators of compromise, detection rules, and independent information about possible successful attacks may also emerge.

Verified and updated: 10/22/2026 06:19