PHP2Shell: Patch PHP and Check for Web Shells

Two critical flaws in PHP, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell in the press, let an unauthenticated visitor potentially run code on a web server. If your site runs WordPress, Drupal, Joomla or custom PHP, on Linux or Windows/IIS, this guide covers what to patch, how to check what you run, and how to look for signs that someone got in before you patched. Updated 8 November 2026.

What we know, and when

This box was checked against primary sources on 8 November 2026. Where news reports differed from the PHP project, we followed the PHP project and say so.

• 21 October 2026: PHP published its security announcement and two advisories, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619). Both are rated critical, 9.2 on CVSS v4.0. The NVD record for the first also shows 9.8 on the older CVSS v3.1 scale.
• Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The 8.6.0 release candidate also contains the fixes.
• 21 October 2026: CISA published an alert.
• 26 October 2026: CISA added both CVEs to its Known Exploited Vulnerabilities catalog, with a federal due date of 29 October. One vendor FAQ lists only the first CVE; the CISA catalog lists both, so we follow CISA.
• Exploitation: PHP's announcement says a working exploit has been demonstrated but does not claim attacks in the wild. Vendors do. Datadog Security Labs reports attempts from 17 October, attributing that date to a report from AWS, and watchTowr reports exploitation from 21 October. Neither says which CVE the observed attacks used. The CISA catalog entry is the strongest evidence that exploitation is real.

Who is affected

Per the PHP announcement, any PHP installation that serves web requests is in scope, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php as the highest risk. Versions before the fixed releases above are affected. PHP 8.1 and earlier no longer receive project updates. The PHP team published minimal source backports for 7.4, 8.0 and 8.1, and some distributions and long-term-support vendors ship their own fixes.

WordPress, Drupal and Joomla do not carry their own PHP. They run on the PHP of the server or hosting plan, so patching the CMS does not fix this. The PHP version is what matters.

How to find out if you are exposed

Start with an inventory. CISA advises finding every system running PHP, including PHP embedded in other software, and handling internet-facing systems first.

Find the version.

• Command line: php -v shows the command-line PHP. The web server may use a different build, so also try php-fpm -v or php-cgi -v where those exist.
• Without phpinfo: avoid leaving a public phpinfo page on a live site; it exposes a lot. Use the tools your CMS gives you instead. WordPress shows the PHP version under Tools, Site Health, Info. Drupal shows it on its Status report, and Joomla under System Information.
• Hosting control panels: most have a PHP version selector per site. Check every site, since sites on one account can differ.
• Apache with mod_php: look at the loaded modules (apachectl -M, or httpd -M) for a PHP module. If it is there, treat that server as the highest priority.
• Windows/IIS: PHP usually runs through FastCGI. Open the PHP handler mapping, note which php-cgi.exe it points to, and run that file with -v. PHP publishes Windows builds of the fixed versions.

The version number may not tell you the truth. Linux distributions and hosting providers often backport a security fix into their existing package without changing the headline PHP version. AlmaLinux says exactly this about its patched packages, so php -v cannot confirm a fix there. The reverse also happens: a number that looks old can be patched. Check your distribution's security notice for the package build:

• Debian: its security tracker lists fixed builds, for example 8.2.35-1~deb12u1 for bookworm and 8.4.27-1~deb13u1 for trixie.
• Ubuntu: its CVE page lists fixed package builds for each release, and these keep their older upstream-style numbers, such as 8.3.6-0ubuntu0.24.04.13 for 24.04 LTS. Older releases need Ubuntu Pro for the fix.
• Red Hat family: Red Hat's CVE page pointed to a bulletin and listed no fixed packages when we read it. AlmaLinux published its own fixed builds. For RHEL itself, check Red Hat's current advisory or ask your vendor.
• Shared hosting: ask your provider in writing which fix they applied.

Compare the package version on your server to the one in the notice, using your package manager (dpkg -l | grep php, rpm -q php-common, or the equivalent).

The fix

Upgrade to the fixed version for your branch (8.5.12, 8.4.27, 8.3.36 or 8.2.35), or to your distribution's patched package, then restart PHP-FPM, Apache or IIS so every worker loads it. The PHP advisory says updating is the only complete mitigation.

Interim mitigations, as PHP states them. These reduce risk but do not make a system safe:

• For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override (for example a php_admin_value in the FPM pool) and check that nothing restores a limit. Keep post_max_size low (PHP suggests 8M if you need no uploads, 32M if you do) with upload_max_filesize below it. Enforce request size and structure limits at the web server or proxy. A container or cgroup memory limit is an alternative, but PHP warns against RLIMIT_AS and RLIMIT_DATA.
• For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini or server config, not at runtime, and restart all workers. PHP suggests keeping it off after patching if you do not use it. On PHP 8.5, set fatal_error_backtraces=0 and restart.
• The advisory for CVE-2026-109619 says no configuration setting is a complete fix.

Read the advisories first; a wrong value can break an application.

If you cannot patch today. CISA advises taking PHP-based systems offline until updated if you cannot patch immediately or are on PHP 8.1 or older, and says a web application firewall may offer some interim protection. We did not find vendor-supplied WAF rules in the sources we read, so we do not offer any. Meanwhile restrict who can reach the server, apply the interim settings, and set a firm upgrade date.

Patched is not the same as clean

Reported attempts before 21 October mean a server may have been compromised before you patched. Patching closes the door; it does not remove anyone already inside. Review logs from mid-October onward.

Preserve evidence first. Before you change anything, copy web server, PHP and system logs somewhere safe, take a disk or VM snapshot if you can, and write down running processes and network connections. Cleaning up first destroys what you need to understand what happened.

Signs worth checking (read-only, and none is proof alone):

• New or recently changed .php, .phtml or .phar files, especially in upload, cache, temp and theme or plugin folders, or files you did not deploy. A read-only check on Linux is find /var/www -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -mtime -30, and Get-ChildItem -Recurse with a date filter does the job on Windows.
• Changed .htaccess or web.config files.
• Unusual POST requests in web server logs, particularly large or oddly structured ones, or repeated requests to a file that normally gets none.
• The web server or PHP worker starting a shell or downloading tools, or making outbound connections you do not expect. CISA and Datadog both call this out as the strongest sign. CISA also publishes detection rules for log-based hunting.
• PHP memory-exhaustion errors or worker crashes in the logs. Datadog notes these can have innocent causes, so correlate them.
• New cron jobs or scheduled tasks, new server users or SSH keys, and unexpected administrators in your CMS.

Compare against a clean copy. For WordPress, Drupal and Joomla, compare core, plugin and theme files with freshly downloaded copies of the same versions. For custom code, compare with your repository or last known-good deployment. Anything not in the source, and not user content, needs an explanation.

If you find something:

1. Isolate the server from the network, without powering it off if you want memory evidence.
2. Preserve evidence, as above.
3. Rotate every credential and key the server held: database passwords, API keys, CMS administrator passwords, SSH keys and any cloud or email credentials.
4. Rebuild from a clean source on a patched system, then restore data only after reviewing it.
5. Find and close the entry point. Deleting the file alone is not enough, because there may be other footholds and the original hole may still be open.

Before sharing logs with a supplier or in a ticket, redact secrets from them first. Our Exchange inbox rule investigation post uses the same evidence-first approach.

Prevention going forward

• Patch routine: an owner, a schedule and a way to see every PHP version in use, including on hosting plans and in containers.
• No PHP execution in upload directories: if only images and documents should live in a folder, configure the server so nothing there is run as code.
• Least-privilege permissions: the web account should not be able to write to code directories.
• Restrict upload types: accept only what the business needs.
• File integrity monitoring: alert when code files change outside a deployment.
• Logging and alerting: keep web, PHP and process logs off the server, and alert on shells started by web workers.
• WAF: a useful extra layer, not a substitute for patching.
• Backups you have restored: a backup you have never restored is a guess.

FAQ

My php -v shows an old number. Am I vulnerable? Not necessarily. Distributions often backport fixes. Check the security notice for your package build, or ask your host.

Is deleting the suspicious file enough? No. Preserve evidence, rotate credentials, rebuild from clean source and find the entry point.

Can Cloudek check my server? You can request a review. We cannot promise a particular outcome.

What we did not verify

• We could not confirm which CVE the observed attacks used, or the exact date attacks began. Datadog gives 17 October, watchTowr 21 October, and PHP's announcement makes no claim.
• We read the NVD record only for CVE-2026-109618, not for CVE-2026-109619.
• PHP's changelog listed 8.5.12 and 8.4.27 with a 22 October date, while the announcement is dated 21 October. We did not see the 8.3.36 and 8.2.35 entries.
• We could not find fixed Red Hat package versions on the pages we read, and did not read Red Hat's bulletin.
• We did not read Tenable, Qualys, Wiz or Recorded Future analyses, and have not tested any of this on a compromised server. This is general guidance, not a guarantee that a system is clean.