PHP security update urged as exploit attempts spread
A PHP security update is urgently needed for two critical vulnerabilities that can let an unauthenticated attacker, meaning someone who has not logged in, run code on an affected web server. The flaws, CVE-2026-109618 and CVE-2026-109619, each have a CVSS v4.0 score of 9.2. CVSS is a standard scale for rating vulnerability severity. Public exploit material is available, and several security companies have reported exploitation attempts.
PHP, the server-side software used to generate many websites and web applications, has released fixed versions for four supported branches: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Administrators of their own servers or virtual private servers (VPSs), which are remotely hosted servers allocated to one customer, should install the appropriate release immediately. Customers using shared or managed hosting should confirm that their provider has deployed either a fixed release or an explicitly patched package.
Both vulnerabilities concern PHP's handling of internal request data, the information received when a browser or other system contacts a website. They are flaws in the PHP runtime, the underlying software that executes PHP code, rather than in WordPress, another content management system, a plugin, a theme or an individual application. Updating those components is still good security practice, but it will not correct these two PHP flaws.
CVE-2026-109618 can arise when PHP runs out of memory while request data is only partly prepared. During cleanup, PHP may treat the incomplete data as valid. That can cause memory corruption, where information held temporarily by a program is damaged or handled incorrectly, and may ultimately permit remote code execution. Remote code execution, commonly shortened to RCE, means an attacker can make the server run commands from another location.
CVE-2026-109619 concerns stale internal state. A PHP worker, a running process that handles web requests, may retain a reference to request data after the memory behind it has been released. A later request processed by that same worker can reach the old information before PHP resets it. The result may be information disclosure or remote code execution.
Sucuri's advisory says every PHP installation serving web requests should be treated as potentially exposed. That includes PHP-FPM, or FastCGI Process Manager, which operates pools of PHP workers, as well as Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers mod_php the highest-risk setup because an unauthenticated request can trigger a demonstrated exploit before the website's own application code begins running.
Public proof-of-concept code, which demonstrates how a vulnerability can be exploited, circulated before the official fixes. Hadrian reported seeing PHP2Shell exploited at scale and said most observed activity used PHP's session upload-progress path. It also warned that additional routes were likely to emerge. WatchTowr, Patchstack, Cloudflare and Vega separately reported malicious activity or attempts connected with the vulnerabilities. An attempted exploit does not by itself prove that a server was compromised, but public code and the volume of reported activity increase the urgency of patching.
After installing PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 through the operating system, hosting control panel, package provider or established deployment process, administrators must restart or reload the relevant PHP workers and services. They should then verify the version actually serving the live website. The version returned by the command-line instruction php -v can differ from the version connected to the web server. Logins, checkout flows, forms, uploads, scheduled tasks, application programming interfaces (APIs) and administration pages should all be tested after the change.
Shared-hosting customers can look for a PHP version selector in their control panel. If no fixed version appears, they should ask the provider whether it has installed a vendor-backported fix, meaning the security repair has been added to an older software branch, or when a fixed release will become available. A displayed version number alone is not enough because operating-system and long-term-support vendors sometimes add security repairs without changing the branch number.
PHP 8.1 and older releases are outside the project's normal support cycle and will not receive standard upstream point releases. Because of the severity of these flaws, however, PHP has issued emergency source backports for PHP 7.4, PHP 8.0 and PHP 8.1. Linux distributions and long-term-support vendors may also supply patched packages. Operators must upgrade to a supported branch, install a package that explicitly addresses both CVE-2026-109618 and CVE-2026-109619, or apply the relevant emergency source backport. Those emergency repairs do not restore long-term support, so migration to a supported PHP branch remains the safer long-term course.
Sucuri states that its existing web application firewall (WAF) rules were already rejecting some malicious request patterns associated with the flaws and that it has added more specific virtual patching rules for known PHP2Shell paths. A WAF is a filtering service placed in front of a website to inspect incoming requests. Virtual patching means blocking recognised exploit traffic before it reaches vulnerable software, but it does not remove the defect itself and cannot replace the PHP security update.
Firewall filtering also fails if an attacker can contact the origin server, the machine that actually hosts the website, without passing through the filtering service. Operators should restrict direct IPv4 and IPv6 access, permit web traffic only from approved firewall addresses, and check that old DNS records or alternate hostnames do not expose the origin. Staging, development, test and backup environments should be protected or access-restricted, while unprotected subdomains and alternate ports must not provide another route to the same application. Old containers, server images and autoscaling templates should also be checked so that they do not continue deploying vulnerable PHP builds.
If immediate patching is impossible, PHP says updating remains the only complete solution. Because much observed activity has targeted session upload progress, administrators can temporarily set session.upload_progress.enabled = Off in php.ini, an FPM pool or another server-level configuration that applies before request parsing, then restart every affected worker. This measure blocks only confirmed session-related routes for CVE-2026-109619. It does not cover every path for that flaw, does nothing against CVE-2026-109618 and may affect applications that show PHP upload progress. PHP provides further temporary advice for the out-of-memory route, but all such measures should be treated as short-lived stopgaps.