Am I affected by PHP2Shell?

Short answer

If your site runs PHP and serves web requests, assume it is affected until you have confirmed two things: which PHP version your web server actually uses, and whether that build includes the patch.

• Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (php.net). As of 24 October 2026 there is no newer PHP release.

• PHP 8.1 and older get no new official release. Your options are a vendor/distro patch, the PHP team's source backports, or an upgrade (php.net).

• A distro package can show an "old" version number and still be patched. Check your distro's tracker, not just the number (Ubuntu, Debian).

What is PHP2Shell?

PHP2Shell is two critical flaws in the PHP core, fixed on 21 October 2026. Both can allow unauthenticated remote code execution (php.net).

Severity: the PHP team rates both CVSS v4.0 9.2 (Critical) (php.net). NVD has finished its analysis of both (status "Analyzed"), with CVSS v3.1 scores of 9.8 for CVE-2026-109618 and 8.1 for CVE-2026-109619 (NVD 109618, NVD 109619).

The bugs are in PHP itself, not in WordPress, Laravel or your plugins. Clean application code doesn't protect you: on Apache mod_php, the attack happens before any application code starts (GHSA-w8hw).

Exploitation attempts are now widespread. Amazon reports that PHP2Shell is seeing broad exploitation attempts in the wild, apparently from multiple actors. The earliest known attempt was on 17 October 2026, four days before public disclosure (AWS Security Blog). watchTowr has also observed exploitation in the wild since 21 October (watchTowr). Amazon says it is unclear whether these attempts would have succeeded on real systems. Indonesia's national cyber agency BSSN has also asked website operators to take security measures now (Kompas Tekno).

Which SAPIs are affected?

The PHP team says every PHP installation serving web requests is at risk, with the highest risk on mod_php (php.net):

SAPI values come from the php_sapi_name() manual. The advisory doesn't count command-line PHP (cli) as "serving web requests". Update it anyway.

How to check: shared hosting / cPanel

On shared hosting your provider usually manages the server's PHP. You can still check what your site uses.

1. Version per domain. In cPanel, go to Software → MultiPHP Manager. It lists each domain's PHP version and whether PHP-FPM is on (cPanel docs). Some hosts call the menu Select PHP Version. On WordPress, the PHP version also shows under Tools → Site Health → Info → Server (Hipwee).

   • These menus often show only "PHP 8.3", without the patch number. Go on to step 2.

2. Exact version and SAPI with phpinfo. Upload a temporary file with a hard-to-guess name (e.g. check-7f3a.php) to your site folder:

   <?php phpinfo();

   Open it in a browser and note:

   • PHP Version at the top (e.g. 8.3.36);

   • Server API (e.g. LiteSpeed V8.x, FPM/FastCGI, Apache 2.0 Handler, CGI/FastCGI);

   • the value of session.upload_progress.enabled (relevant to the stop-gaps below).

   Delete the file right after checking. phpinfo shows the PHP version, server information and server environment data (phpinfo manual) to anyone who knows the URL.

3. Compare with the patched versions: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or later (php.net).

4. Ask your host if you're below those versions, or on PHP 8.1 or older. A message you can send to support:

   "Does the PHP on my account's server include the fixes for CVE-2026-109618 and CVE-2026-109619 (PHP2Shell)? phpinfo shows version [x], Server API [y]. If not, when is it scheduled, and can I switch to 8.2.35 or later now?"

5. Switch versions if you can in MultiPHP Manager / Select PHP Version to a supported branch (8.2 or newer), then test the site. Old plugins or code can break on an upgrade.

How to check: VPS / your own server

1. CLI version (may differ from what the web server uses):

   php -v

   The PHP on a developer's laptop or on the CLI isn't necessarily the one your hosting server runs (Kompas Tekno). Do steps 2 and 3 as well.

2. Find every PHP that serves the web:

   # Running PHP-FPM (service names vary by distro, e.g. php8.3-fpm or php-fpm)
   systemctl list-units --type=service | grep -i php
   ps aux | grep -E 'php-fpm|php-cgi|lsphp|frankenphp' | grep -v grep
   
   # Apache mod_php
   apachectl -M 2>/dev/null | grep -i php     # or: httpd -M

   If apachectl -M shows php_module (or php7_module), you're on mod_php, the highest-risk SAPI (php.net).

3. Web-facing version: use a temporary phpinfo file as in the shared-hosting section, note PHP Version and Server API, then delete it.

4. Check the package, not just the number. Distros backport fixes to older versions, so a php -v that shows an "old" version doesn't by itself mean you're vulnerable. Examples listed as fixed for both CVEs:

   • Ubuntu 24.04: php8.3 8.3.6-0ubuntu0.24.04.13, even though the upstream number is 8.3.6 (Ubuntu);

   • Debian 12 (bookworm): php8.2 8.2.35-1~deb12u1; Debian 13 (trixie): php8.4 8.4.27-1~deb13u1 (Debian).

   Pentestit also advises using the distro tracker and checking each CVE's page separately, because vendors may publish them on different days (Pentestit).

   dpkg -l | grep -E '^ii\s+php'   # Debian/Ubuntu
   rpm -qa | grep -i php           # RHEL/Alma/Rocky

   Compare the package version with your distro's security tracker.

5. Docker/containers: rebuild images you built yourself on a patched PHP, then redeploy (Google Cloud).

6. Restart every PHP worker after updating (php-fpm, Apache, LiteSpeed) so the fix takes effect (watchTowr). Then re-check phpinfo.

Want to test from outside? Searchlight Cyber released php2shell-scanner (open source) to test whether a host is exposed to both CVEs (Help Net Security). Note that it deliberately triggers an out-of-memory condition, and each tested path can receive probes totalling about 29 MiB. Searchlight Cyber, the scanner's authors, say this is risky by nature (Help Net Security). Run it only against servers you own, outside busy hours.

Patched versions

Sources: php.net, GHSA-w8hw, GHSA-6wmf. End of 8.2 support: php.net.

PHP 8.1, 8.0, 7.4 or older: no official release

The PHP project doesn't ship updates for 8.1 and older (php.net). Your options, most recommended first:

1. Upgrade to a supported branch (8.2.35+, ideally 8.4/8.5), then test the app.

2. Use a vendor/distro patch. Some distros and LTS vendors provide backports. For example, Ubuntu lists fixes for php8.1 (22.04) and php7.4 (20.04). The php7.4 fix and older ones need Ubuntu Pro (Ubuntu).

3. Build from source with the PHP team's backports for 7.4, 8.0 and 8.1 (php.net).

4. PHP 7.3 and older (including PHP 5): there is no official backport from the PHP team. watchTowr reports that these old branches, PHP 5 included, are affected too (watchTowr). If you're on an old Ubuntu, Ubuntu Pro lists fixes for php7.2 (18.04), php7.0 (16.04) and php5 (14.04), the last two through the Legacy Support add-on (Ubuntu). Otherwise, upgrade, or take the server off the internet or put it behind a VPN or WAF until you can upgrade (Huntress). The UK NCSC suggests considering taking systems offline that can't be mitigated right away, and checking for compromise before you upgrade or mitigate (NCSC).

5. rpms.remirepo.net users: on 21 October the repo had no updated packages, and Help Net Security advised moving to distro packages or building from source (Help Net Security). We haven't confirmed its current status.

Stop-gaps (not a replacement for updating)

The PHP team says only an update fully closes these flaws. The steps below only cut off specific attack paths (php.net):

• Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server config, then restart every worker. Don't rely on ini_set() or FPM .user.ini. The PHP team also suggests keeping this setting until the next bugfix release, because of a separate, rare RCE path (CVE-2026-115560). That path only exists if an app switches session.serialize_handler at runtime (php.net, 23 Oct).

• On PHP 8.5 only: set fatal_error_backtraces=0, then restart workers.

• Use a low post_max_size (8M with no uploads, 32M with uploads) and limit request size at the web server/proxy.

• VPS/own server only: the PHP team lists memory_limit=-1, locked via php_admin_value, as a mitigation that is itself incomplete. Be careful: it removes PHP's memory limit, so a single request can use as much memory as the server has (PHP manual). If you use it, keep a container or cgroup memory limit as an availability boundary, as the PHP team advises. On shared hosting this isn't your setting to change; leave it to your host.

• Don't use RLIMIT_AS/RLIMIT_DATA, because they can trigger the vulnerable path.

• Cloudflare has deployed initial WAF rules for the known exploit vectors, for all customers including the free plan (Help Net Security). A WAF is an extra layer, not a fix (Google Cloud).

Updated. Am I done?

An update closes the hole, but it doesn't remove anything that got in before. Check logs, files and processes from 17 October 2026 onward, the date of the earliest known exploitation attempt (AWS Security Blog).

Huntress hasn't published confirmed indicators of compromise (IOCs) yet, but expects exploitation to show up as (Huntress):

• PHP/web server processes (php-fpm, php-cgi, httpd, apache2) spawning sh, bash, curl, wget, nc, python or perl;

• new files or webshells in the web root;

• new cron jobs, scheduled tasks or accounts.

If you find signs of compromise, isolate the server and preserve the web server and PHP logs (Huntress). Then change the access credentials stored on the server, including database access (Kompas Tekno). Wiz showed a memory-disclosure path that can expose passwords, tokens, API keys and certificates, even without code execution (Wiz).

Myths vs facts

Only claims that appear in a public source.

"It's CVSS 10.0."
No. The PHP team rates both CVEs CVSS v4.0 9.2 (php.net). The 10.0 figure came from the early leak, and Pentestit has flagged it as wrong (Pentestit).

"Both bugs are about session upload progress, so turning off upload progress is enough."
No. CVE-2026-109618 is an out-of-memory bug. Upload progress is only one confirmed path for CVE-2026-109619 (Pentestit, GHSA-6wmf). Turning it off helps, but it isn't a fix (php.net).

"Just put session.upload_progress.enabled = Off in .user.ini."
This advice has been circulating. Pentestit still lists it in its response steps, although its update log says the advice was withdrawn. The PHP team says not to rely on ini_set() or FPM .user.ini, because the setting must be active before the request is parsed. Put it in php.ini, the FPM pool or the server config (php.net). On shared hosting without that access, ask your host to set it.

"70% of websites are affected." (figure clarified)
The ~70% figure in news coverage is the share of websites that use PHP, among sites whose server-side language W3Techs can identify. It is not the number of vulnerable sites (Kompas Tekno). There is no official count of affected sites. The only way to know your site's status is to check its version.

Want us to check and patch it?

We check the PHP version, SAPI and packages your site actually uses, then patch, upgrade or backport (PHP 7.4–8.1), restart every worker, and look for signs of compromise. You get a written findings report the same day you request it, and the patch is applied within one working day after that. On shared hosting that doesn't allow a version switch, the PHP belongs to your host, and we send your host the exact request. We record the final status in the same report: checked and patched.

See the scope and request a check & patch →