PHP2Shell.fyi Check a site

Questions about PHP2Shell

Short answers for site owners. PHP2Shell is two flaws in PHP itself, and a PHP update fixes both.

Last reviewed . Rules of .

The basics

What is PHP2Shell?

Two critical flaws in PHP: CVE-2026-109618 and CVE-2026-109619. An attacker with no account can run code on the server or read data from its memory. PHP released fixes on 21 October 2026 (php.net advisory). The full explainer has more.

Which PHP versions fix it?

PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (php.net advisory). A patched build from your Linux distribution or host also counts, even when it keeps an older number. Of the PHP 8.6 test builds, 8.6.0RC4 has the fix, but it is not for production. See Fixed versions.

I run PHP 7.4, 8.0 or 8.1. Is there a fix?

Not as a release. The PHP project ships no new releases for 8.1 and older. Its security team published minimal source patches for 7.4, 8.0 and 8.1 only, for people who build PHP themselves, and lists none for 7.3 and older. Ask your distribution, host or LTS vendor for a patched build, or move to a supported branch (php.net advisory).

How severe is it?

The PHP project rates both flaws 9.2 out of 10, Critical (CVSS v4.0, in the GHSAs).

Does an attacker need an account?

No. Both flaws can allow remote code execution without a login (php.net advisory). On Apache with mod_php, the demonstrated attack runs before any application code, so a login page does not stop it.

Which server setups are at risk?

Every PHP install that serves web requests. php.net names PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, and rates mod_php the highest risk. It does not name nginx, Caddy or IIS. Our reading: those pass PHP requests to PHP-FPM, FrankenPHP or php-cgi, so the same risk applies.

Is PHP-FPM with nginx at risk too?

Yes. For CVE-2026-109619 the PHP security team confirmed code execution on PHP-FPM, given a suitable operation in the app. For CVE-2026-109618, source analysis shows PHP-FPM is susceptible, though no complete PHP-FPM exploit was shown (GHSAs). mod_php carries the highest risk, and PHP-FPM still needs the update.

Your site and your app

Is only WordPress, Drupal or Joomla affected?

No. The researchers used WordPress, Drupal and Joomla to show attacks without a login, but the flaw is in PHP: any app on an affected PHP is exposed, even a plain Hello World page (php2shell.com). See Platforms.

I updated WordPress and all plugins. Am I fixed?

No. App and plugin updates leave PHP as it was. Your host or server admin has to update PHP itself.

WordPress Site Health says my PHP is fine. Is it patched?

Not necessarily. Site Health compares your PHP with a recommended branch, such as 8.3, not with a patch level. On 2026-10-22 the WordPress.org PHP check gave the same answer for an unfixed 8.3.35 and a fixed 8.3.36. So a green result does not show that the PHP2Shell fix is installed. Ask your host for the exact PHP build. See WordPress.

My server shows an older number, such as 8.3.6. Is it affected?

Not necessarily. Linux distributions and LTS vendors received the patches in advance (php.net advisory), and some of their fixed builds keep the old upstream number (Ubuntu and the RHEL 9 default PHP, for example). Check that your vendor has published a fixed package, then compare your package version with it, for example with dpkg -l 'php*' 'libapache2-mod-php*' or rpm -qa 'php*' on the server.

php.net also warns that rpms.remirepo.net would not have updates on 21 October. If you use it, php.net urges you to switch to distribution packages or build from source.

I ran php -v and it shows a fixed version. Is my site using it?

Not always. The command-line PHP can be a different install from the PHP that serves your site. Check the PHP-FPM pool, the web server config, or the PHP page in your hosting panel.

My PHP version is hidden. Is that good news?

No. A hidden version says nothing either way, so the checker marks it inconclusive. Hiding the version with expose_php=0 is optional hardening and does not fix PHP2Shell (php2shell.com). Check the installed version on the server, or ask your host.

Fixing and limiting exposure

Can I fix it with php.ini settings?

No. The PHP security team says no complete configuration workaround exists. Settings such as session.upload_progress.enabled=0, a low post_max_size and request limits at the proxy only reduce exposure until you update. See Mitigations.

Does turning off display_errors help?

Not against the flaw. Changing error_reporting, using @, or turning off display_errors or log_errors gives no protection (GHSA). display_errors=0 is still good hardening in production (php2shell.com).

Does a WAF or a CDN such as Cloudflare stop it?

A WAF with PHP2Shell rules can stop some attack requests, but the researchers say a protective rule does not replace the PHP update (php2shell.com). A WAF also sees only the traffic that passes through it, and requests sent straight to your origin server skip it. Our advice: let the origin accept web traffic only from your CDN or WAF.

Do I need to restart after updating?

Yes. Restart Apache, PHP-FPM and every long-running PHP worker (php2shell.com). Our advice: if you use containers, pull or rebuild the updated image and recreate the containers.

What changes after I update?

PHP handles running out of memory differently. A new hard limit ends the process at once, without shutdown functions. The new setting memory_hard_limit_percent controls it. By default the hard limit is two times memory_limit up to 1G, and memory_limit plus 1G above 1G (php-src source). If you set memory_limit=-1 as a stopgap, set a real limit again. See After you update.

I see "zend_mm_heap corrupted" after updating. Should I downgrade?

No. php-src issue GH-24488 reports this crash in 8.4.27 and 8.5.12 with SimpleXML. It is a crash, not a reported vulnerability. The fix is in the php-src source since 2026-10-22, but not yet in a release. Our advice: do not downgrade, because older releases bring both flaws back. Watch php.net for a follow-up release.

If your site was exposed

Can I tell if someone attacked my site?

Not for sure. The researchers name these signs: unusually large or malformed PHPSESSID cookies in responses, odd multipart requests followed by memory-limit errors or repeated HTTP 500 errors, and PHP worker crashes with no clear cause (php2shell.com). Clean logs do not prove that no attack happened. See Check your logs.

What should I rotate?

The flaws can leak server memory, which can hold passwords, login tokens, API keys and certificates (php2shell.com). Our advice: after you update, rotate the secrets that PHP could read on hosts that ran an affected version, and end active sessions.

About this checker

Is php2shell.fyi official?

No. php2shell.fyi is an independent checker. It is not affiliated with php.net or the PHP project, or with the researchers' site php2shell.com, which Wiz runs. The official advisory is on php.net. The research is on php2shell.com.

Does the checker attack my site?

The normal check does not. It sends one ordinary GET request to the URL you enter, as a browser would, and follows at most two redirects on the same site. It sends no payloads, uploads or cookies. The optional active scan is different: it sends test requests that try to trigger the flaw, and it runs only when someone starts it and confirms they may test the site. Operators and privacy has the full details and how to opt out.

Why does the checker say inconclusive?

Because the public response does not show enough to tell. Common reasons:

Inconclusive is neither good news nor bad news. Check the PHP runtime on the server, or ask your host.

Why can I check a site only once every 10 minutes?

To spare sites from repeated checks. The limit is per site, and all users share it: if someone else checked the site in the last 10 minutes, you wait too. example.com and www.example.com count as one site. Each user also has limits on how many checks they can run.

Sources

Check your site

Find out which PHP version your site reports to visitors. Check my site.