Skip to content
Critical PHP security flaws: check whether your site is protected.Read the advisoryGet in touch
Dazvix
Journal
4 min read

PHP2Shell: what website owners should do about the critical PHP flaws

The PHP team has released security updates for two critical flaws. Here is how to check the PHP runtime serving your site, update it safely, and understand the limits of temporary mitigations.

Share this article

Two vulnerabilities in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619 and referred to together as PHP2Shell, can allow unauthenticated remote code execution in affected web deployments. The PHP team rates both critical and urges users to update. This is a server runtime issue: updating WordPress, a plugin, or a theme does not patch PHP.

What is PHP2Shell?

PHP is the runtime that executes code for WordPress, WooCommerce, and many other web applications. CVE-2026-109618 concerns request handling after an out-of-memory condition leaves internal data only partly initialized. CVE-2026-109619 concerns stale internal state that can point to memory already freed. In certain circumstances, a remote attacker can trigger these flaws through web requests without logging in.

The impact depends on the deployment and the permissions of the PHP worker. Successful code execution can expose data the worker can access, allow changes to application files, or disrupt service. A vulnerable version does not prove that a site has been compromised.

Who may be affected?

PHP’s advisory covers installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP team identifies mod_php as the highest-risk setup, with a demonstrated attack that can trigger before application code runs. Configuration and application behavior affect exposure in other setups, so do not assume that PHP-FPM or a managed host is automatically safe.

A WordPress site can have current core files, plugins, and themes while its server still runs an affected PHP build. Check the runtime itself. Also remember that the command php -v may report a command-line version different from the one handling website traffic.

Which versions contain the fixes?

The PHP project released these patched versions on October 21, 2026:

  • PHP 8.5: 8.5.12
  • PHP 8.4: 8.4.27
  • PHP 8.3: 8.3.36
  • PHP 8.2: 8.2.35

Linux distributions and long-term support vendors may ship patched packages with their own version numbering. Check the vendor’s security notice instead of relying only on the upstream version string. PHP 8.1 and older no longer receive regular updates from the PHP project; some vendors provide backported fixes, and PHP has published minimal source backports for 7.4, 8.0, and 8.1. Confirm your specific build with its supplier, or plan a move to a supported branch.

How to respond

  1. 01Identify the PHP build used by production web requests through your hosting panel, PHP-FPM or web-server configuration, or hosting provider.
  2. 02Update to a patched release or a vendor build confirmed to include the fixes. For older branches, verify the exact backport status with the distribution or hosting vendor.
  3. 03Restart PHP-FPM or other persistent PHP workers as required by your deployment, so the patched runtime is actually serving requests.
  4. 04Test essential flows such as login, forms, checkout, integrations, scheduled jobs, and background workers. Use staging where available, but coordinate the security update promptly.
  5. 05Review server and application logs for suspicious activity if the site was exposed while running an affected build. Check for unexpected accounts, files, code changes, scheduled tasks, and outbound connections.

If you cannot update immediately

PHP lists temporary measures that can reduce exposure to specific attack paths, but says updating is the complete solution. The measures are configuration-dependent and should be applied by a qualified administrator. They include limiting request sizes and multipart input for the out-of-memory path, and disabling session upload progress before request handling for the stale-state path. Do not treat a firewall rule, a WordPress security plugin, or one of these workarounds as proof that an unpatched installation is safe.

On October 23, PHP published a further informational advisory about a rare configuration and application-code combination involving session upload progress and changing the session serializer at runtime. If you already disabled session.upload_progress.enabled as recommended, PHP says to keep it disabled. Otherwise, check the official advisory and ask your PHP administrator to assess whether the unusual conditions apply. The core security update remains the priority.

The practical takeaway

PHP2Shell is a reminder that application security also depends on the server software underneath it. Know which runtime serves your website, keep it supported, and have a clear process for urgent updates. If the host manages PHP for you, ask for confirmation of the patched build and the time its workers were restarted.

Sources