CVE-2026-109618 · CVE-2026-109619
PHP2Shell checker: is my site affected?
Enter a website to see the PHP version it shows and whether that version has the PHP2Shell fix, plus a full passive security scan. We never send exploit code.
PHP version checker_
This PHP2Shell checker answers "is my site affected?" from the outside. It works as a PHP version checker: it loads the homepage the way any visitor does and reads the PHP version the server reports in its X-Powered-By or Server header, then compares it with the releases that fixed CVE-2026-109618 and CVE-2026-109619 on 21 October 2026. It recognises Ubuntu and Debian build strings, which keep an old version number while carrying the fix, and says when a site runs PHP but hides the version, which is the case for most well configured sites. Then it runs the rest of our website security check, because a site that was exposed before it was patched may already show signs of a hack.
To check the PHP version of a website you run yourself, the steps for cPanel, hPanel, Plesk and a VPS are below.
What is PHP2Shell?
PHP2Shell is two memory safety bugs in the PHP runtime, published on 21 October 2026 with fixes for every supported branch. Both are rated CVSS 4.0 9.2 (critical) and can lead to remote code execution by an attacker who is not logged in, with the rights of the web server's PHP worker.
CVE-2026-109618: out of memory corruption
When PHP runs out of memory, it abandons the request. If that happens while request data is only partly set up, the cleanup that follows can treat that data as valid. Crafted multipart requests can trigger it. On Apache with mod_php this can be reached before any of your application's code runs.
CVE-2026-109619: stale state across requests
PHP reuses worker processes. Some internal state can still point at memory that was freed at the end of an earlier request, and a later request on the same worker can use it. PHP confirmed code execution through session upload progress (on mod_php and PHP-FPM) and through PHP 8.5's fatal error backtraces.
The bugs were reported by Calif, Wiz and OpenAI, after a developer working for the PHP Foundation first spotted signs of the memory bug while fixing an issue from a 2024 Quarkslab audit. Because the bugs are in PHP itself, updating WordPress, Drupal or a plugin does not fix them: PHP has to be updated.
Who is affected?
The PHP project says every installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php, where a demonstrated exploit runs before any application code. The researchers found affected code going back to PHP 5.4.
PHP runs a large share of the web, which is why national agencies in the US (CISA, NSA), UK, Canada, Australia, New Zealand and the Netherlands all published advisories. Shared hosting customers usually cannot update PHP themselves: the host has to.
Patched PHP versions for each branch
| Branch | PHP2Shell | Update to | Support (php.net) |
|---|---|---|---|
| 8.5 | Fixed | 8.5.12 | Security support until 31 Dec 2029 |
| 8.4 | Fixed | 8.4.27 | Security support until 31 Dec 2028 |
| 8.3 | Fixed | 8.3.36 | Security support until 31 Dec 2027 |
| 8.2 | Fixed | 8.2.35 | Security support ends 31 Dec 2026 |
| 8.1, 8.0, 7.4 | No official release | Source backports from the PHP security team; distribution or LTS packages | End of life |
| 7.3 down to 5.4 | No fix from PHP | Upgrade | End of life |
PHP 8.6.0 RC4, a test release, also contains both fixes. Sources: php.net release announcements and supported versions page, 21 and 25 October 2026.
Ubuntu, Debian and other distribution packages
Linux distributions received the fixes before the public release and patch the PHP version they already ship, keeping its number. So PHP/8.1.2-1ubuntu2.20 in a header is not automatically vulnerable, and 8.1.2 is not automatically safe: what counts is the package build. These are the builds the Ubuntu and Debian trackers list as fixed:
| Release | Package | Fixed build |
|---|---|---|
| Ubuntu 26.10 | php8.5 | 8.5.9-0ubuntu2.1 |
| Ubuntu 26.04 LTS | php8.5 | 8.5.4-0ubuntu1.5 |
| Ubuntu 24.04 LTS | php8.3 | 8.3.6-0ubuntu0.24.04.13 |
| Ubuntu 22.04 LTS | php8.1 | 8.1.2-1ubuntu2.28 |
| Ubuntu 20.04 (Ubuntu Pro) | php7.4 | 7.4.3-4ubuntu2.29+esm5 |
| Debian 13 (trixie) | php8.4 | 8.4.27-1~deb13u1 (DSA-6574-1) |
| Debian 12 (bookworm) | php8.2 | 8.2.35-1~deb12u1 (DLA-4848-1) |
The checker compares these build strings when a site shows one. Red Hat based systems (RHEL, AlmaLinux, Rocky, CloudLinux) and cPanel's EasyApache packages also patch without always changing the number, so on those, check your package updates or ask your host. Trackers: Ubuntu CVE-2026-109618, Ubuntu CVE-2026-109619, Debian CVE-2026-109618, Debian CVE-2026-109619.
How does the PHP2Shell checker work?
PHP adds an X-Powered-By: PHP/x.y.z header to every page unless expose_php is off, and some Apache servers add the PHP version to the Server header. We read those and decide: at or above the fixed release for the branch is patched; below it is likely affected; 7.4, 8.0 and 8.1 have no official fix; anything older is end of life; a build with a distribution suffix is compared with that distribution's fixed build where we know it. If no version is shown but we see a PHPSESSID cookie, links to .php pages, or WordPress, Joomla, Drupal or another PHP application, the verdict is "PHP in use, version hidden".
A worked example. On 25 October 2026 a university department site we checked sent X-Powered-By: PHP/8.2.35 with a Red Hat Apache server header. 8.2.35 is the fixed 8.2 release, so the verdict was "Patched for PHP2Shell", with a reminder to keep session upload progress switched off until the next regular release. A site sending PHP/8.2.30 would get "Likely affected", and one sending PHP/8.1.33 "a branch with no official fix".
How to check your site and patch it, step by step
1Enter your domain
Type the site address above. The checker loads the homepage like a visitor and reads what the server says about itself.
2Read the PHP verdict
Patched, older than the fix, a branch with no official fix, a Linux distribution build, or PHP in use with the version hidden.
3Confirm the version where PHP runs
Check it in your hosting panel or with php -v and php-fpm -v on the server, because a hidden or distribution version cannot be judged from outside.
4Update PHP and restart it
Install the fixed release or your distribution's security update, then restart PHP-FPM, Apache or LiteSpeed so the new code is loaded.
5Check again and hide the version
Run the checker again, then set expose_php = Off so the version is no longer advertised.
How to check your PHP version
cPanel
Open MultiPHP Manager in the Software section. It lists the PHP version each domain uses and the server default. That shows the branch (for example ea-php83); the exact patch level comes from the host's EasyApache packages.
Hostinger hPanel
Go to Websites, open the site's Dashboard and search for PHP Configuration in the sidebar. The selected version applies to every site on the plan.
Plesk
Open Websites & Domains, pick the domain and click PHP (PHP Settings). The PHP support line shows the version and handler (FPM, FastCGI).
VPS or dedicated server
Run php -v, and also php-fpm -v (or php-fpm8.3 -v), because the command line PHP and the one serving your site can be different builds. On Ubuntu or Debian, dpkg -l 'php8*' lists the installed package builds; on RHEL based systems, rpm -qa 'php*'.
WordPress
Tools > Site Health > Info > Server shows the PHP version the site runs on.
phpinfo() on your own server
Create a file with <?php phpinfo(); under a random name, open it once, note the version, and delete it straight away: it reveals a lot about your server. Only do this on a site you run; we never look for such files on other people's sites.
How to patch PHP2Shell
Shared hosting (cPanel, hPanel, Plesk)
Ask your host whether its PHP builds have the 21 October fix. On cPanel, the host updates the EasyApache PHP packages; you can switch a domain to a newer branch in MultiPHP Manager. On Hostinger, pick 8.2 or newer in PHP Configuration. On Plesk, the server admin installs updates in Tools & Settings, then you choose the version per domain under PHP.
Ubuntu or Debian (apt)
sudo apt update && sudo apt upgrade, then restart PHP: sudo systemctl restart php8.3-fpm (your version) or sudo systemctl restart apache2 for mod_php. Check that dpkg -l 'php8*' shows the fixed build from the table above.
RHEL, AlmaLinux, Rocky, Fedora (dnf)
sudo dnf upgrade 'php*', then sudo systemctl restart php-fpm and httpd or nginx. Check your vendor's advisory for the fixed package.
Docker, source and Windows
Rebuild containers on the newest image for your PHP branch, built after 21 October. From source or on Windows, download 8.5.12, 8.4.27, 8.3.36 or 8.2.35 from php.net. On 7.4, 8.0 or 8.1, use the PHP security team's backport branches or, better, upgrade.
Restart every PHP process after updating: a running worker keeps the old code.
Temporary mitigations if you cannot update today
PHP's advisory lists these, and says plainly that none of them makes an installation safe. Updating is the only complete fix.
- Turn off session upload progress:
session.upload_progress.enabled = 0in php.ini, the FPM pool or the server config (not withini_set()or.user.ini, which come too late), then restart every worker. This blocks the confirmed session paths of CVE-2026-109619 and also the third bug disclosed on 23 October. PHP and SANS suggest keeping it off until the next regular release, even after patching. - PHP 8.5 only:
fatal_error_backtraces = 0, set by the administrator, then restart. - Smaller request bodies:
post_max_size = 8Mwhere no uploads are needed, or 32M withupload_max_filesizebelow it, and limits on request size and multipart parts at the web server or proxy. - For CVE-2026-109618:
memory_limit=-1set so applications cannot override it (php_admin_value). Do not use RLIMIT_AS or RLIMIT_DATA, which can trigger the bug. - A web application firewall such as Cloudflare's emergency rules, which cover traffic routed through Cloudflare only.
PHP2Shell timeline
- 17 Oct 2026, first attempt seen. Amazon's MadPot honeypots log the first exploitation attempt, four days before the fix.
- 20 Oct 2026, ids leak, notice. The CVE IDs leak with a wrong score of 10.0; PHP announces a security release and moves it forward a day.
- 21 Oct 2026, fix released. Cloudflare's WAF rules go live at 03:02 UTC. PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 at 14:00 UTC. CISA issues its alert.
- 23 Oct 2026, third bug. PHP discloses CVE-2026-115560, a lower risk bug in session upload progress, fixed in the next regular release.
Is PHP2Shell being exploited?
Yes, attempts are real. Amazon's threat intelligence team saw a first attempt against its MadPot honeypots on 17 October, before disclosure, and more from several sources from 21 October, and advises investigating from 17 October rather than from the release date. Cloudflare reported early attacks on 21 October and attackers changing payloads to get around its rules. How well the public exploits work is less clear: Rapid7 found each public proof of concept works only on a specific combination of operating system, PHP build and web server, and a SANS handler noted they rely on lab settings such as an 8 MB memory limit and a single worker. That is a window to patch, not a reason to wait. The same SANS diary mentions a possible way around the current fix, without details, which is one more reason to keep upload progress off.
Does Cloudflare protect my site?
If your site is behind Cloudflare, its emergency WAF rules for PHP2Shell went live at 03:02 UTC on 21 October for every plan with the WAF, Free included; Pro, Business and Enterprise users should check the Cloudflare Managed Ruleset is deployed in block mode. Cloudflare's own post says the rules are an additional layer and you should still patch PHP, and a later update notes that sites that renamed session.upload_progress.name are not covered by the WAF rule. The checker notes when a site is behind Cloudflare.
How accurate is this PHP version checker?
It is exactly as accurate as the headers the site sends. A shown version is the version of the PHP build that answered, so "patched" and "older than the fix" are reliable for plain upstream builds. Builds from distributions and some control panels keep old numbers while carrying the fix, so for those we say so instead of guessing. Most sites hide the version, and then nobody can tell from outside: you need to check on the server. A CDN or proxy can also remove or cache headers. We never try the exploit to find out, on any site.
Why we built this PHP2Shell checker
When PHP2Shell broke, the advice everywhere was "check your PHP version", but most site owners do not know where to look, and the tools that answer it from outside either want an account or go further than a visitor would. We already had the parts: a passive website check that reads headers, and the habit of saying what we cannot see.
Nitin Raja, who builds Is It Up or Down, puts it this way: "After testing out a lot of websites, I found what is needed by people and what is not, and built around this." Here that meant one box, a verdict per PHP branch that does not cry wolf over distribution builds, and the patch steps on the same page.
What this PHP2Shell checker measures
- PHP version: from X-Powered-By and the Server header of the homepage, compared with 8.5.12, 8.4.27, 8.3.36 and 8.2.35, the end of life branches, and the Ubuntu and Debian fixed builds in the table above.
- PHP in use: a PHPSESSID cookie, links to .php pages, and WordPress, Joomla, Drupal, Magento and other PHP applications.
- Cloudflare: whether the site answers through Cloudflare.
- Everything in the website security check: signs of a hack, blocklists, HTTPS and security headers.
What it does not measure: whether PHP2Shell can actually be exploited on the server (we never try), the PHP version of pages other than the homepage, the server's package versions, or mitigations such as upload progress being off.
Why this PHP2Shell checker is different
It reads only what the server already tells every visitor, so it is safe and legal to run on any site. It knows the difference between an upstream version and a distribution build, gives the branch-specific answer, and puts the steps to check and patch on the same page.
| This checker | Typical vulnerability scanners | |
|---|---|---|
| How it checks | Reads the headers a normal page view returns | Often active probes or an installed agent |
| Distribution builds | Compared with Ubuntu and Debian fixed builds, otherwise flagged as "check your package" | Remote scans often go by the number only |
| Hidden version | Says PHP is in use and how to check yourself | Often "not detected" |
| Patch steps | cPanel, hPanel, Plesk, apt, dnf on the page | Usually a link to the vendor |
| Account | None | Usually required |
Sources
- PHP security advisory, 21 October 2026, PHP advisory on CVE-2026-115560, 23 October, PHP 8 ChangeLog and supported versions
- GitHub advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- The PHP Foundation on the release and php2shell.com (Wiz, Calif, OpenAI)
- CISA: Critical vulnerabilities in PHP require immediate patching
- Tenable PHP2Shell FAQ and Rapid7 analysis
- SANS ISC: Reliable php2shell exploitability and PHP vulnerability wrap-up
- Amazon threat intelligence on exploitation before disclosure and Cloudflare's WAF protections
- cPanel MultiPHP Manager and Hostinger: change the PHP version
PHP2Shell questions
What is PHP2Shell?
PHP2Shell is the name used for two critical bugs in PHP itself, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. Both are rated 9.2 (CVSS 4.0) and can let an attacker who is not logged in run code on the web server. They are in the PHP runtime, not in WordPress or any other application, so updating your CMS or plugins does not fix them.
Is my site affected by PHP2Shell?
If the site runs PHP older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or any 7.4, 8.0 or 8.1 build without a vendor backport, assume yes. Enter the domain above: if the site shows its PHP version we give a verdict, and if it hides it we show how to check from your hosting panel or server.
How do I check the PHP version of a website?
From outside, only if the site shows it: the X-Powered-By header (for example PHP/8.3.36) or a PHP version in the Server header, which is what the checker above reads. Most well configured sites hide it. With access, look in cPanel MultiPHP Manager, hPanel PHP Configuration, Plesk PHP settings, WordPress Tools > Site Health > Info > Server, or run php -v on the server.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all released on 21 October 2026. There is no official release for 7.4, 8.0 or 8.1: the PHP security team published source backports for those branches, and some Linux distributions and long-term support vendors ship patched packages.
My host shows PHP 8.1 or 7.4. Am I vulnerable?
A plain 8.1.x or 7.4.x number from the PHP project is vulnerable, because those branches got no fix. Some distributions patch old branches and keep the number (Ubuntu 22.04 ships a fixed 8.1.2-1ubuntu2.28, for example), so ask your host which package you have. The safer answer is to move to 8.2.35 or newer. CISA advises taking systems on 8.1 or older offline until they are patched or updated.
Does Cloudflare protect my site from PHP2Shell?
Partly. Cloudflare put emergency firewall rules live for every plan with the WAF, including Free, on 21 October 2026, and paid plans should check that the Managed Ruleset is in block mode. Cloudflare says the rules are an extra layer that does not replace updating PHP, and they only cover traffic that goes through Cloudflare.
Is PHP2Shell being exploited?
Amazon saw a first exploitation attempt on one of its honeypots on 17 October 2026, four days before the fix, and more from 21 October. Cloudflare reported attacks on 21 October. Public proof of concept code exists, but Rapid7 and SANS found it works only on specific setups. That makes now the time to patch, not a reason to wait.
Does this checker try to exploit my site?
No. It loads the homepage like a visitor, reads the headers it sends back and runs the same passive checks as our website security check. It never sends exploit code, never looks for phpinfo or other hidden files, and identifies itself as "isitupordown.com site checker".