Critical · CVSS 9.2 CVE-2026-109618 ↗ CVE-2026-109619 ↗

Am I vulnerable to PHP2Shell?

PHP2Shell lets an unauthenticated attacker corrupt PHP worker memory, read sensitive memory, or run code on affected servers. Enter a domain to check the PHP version it reports.

Sends one passive GET / to the site and reads its X-Powered-By header. Nothing is exploited and nothing is stored. Only check sites you own or are authorized to assess.

Try a demo: vulnerable server · patched server

What is PHP2Shell?

PHP2Shell is the name researchers gave to two critical vulnerabilities in the PHP runtime itself, CVE-2026-109618 and CVE-2026-109619. They are memory-safety flaws (use-after-free, CWE-416) in how PHP handles web requests. They are not bugs in any single application, so any site running an affected PHP version can be exposed, whatever framework or CMS it uses.

According to the PHP project, all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Risk is highest for mod_php, where an unauthenticated request can trigger the attack before any application code runs.

SeverityCritical · CVSS 9.2
WeaknessUse-after-free (CWE-416)
Attack vectorNetwork, no authentication
AffectedPHP 7.4 – 8.5 before the fixed releases

Why it matters

An attacker needs no account and no user interaction. Sending crafted requests to a vulnerable server can lead to:

01

Remote code execution

Commands run as the web server's PHP worker account. That gives the attacker a foothold to steal data, plant web shells or move further into the network.

02

Memory disclosure

The attacker can read sensitive worker memory, which can include session data, credentials, API keys and other users' requests.

03

Memory corruption

Corrupting process memory can crash workers and disrupt the service, even when code execution isn't achieved.

There is no complete workaround. The PHP project says updating is the only safe choice. PHP 8.1 and older are end-of-life and get no official release. The PHP security team published source-code backports for 7.4, 8.0 and 8.1, and some OS and LTS vendors ship backported packages.

How to check and fix

  1. 1

    Check

    Enter a domain above. The checker sends one passive request to the site's home page and reads the PHP version it reports in the X-Powered-By header. It then compares that version with the fixed releases.

    Nothing is exploited, nothing is probed beyond that one request, and no domains or results are stored. Only anonymous daily totals per verdict are kept, and page visits are counted without cookies.

  2. 2

    Confirm

    A remote version check has limits, so confirm the result on the server itself:

    • Distro packages may already be patched. Debian, Ubuntu, RHEL and similar vendors backport fixes without changing the version number. Check your vendor's advisory.
    • A hidden version is not proof of safety. Many servers turn off expose_php.
    • Only the home page is checked. PHP behind another path or host won't be seen.

    On the server

    php -v

    From a terminal

    curl -sI https://your-site.com/ | grep -i x-powered-by
  3. 3

    Fix

    Upgrade to the fixed release for your branch, or later:

    BranchVulnerableUpgrade to
    8.58.5.0 – 8.5.118.5.12+
    8.48.4.0 – 8.4.268.4.27+
    8.38.3.0 – 8.3.358.3.36+
    8.28.2.0 – 8.2.348.2.35+
    8.1, 8.0, 7.4All releasesEnd-of-life, with no official release. Upgrade to a supported branch, use your OS or LTS vendor's backported package, or apply PHP's source backport.
    7.3 and olderNot covered by the advisoryEnd-of-life with no security fixes of any kind. Upgrade to a supported branch.
    8.6 (pre-release)Builds before 8.6.0RC48.6.0RC4+ (not for production)

    Development, alpha, beta and RC builds of a fixed version predate the fix and count as vulnerable. Partial mitigations exist (see the PHP announcement), but they do not make an installation safe.