Skip to main content

PHP version checker

Enter a website address to see which PHP version its server announces and whether that version is below the releases that fixed the PHP2Shell flaws. The check is passive: one ordinary page request, the response headers and the start of the page are read, and no exploit payload is ever sent.

What the checker reads

The X-Powered-By and Server headers for a PHP/x.y.z string, and when there is none, cookie names, generator tags and page markers that still show the site runs PHP.

Find out more

What each verdict means

Six outcomes: vulnerable, end of life, possibly patched by the distribution, version hidden, fixed, and no PHP found.

Find out more

A check shows today, monitoring shows the change

A deploy, a server move or an image rollback can bring an old PHP back behind the same address. An HTTP monitor with a header rule tells you when that happens.

Find out more

How to fix PHP2Shell

Update PHP to 8.5.12, 8.4.27, 8.3.36, 8.2.35 or newer, or to a distribution package that carries the fix, then restart PHP-FPM, Apache and any long-running PHP workers.

HostTracker is not affiliated with the PHP project or any vendor named on this page.

A one-time check only tells you about today See website monitoring

Key takeaways

  • This tool sends one ordinary GET request to a website, reads the PHP version it announces in the X-Powered-By or Server header, and compares it with the releases that fixed the PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619.
  • The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, published on 21 October 2026; branches older than 8.2 are end of life and get no official release.
  • The verdict is one of six: vulnerable, end of life, possibly patched by the distribution, version hidden, fixed, or no PHP found, shown with the headers, cookie names and page markers behind it.
  • It is passive: it sends no exploit payload and no multipart body, it reads the response headers and the first 256 KB of an HTML page, and a result is kept for about 5 minutes.
  • A hidden version is not a safe version, and a distribution package can carry the fix under an old number; the tool is free and needs no login.

Frequently asked questions.

PHP2Shell is the nickname for two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619, fixed in the releases published on 21 October 2026. The first is memory corruption that can be triggered when PHP runs out of memory while handling a crafted multipart request, such as a form or file upload, and it can lead to remote code execution without logging in. The second is stale global state left behind between requests; it can also lead to code execution, and it can leak memory from other requests, such as passwords, tokens, API keys and certificates, even when no code runs. Both score 9.2 on the CVSS v4 scale. Amazon Threat Intelligence reports that they are exploited in the wild, and CISA added both to its Known Exploited Vulnerabilities (KEV) catalog on 26 October 2026. Details: the PHP changelog, the CISA alert and Tenable's FAQ.
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and anything newer on the same branch. A site on 8.3.35 is exposed, a site on 8.3.36 is not. Branches older than 8.2 are end of life: they get no official releases, so there is no official fixed number for them and the answer is to move to a supported branch. Some Linux distributions fix older numbers inside their own packages, which is why the checker has a separate "possibly patched" verdict.
Then the server is hiding it, which is common: the PHP setting expose_php = Off removes the X-Powered-By header, and many proxies and hosts strip it too. When other signs of PHP are present, such as a PHPSESSID cookie or WordPress markers in the page, the verdict is "version hidden". That is not the same as safe. A hidden version can be old or new, and this check has no way to tell. Look on the server instead: php -v prints the command-line build, a phpinfo() page shows what the web server runs, and your hosting panel or provider can name the exact version.
Debian, Ubuntu, Red Hat family systems, CloudLinux and similar distributions usually keep a PHP package's upstream number and copy security fixes into it, so a package called 8.3.6-0ubuntu0.24.04.2 can already contain a fix that upstream shipped in 8.3.36. When the version is below the fixed release and its suffix looks like such a package, the checker says "possibly patched" instead of "vulnerable", because the number alone cannot settle it. Confirm on the server with apt changelog php8.3-fpm or dpkg -s php8.3-cli on Debian and Ubuntu, rpm -q --changelog php on Red Hat family systems, or the distribution's security tracker. cPanel's ea-php and CloudLinux's alt-php builds have their own packages; CloudLinux published a note on both CVEs.
An end-of-life branch no longer gets official releases from the PHP project. For PHP2Shell, 8.1 and every older branch got no official fixed release; the PHP security team published source backports only, which you would have to build yourself or get from a vendor that maintains the branch. A site on one of those branches should move to 8.5, 8.4, 8.3 or 8.2. Which branches are still supported is listed on php.net. The checker still says "end of life" for an old branch that carries a distribution suffix: a vendor may have backported the fix, but the branch gets no upstream releases, so confirm the package changelog or plan the move.
Cloudflare has published WAF rules for the known PHP2Shell exploit vectors, and they are available on all plans, including free ones. For traffic that passes through Cloudflare that is a useful stop-gap, not a fix: a rule can miss a variant, traffic that reaches the server another way is not filtered, and PHP itself stays vulnerable until it is updated. That is why the checker adds a note when it sees Cloudflare headers but never changes the verdict. PHP's own position is that no configuration change fully mitigates the flaws and that updating is the only safe step.
PHP's advisory lists two settings that reduce exposure. For CVE-2026-109619, set session.upload_progress.enabled=0 (on PHP 8.5, also fatal_error_backtraces=0). For CVE-2026-109618, set memory_limit=-1 in a way applications cannot override, with the caution that it removes the memory ceiling, so a runaway script can then use all the memory the server has. PHP states that these measures do not make an install safe, and every PHP worker has to be restarted after a change for it to take effect. Keep the update on the calendar: it is the only complete fix. If the delay comes from testing, note that 8.4.27 and 8.5.12 can crash PHP processes in some applications that use SimpleXML (php-src issue 24488, a separate fix that was merged but not yet released as of 26 October 2026), so try the update on a staging copy before a fleet-wide rollout.
The checker sends one GET request of the same kind a browser sends when it loads the page, and it follows up to 5 redirects. It reads the response headers and the first 256 KB of an HTML page. It sends no multipart body, no payload, no login attempt and does no probing, and it never tries to confirm that a site can be exploited. It identifies itself as HostTracker-PhpVersionCheck in the User-Agent header, and the server may log the request like any other visit. Check addresses you own or manage. Private, local and internal addresses are refused.
Add an HTTP monitor for the site and give it a rule on the X-Powered-By response header, so an alert goes out when the header stops showing the version you expect, for example after a server move or an image rollback that brings back an old PHP. HostTracker's HTTP monitor runs from 300+ locations and sends alerts by email, SMS, Slack, Telegram or webhook. The rule works only where the version is announced: a server that hides it gives the monitor nothing to compare. Re-run this checker after you update; a result is cached for about 5 minutes, so wait a few minutes after the restart.

Part of HostTracker's website monitoring software.