PHP released an emergency update on October 21 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Four days before disclosure, Amazon Threat Intelligence had already recorded an attempt to exploit them.
Updating PHP addresses the vulnerabilities, but it doesn’t explain how much damage an attacker could do if they exploited a server.
What happened
The flaws are known informally as PHP2Shell, a name used in public reporting rather than by PHP itself. The PHP security team gave advance notice on October 20 of a release scheduled for October 21 at 14:00 UTC, after information about the flaws leaked online.
Both vulnerabilities are rated 9.2 on CVSS v4.0, and the security firm watchTowr reported reproducing at least one of them before the fix. PHP’s announcement describes both as remote code execution (RCE) vulnerabilities, which means an attacker can run their own code on the server, and they can be exploited without logging in.
Amazon says the flaws are now being exploited broadly in the wild, though it is unclear whether the attempts it recorded would have succeeded.
How the flaws work
In the first, CVE-2026-109618, a request can run out of memory when PHP has only partially set up its internal data. PHP then stops the request early, and the cleanup that follows treats that incomplete data as if it were valid.
In the second, CVE-2026-109619, internal state from one request can still point to memory that has already been freed, which is known as a use-after-free. A later request handled by the same worker may use it. PHP says this can lead to code running with the privileges of the web worker, which is the process that handles the request.
Who is exposed
The vulnerabilities affect PHP itself, putting applications running on vulnerable PHP versions at risk. Patchstack names common platforms such as WordPress and Magento.
The fixed releases are:
-
8.2.35
-
8.3.36
-
8.4.27
-
8.5.12
Earlier versions in these branches are affected. PHP says every installation serving web requests is at risk, including those running PHP-FPM, php-cgi, FrankenPHP, or LiteSpeed. The risk is highest with Apache and mod_php, where an unauthenticated request can trigger an attack before any application code runs.
VulnCheck counted about 2.6 million internet-facing hosts running PHP, with over 700,000 on PHP 7.3 or older and about 400,000 on PHP 7.4 to 8.1. PHP no longer provides regular security updates for these older versions.
The PHP security team did publish minimal source backports for 7.4, 8.0, and 8.1, and some operating system vendors and long-term support providers may supply their own backported fixes.
PHP’s advisories list fixes for the 8.2 to 8.5 branches only. Researchers report that the vulnerable code goes back to PHP 5.4, according to Tenable’s summary of findings, though PHP has not published a range for older versions.
Patch first
What to do depends on where PHP runs and which version is installed.
-
PHP 8.2 to 8.5: Update to the fixed release for the branch in use.
-
Containers and CI images: Rebuild them from updated base images and pin the fixed tag, such as
php:8.2.35-fpm, since floating tags can lag behind a release. -
PHP 8.1 or older: Check with the operating system vendor or support provider for a backported fix, or build from one of the source backports the PHP security team published for 7.4, 8.0, and 8.1. If neither is available, upgrade to a supported PHP branch and install its fixed release.
PHP says updating is the only complete fix. For systems that cannot be updated right away, PHP’s announcement lists temporary measures for each flaw, such as turning off session upload progress for CVE-2026-109619 and setting memory_limit to -1 for CVE-2026-109618, which PHP pairs with limits on request size.
These block only the paths known so far, so they do not make a vulnerable server safe. PHP says they should be set where applications cannot override them, such as the server or PHP configuration, and not through ini_set() or .user.ini, and that workers must be restarted afterward.
Amazon recommends checking web server logs dating back to October 17 and looking for unexpected processes or file changes on application servers, as attackers were attempting to exploit the vulnerabilities before the fix was released.
Reducing what an attacker can access or change
Patching addresses these two vulnerabilities. What an attacker can access or change after executing code depends on how applications are built and deployed, and developers make many of those decisions. The measures below do not stop code from running, but they limit what it can reach.
-
Process permissions: PHP that runs without elevated privileges and without permission to write to application code limits what injected code can change. Injected code runs with the web worker’s privileges, so those privileges determine the potential damage.
-
Upload and temporary directories: Directories that do not allow execution stop uploaded files from running directly, and write access can be removed from directories that do not need it.
-
Database accounts and secrets: An application account with only the permissions it needs, and secrets limited to that application, keep a compromise from spreading to other data and systems.
-
Outbound connections: An application that can only reach the services it needs makes it harder for an attacker to download tools or open a remote shell.
-
Fatal errors and unused features: PHP’s advisory suggests keeping session upload progress off, even after patching, if an application does not need it. It also advises fixing fatal errors and execution timeouts on paths an attacker can reach, because these can leave stale state behind. PHP notes that hiding error messages does not help.
In general, PHP-level restrictions such as disable_functions and open_basedir may not be reliable once memory is corrupted, since they run in the same process. Controls enforced outside PHP, such as operating system permissions and network rules, are more dependable.
In the RCE guide, learn what remote code execution is and how to reduce the risk.
Practical training and threat modeling
Secure coding and configuration are easier to learn when developers can see how vulnerabilities work in a realistic environment.
SecureFlag’s hands-on labs give developers practical experience identifying and fixing vulnerabilities, including labs on PHP and RCE. ThreatCanvas generates threat models with recommended controls for each threat, giving teams a good starting point.
These capabilities reinforce secure coding and configuration practices that can limit the impact of a future compromise.
