Datahorses

PHP2Shell: which PHP versions are fixed and how to check yours

By · · 4 min read

In October 2026 the PHP project fixed 2 critical vulnerabilities that can let an attacker run code on a server without logging in. CISA refers to them as "PHP2Shell". They are tracked as CVE-2026-109618 and CVE-2026-109619, and both are rated 9.2 on CVSS v4.0. If any part of your company's online service runs on PHP, the action is simple: make sure it runs PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer, or a vendor build that contains the fix.

This article explains what was fixed, which versions contain the fix, how to find out which version your server reports, and what to ask the people who run your hosting. You can also check which PHP version your website reports in a few seconds.

What PHP2Shell is

The PHP security advisory of October 21, 2026 describes 2 flaws in how PHP handles internal request data:

  • CVE-2026-109618, out-of-memory corruption. When PHP runs out of memory, it can be interrupted while internal request data is only partly initialized, and the cleanup may then treat invalid data as valid.
  • CVE-2026-109619, stale request state. Internal state that belongs to one request can survive after its memory has been freed, and a later request handled by the same worker may use it.

Both can allow unauthenticated remote code execution. According to the advisory, every PHP installation that serves web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers mod_php the highest risk, because a request can trigger the attack before any application code runs. That also means the application on top (WordPress, an online shop, a custom portal) does not protect you by itself; the fix is in PHP.

Fixed versions and timeline

PHP 8.1 and older no longer receive updates from the PHP project (see supported versions). The advisory notes that some Linux distributions and long-term support vendors backport fixes, and that the PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for those who build PHP themselves. If your service runs one of these branches, ask your vendor whether the fix is included, and plan a move to a supported branch.

How to find out which PHP version you run

The definitive answer comes from the server itself, not from the outside:

  • Ask whoever runs the service (your hosting provider, agency or IT team) for the exact PHP version and whether it includes the fixes from October 21.
  • If you have shell access, run php -v. The web server may use a different PHP binary than the command line, so also check the version in your hosting panel or in the PHP-FPM pool.
  • Package managers show vendor builds: on Debian and Ubuntu dpkg -l | grep php, on RHEL and similar systems rpm -qa | grep php. Compare the package version with your vendor's security notice, since vendors often keep the original version number and add the fix.

From the outside, some servers announce their version in HTTP response headers:

X-Powered-By: PHP/8.3.12
Server: Apache/2.4.62 (Debian)

You can see your own headers with curl -sI https://www.example.com/. Our PHP2Shell check reads the same 2 headers, X-Powered-By and Server, and compares the number with the fixed versions.

What the header can and cannot tell you

Read the header carefully, in both directions:

  • An old number does not prove the server is vulnerable. Many hosting providers apply the fix at the system level and keep the original version string.
  • A current number is a good sign, not proof. The header can be changed, or set by a proxy in front of the server.
  • No number means no information. Most servers do not send their PHP version at all. When we measured 8,221 Slovak company domains on October 31, 2026, only 332 of the 8,171 that responded reported a PHP version in their headers (4.1%). For the rest, the header says nothing either way, and the question goes to whoever runs the service.

What to do now

  1. Update PHP to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer, or install your vendor's fixed package. Restart PHP-FPM or the web server so the new version actually runs.
  2. Ask your hosting provider in writing which PHP version runs your service and whether it contains the fixes for CVE-2026-109618 and CVE-2026-109619. Ask the same about staging servers and older projects; see forgotten staging and test servers.
  3. Plan the move off PHP 8.1 and older if a backported fix is not available.
  4. Stop announcing the version. Set expose_php = Off in php.ini to remove X-Powered-By, and limit the Server header (ServerTokens Prod for Apache, server_tokens off for nginx). This fixes nothing by itself, but it stops advertising details to automated scanners. More in HTTP security headers every business website should send.

If you cannot update immediately, the advisory lists temporary measures that reduce specific attack paths, and states clearly that only the update is a complete solution.

How Datahorses helps

We watch your company from the outside every day, the way an attacker would see it, and we do not need access to your systems. When a server starts announcing an outdated software version, the finding comes with exact steps for whoever runs it. See what we guard or request a proposal.

More articles

All articles