Skip to content

PHP2Shell: How to Patch the PHP Vulnerability on Any Server

Guides & InsightsUpdated Long guide
Share
PHP2Shell: How to Patch the PHP Vulnerability on Any Server

Every Laravel, Symfony, Drupal, Magento, Joomla or custom PHP site on an unpatched server is exposed to PHP2Shell, a pair of flaws in the PHP engine tracked as CVE-2026-109618 and CVE-2026-109619. Both can let an attacker with no login run code on a server that uses PHP to answer web requests.1 PHP fixed them on October 21, 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no official release.1

Updating your application does not touch PHP2Shell. Cloudflare says "updating website code or a plugin(s) alone does not fix these vulnerabilities," and PHP says "There are no complete mitigations, updating is the only safe choice."101

The short version

  • What: Two memory-safety bugs in PHP itself, rated 9.2 (Critical) by PHP under CVSS v4.0. The NVD's own CVSS v3.1 scores are 9.8 for CVE-2026-109618 and 8.1 for CVE-2026-109619.25
  • Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 2026. PHP 8.1 and older get no official release.1
  • Who: Any PHP install serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php the highest risk.1
  • Exploited? Disputed. Amazon and Cloudflare report broad attempts. CISA had not observed exploitation, and its Known Exploited Vulnerabilities (KEV) catalog listed neither CVE on October 23. Sansec says public exploits fail on default installs. None of the sources we checked reports a confirmed breach.91113148
  • The version trap: Distro, CloudLinux and many host builds keep the old version number after patching. Check the changelog or build date.192228
  • Do this: Snapshot, patch PHP, restart every PHP process, verify, then review logs back to October 17.923

What is PHP2Shell, in plain English?

PHP2Shell is two related flaws in the core PHP engine. They sit underneath every PHP application, so a site can be exposed even when its own code is secure.7

CVE-2026-109618, "RCE via OOM corruption." When a request runs out of memory, PHP abandons it with a low-level jump. Some of the request's memory can be reached before PHP has finished setting it up, and the shutdown routine then reads that half-built state. Crafted multipart form submissions, and some application inputs, can push a request into that condition. No login is needed.2

CVE-2026-109619, "RCE via stale global state." A PHP worker handles many requests in a row. Some state it keeps between requests can point at memory from a request that already finished. If a later request on the same worker touches it before it is reset, PHP uses freed memory (a use-after-free bug). Fatal errors, timeouts and out-of-memory conditions can leave that state behind.3

Wiz says an attacker can also read a PHP worker's memory without running any code, exposing passwords, tokens, API keys and certificates from other requests.6

Wiz demonstrated unauthenticated code execution against the latest official container images for WordPress, Drupal and Joomla, and says a simple "Hello World" app on an affected version can be vulnerable.6 Sansec lists products that Calif, one of the reporting teams, found exploitable without a login, including Magento 2.4.9, Laravel 13.11, Symfony 8.1 and WHMCS.8 The vulnerable code goes back to PHP 5.4, released in 2012.68

Who is exposed to PHP2Shell, and who is less exposed?

By how PHP runs

How PHP runs What PHP's advisories say
Apache with mod_php Highest risk. Code execution demonstrated for both CVEs, and the attack can fire before any application code runs.123
PHP-FPM (Nginx and most modern stacks) CVE-2026-109618: "no complete FPM exploit has been demonstrated." CVE-2026-109619: the session path was validated on a normal pool.23 The PHP Foundation says code execution was "confirmed on PHP-FPM through application-level code paths."4
LiteSpeed (LSAPI) and FrankenPHP Likely susceptible to CVE-2026-109618, not validated. For CVE-2026-109619, LiteSpeed is conditional. FrankenPHP has no known default trigger, which PHP says does not make it immune.23
php-cgi On PHP's at-risk list.1

Red Hat says standard RHEL deployments use PHP-FPM, which makes code execution "difficult in practice."17 watchTowr says to prioritize internet-facing servers, especially those running mod_php.12 Patch the FPM servers the same day.

PHP's at-risk list covers installations "serving web requests," so command-line scripts are not on it.1 Long-running CLI workers such as queue consumers still need a restart after you patch.23

By PHP branch

Branch PHP2Shell fix1 Security support3637
8.5 8.5.12 Until Dec 31, 2029
8.4 8.4.27 Until Dec 31, 2028
8.3 8.3.36 Until Dec 31, 2027
8.2 8.2.35 Until Dec 31, 2026
8.1, 8.0, 7.4 No PHP release. PHP's source backport, or a distro or host package Ended Dec 31, 2025 (8.1), Nov 26, 2023 (8.0), Nov 28, 2022 (7.4)
7.3 and older No PHP backport. Some vendors ship patched packages Ended

Old branches are common. VulnCheck counted PHP on 2,608,039 internet-facing hosts, including over 700,000 on PHP 3.x through 7.3 and about 400,000 on 7.4, 8.0 or 8.1, per The Hacker News.34 WordPress.org's statistics put 34.7% of WordPress sites below PHP 8.2.39

By who controls the server

Drupal's security team says a patched PHP release "is the only complete mitigation."38 On shared and managed hosting, your host patches PHP and you confirm it. On a VPS, a dedicated server or a server manager such as Laravel Forge, you patch. Forge says its automatic security updates "do not patch PHP," and GoDaddy and Hostinger say VPS customers patch PHP themselves.232829 Containers need a rebuild, and PaaS platforms vary (table below).

PHP2Shell timeline

All times UTC.

Date (2026) What happened
August 11 to September 18 Calif, Wiz and OpenAI report the bugs to PHP.4
October 17 Amazon's MadPot honeypots record an exploitation attempt from a commercial anonymization network.9
October 20, about 15:00 The CVE IDs leak online with a wrong 10.0 score.4
October 20, 19:30 PHP pre-announces the release and moves it from October 22 to October 21 at 14:00.4
October 21, about 02:00 Amazon sees the first proof-of-concept exploits.9
October 21, 03:02 Cloudflare's WAF rules go live on all plans, including Free.10
October 21, 07:34 Hosting partners report active exploitation incidents to Patchstack.30
October 21, 14:00 PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35.14
October 21, 14:19 watchTowr publishes its PHP2Shell page. It later reports honeypot exploitation of both CVEs that day.12
October 22, 21:21 Sophos withdraws its same-day report of one successful exploitation. Its telemetry shows scanning and failed attempts.44
October 23, 06:27 CISA's KEV catalog still lists neither CVE.14

PHP's ChangeLog page dates the releases October 22, the originally planned day. PHP's announcement and advisories say October 21.4012

Is PHP2Shell being exploited in the wild?

Attackers are trying it at scale, and no one has publicly confirmed a breach through it. The sources disagree on how much of the activity works:

  • Amazon: "PHP2Shell is now seeing broad exploitation attempts in the wild," though "it's unclear if any of these attempts would have succeeded in real-world systems."9
  • Cloudflare: CEO Matthew Prince, quoted by SecurityWeek, said the network saw thousands of attempts in the 10 hours before the announcement and "millions now."11
  • watchTowr: says it "has observed exploitation" of both CVEs in its honeypots. Its head of threat intelligence, Jake Knott, told SecurityWeek the exploits being sprayed either don't work, only test for timing differences, or crash the target.1211
  • CISA: "has not observed exploitation" as of its October 21 alert.13 The CVE record's CISA exploitation field reads "none," and KEV listed neither CVE at 06:27 UTC on October 23.4114
  • Sophos (October 22): reported "one successful exploitation" at 16:18 UTC, then withdrew it at 21:21 UTC. Its customer telemetry shows "scanning and a small number of failed exploitation attempts," with "no evidence of a successful compromise."44
  • Sansec (October 22): "The public exploits do not work against a default PHP installation." Most need the app to also have a local file inclusion bug.8
  • Arctic Wolf (October 22): wide scanning and some second-stage attempts, with "comparatively little evidence of reliable exploitation at scale."15
  • Hosts: Pantheon saw "no evidence of compromise," and Hostinger reports no rise in malware infections.2729 Patchstack, which logged partner reports of exploitation at 07:34 UTC on October 21, saw "only probing attacks" by 13:57 UTC.30

Still, PHP itself refers to "a demonstrated exploit" for mod_php, so patch as though a reliable one is already circulating.1

How do I check which PHP version my site really runs?

Check the build as well as the version number, because backported fixes keep old numbers. Ubuntu 24.04's patched package still reports PHP 8.3.6, and CloudLinux's patched ea-php84 build reports 8.4.26.1922 GoDaddy says "Your PHP version number may not change after this update," and Hostinger says the same.2829

On shared or managed hosting

  1. Read your host's status page for what it patched and when.
  2. Check the build date. Hostinger says to open Websites > Dashboard > PHP Info, where a Build Date of "October 21, 2026 or later" means the fix is in.29 GoDaddy gives the same date test, read from the "built:" line of php -v or from a temporary phpinfo() file you delete afterward.28
  3. Ask in writing. "Has the October 21, 2026 PHP security release, or a vendor backport of it, been applied to every PHP version on my account? What is the PHP build date now?"

On a VPS or dedicated server

php -v reports the command-line PHP, and the web server may run a different binary, so watchTowr says to confirm the version that serves web requests.12 On Ubuntu servers using Ondřej Surý's packages (what Forge installs), Forge's checks are:23

ls /etc/php                    # every PHP version installed
php8.4 -v                      # CLI build for one version
php-fpm8.4 -v                  # the FPM build that serves the site
apt-cache policy php8.4-fpm    # installed vs candidate package

Repeat for each version in /etc/php, including versions no site uses. To see whether a distro package carries the fix despite an old version number, Sansec gives:8

# Debian and Ubuntu (swap 8.3 for your version)
zgrep CVE-2026-109618 /usr/share/doc/php8.3-common/changelog.Debian.gz
# RHEL, AlmaLinux, Rocky Linux
rpm -q --changelog php-common | grep CVE-2026-109618

RHEL's 8.2 and 8.3 streams name no CVE in the changelog, so Patchstack says to use dnf updateinfo there.30 For ea-php packages, CloudLinux gives rpm -q ea-php84-php-cli --changelog | grep -E 'CVE-2026-(109618|109619)'.22

Platform Fixed package or advisory
Ubuntu 26.10 / 26.04 / 24.04 / 22.04 php8.5 8.5.9-0ubuntu2.1 (26.10) and 8.5.4-0ubuntu1.5 (26.04), php8.3 8.3.6-0ubuntu0.24.04.13, php8.1 8.1.2-1ubuntu2.2819
Ubuntu 20.04 / 18.04 (Ubuntu Pro) php7.4 7.4.3-4ubuntu2.29+esm5, php7.2 7.2.24-0ubuntu0.18.04.17+esm14. 16.04 and 14.04 get fixes through the Legacy Support add-on20
Debian 13 / 12 php8.4 8.4.27-1~deb13u1 (DSA-6574-1), php8.2 8.2.35-1~deb12u1 (DLA-4848-1)21
RHEL 10 RHSA-2026:87070 (php 8.3.36-1.el10_2), RHSA-2026:87071 (php8.4 8.4.27-1.el10_2)18
RHEL 9 RHSA-2026:87072 (php:8.2), RHSA-2026:87079 (php:8.3), RHSA-2026:87151 (php 8.0.30)18
RHEL 8 RHSA-2026:87073 (php:8.2), RHSA-2026:87080 (php:7.4)18
cPanel EasyApache 4 (release 25.91) ea-php85 8.5.12, ea-php84 8.4.27, ea-php83 8.3.36, ea-php82 8.2.35. Backported fix in ea-php81, ea-php80 and ea-php7445
CloudLinux ea-php builds ea-php84 8.4.26-2, ea-php83 8.3.35-2, ea-php82 8.2.34-2, ea-php81 8.1.34-4 (version numbers stay below PHP's)22

Red Hat still listed the RHEL 9 php:8.4 stream as "Affected" when we checked.18

In Docker and other containers

Check the PHP inside the running container and the tag in your Dockerfile's FROM line. The official php image has 8.5.12, 8.4.27, 8.3.36 and 8.2.35 tags, refreshed on October 22. Its newest 8.1 tag is 8.1.34, last updated January 2, 2026, so an 8.1 image has no fix.24 An image built before October 21 from a floating tag such as php:8.4-fpm keeps the old PHP until you rebuild it.

On PaaS and serverless platforms

Platform What the vendor says
AWS Elastic Beanstalk Updated platforms arrive with Managed Platform Updates. Otherwise, update the platform version.25
AWS Lambda and Lightsail Lambda has no managed PHP runtime, so update your custom runtime or image. Lightsail instances can't be updated in place, so launch new ones from updated blueprints.25
Amazon Linux Updated PHP packages are available. Apply them with your normal update.25
Google Cloud App Engine standard on PHP 8.2 or newer updated automatically. App Engine flexible, GKE, and Cloud Run without automatic base image updates need a rebuild or redeploy. Runtimes 5.5, 7.2 to 7.4 and 8.1 stay vulnerable.26
Pantheon Live sites patched on October 21. Free and sandbox environments to follow within 24 to 48 hours. No customer action required.27

We found no PHP2Shell statement from Microsoft Azure App Service. If your platform has said nothing, open a ticket and ask for the patch date.

How do I patch PHP2Shell on each type of server?

Work in this order on every server: snapshot, patch PHP, restart everything that runs PHP, verify. Patch PHP before you spend time on app code, plugins or config cleanup.

1. Snapshot first

Snapshot the disk, or at least copy site files, database, PHP config and logs off the server. GoDaddy's self-managed steps start with a backup, and watchTowr says to preserve logs, configuration and suspicious files before any change.2812

2. Update PHP from the right source

Install PHP only from php.net, your OS vendor, your host, or the package source your server manager already configured. Patchstack warns against "unofficial 'fix' plugins and copy-pasted snippets," and JFrog found fake proof-of-concept exploits and prank malware on GitHub, per The Hacker News.3034

Ubuntu and Debian distro PHP. Ubuntu says "a standard system update will make all the necessary changes."19 Run sudo apt update and sudo apt upgrade, then repeat the changelog check.

Ondřej Surý packages (Forge and many VPS setups). On Forge, the recommended route is the server's PHP tab, where "Update PHP X.X" also repairs the package source. Over SSH, run sudo apt-get update and confirm the Candidate in apt-cache policy matches the fixed version. If it doesn't, Forge says the repository hasn't caught up, so wait and retry. Then upgrade every package for that version while keeping your config files. Forge warns the upgrade restarts PHP-FPM, so expect a few seconds of downtime per version:23

sudo apt-get install --only-upgrade -y \
  -o Dpkg::Options::="--force-confold" \
  $(dpkg -l 'php8.4*' | awk '/^ii/ {print $2}')

RHEL, AlmaLinux and Rocky Linux. Run your normal dnf update (on RHEL, that pulls the errata in the table above), then confirm with dnf updateinfo or the changelog check.18308

cPanel and CloudLinux. cPanel's EasyApache 4 release 25.91, dated October 21, moves ea-php82 through ea-php85 to the fixed PHP versions and backports the fix to ea-php74, ea-php80 and ea-php81.45 On CloudLinux, fixed ea-php52 through ea-php85 builds reached stable at 20:55 UTC on October 21, and alt-php fixes at 00:07 UTC on October 22.22 Update, then verify with the rpm changelog check. On cPanel & WHM, also confirm you took September's builds for CVE-2026-87899, a separate flaw that lets any hosting account run code as root.

Docker. Pull the fixed tag, rebuild without the build cache, redeploy, and run php -v inside the new container.

3. Restart everything that runs PHP

A patched package on disk does nothing for a process that started before the update. Restart "Apache, PHP-FPM, and any long-running PHP workers," as The Hacker News puts it, for every PHP version on the server.3312 For Laravel, Forge lists:23

php artisan queue:restart
php artisan horizon:terminate
php artisan octane:reload

Symfony Messenger consumers, Supervisor daemons and any other long-running PHP process need a restart too.

4. Verify the build that serves traffic

Run php-fpm8.x -v for each version, or recheck your host's build date. Aikido's free checker at php2shell.aikido.io tests from outside, but its definitive test "can crash a PHP worker and interrupt requests," and a clean result does not prove you are patched.32 Scan only servers you own.

5. Undo temporary mitigations

If you set memory_limit=-1 as a stopgap, put a finite limit back. The fix adds a hard memory ceiling that kills a process before shutdown handlers run, so the PHP2Shell researchers say to review memory_limit alongside request-size limits.7 PHP's advisory says it "might be prudent" to keep session upload progress off after patching if you don't use it.3

What if I'm still on PHP 8.1, 8.0 or 7.4?

PHP will not ship a release for these branches.1 Your options, best first:

  1. Move to a supported branch. PHP 8.2's security support ends December 31, 2026, so 8.3 or 8.4 buys more time.36 Test on a staging copy with composer install and your test suite first. If a Laravel, Symfony or custom app needs code changes to move, that falls under our web application development work.
  2. Use a vendor backport. Ubuntu patched 22.04's PHP 8.1 and, through Ubuntu Pro, 20.04's PHP 7.4 and 18.04's PHP 7.2.1920 Red Hat shipped errata for RHEL 8's php:7.4 and RHEL 9's PHP 8.0.30.18 cPanel backported the fix to ea-php74, ea-php80 and ea-php81, and CloudLinux's ea-php builds cover ea-php52 through ea-php85.4522
  3. Build PHP's source backport. PHP published "minimal source-backports" for 7.4, 8.0 and 8.1 for people building from source or without an LTS vendor.1 Patchstack calls them "a minimal mitigation, not a restored support branch." They switch session upload progress off regardless of php.ini and add no hard memory limit.30
  4. Take it offline. CISA says organizations that can't patch, or still run PHP 8.1 or older, should take PHP systems offline until they are patched or updated.13 The UK's NCSC says to consider the same for systems that can't be mitigated.16

What can I do if I can't patch PHP today?

PHP says the mitigations "reduce exposure to specific attack paths but do not make an installation safe."1 Use them for hours or days while you schedule the update.

Mitigation Helps against Limits
session.upload_progress.enabled=0 in php.ini or the FPM pool, then restart workers The known CVE-2026-109619 session path Nothing for CVE-2026-109618. PHP says not to rely on ini_set() or FPM .user.ini.1
memory_limit=-1 via php_admin_value CVE-2026-109618 "Not a complete mitigation."2 One request can then use all server memory, per Sansec, so PHP suggests a container or cgroup memory limit as the backstop.81
post_max_size of 8M (32M with uploads), upload_max_filesize below it CVE-2026-109618 Larger uploads fail.1
Proxy limits on body size, field count, multipart parts, headers and nesting CVE-2026-109618 Must also cover requests with no usable Content-Length.1
Block multipart/form-data if unused CVE-2026-109618, also suggested by Amazon Breaks uploads, and some checkouts submit as multipart. Sansec says to place a test order afterward.289
fatal_error_backtraces=0 (PHP 8.5) The confirmed mod_php case of CVE-2026-109619 Leaves other triggers open.3
pm.max_requests=1 CVE-2026-109619 Heavy performance cost.3
WAF rules (Cloudflare, AWS WAF, Cloud Armor, Imunify360) Known exploit patterns Cloudflare saw attackers mutating payloads. CloudLinux said early on October 22 that no Imunify360 rule blocked the CVE-2026-109618 memory path yet. Patchstack says Cloudflare's rules help only if your server accepts traffic exclusively from Cloudflare.1022302526

Never use RLIMIT_AS or RLIMIT_DATA as a memory cap, because PHP says they trigger the vulnerable path.2 Cloudflare's paid plans should confirm the Managed Ruleset is in block mode, and AWS WAF users who pinned the PHP rule group version must update it.1025

How do I tell if my server was hit by PHP2Shell?

Amazon says to investigate from at least October 17.9 Treat each signal below as a lead to investigate, since memory-limit errors and HTTP 500s also happen on healthy systems.31

In logs:

  • Unusual multipart requests followed by memory-limit errors or repeated HTTP 500s, and unexplained PHP worker crashes or restarts.67
  • Unusually large or deeply nested multipart requests.12
  • Large or malformed PHPSESSID cookies in responses, a possible sign of memory disclosure.631
  • POST requests containing PHP_SESSION_UPLOAD_PROGRESS.9 Access logs don't store request bodies, so this needs WAF or body logging.
  • The user agent php2shell-scan/109618 or the markers PHP2SHELL_CONFIRMED and P2SFNAME, listed by Arctic Wolf.15 These show someone tested you. They don't show the test worked.

On the server:

  • PHP or web server processes starting shells, discovery commands such as id or whoami, or download tools.31
  • curl or wget writing to world-writable paths such as /tmp, and executables run from there.31
  • New .php or script files in web-served directories, especially right after an inbound request.31 For a first pass, find /var/www -name '*.php' -newermt 2026-10-17 lists PHP files changed since October 17 (use your web root).
  • New cron jobs or accounts nobody created, and outbound connections from the web server user to new destinations.1231

Amazon published the addresses behind early attempts, including 103.216.220[.]92 and 31.223.184[.]166. They include shared anonymization infrastructure, so Amazon says organizations "should investigate any observations involving these addresses as opposed to blocking." Arctic Wolf tied second-stage attempts to 92.118.112[.]100.915

The PHP2Shell researchers say the absence of these signals "does not establish that a system is unaffected."7 If a host was exposed, rotate its secrets anyway.

If you're not technical, ask your host or developer when PHP was patched, what the build date is now, and whether their firewall or malware scanner flagged anything since October 17. If you run WordPress, read our PHP2Shell guide for WordPress sites for the WordPress-specific checks.

What should I do if I find signs of compromise?

Work in this order, so you keep the evidence and don't clean a server that can be re-entered the same way.

  1. Preserve evidence. Snapshot the disk and copy logs, config and suspicious files off the server.12 Never restore from this snapshot.
  2. Cut off access. Restrict internet access or take the site offline.1213
  3. Patch PHP and restart every worker before cleaning anything.
  4. Remove persistence. Hunt for web shells, cron jobs, new accounts and unknown processes.1231 Check authorized_keys files for SSH keys nobody added.
  5. Rebuild or restore. If compromise is confirmed, rebuild from a clean image or restore a backup from before October 17, patched before it goes live. For WordPress, our hacked WordPress site playbook covers the first hours.
  6. Rotate secrets once the clean, patched server is in place, so an attacker still on the old one can't capture the new values. Aikido advises rotating passwords, API keys and tokens on internet-facing PHP systems.32 Include database, payment, email and cloud credentials. Plan app key rotation (such as Laravel's APP_KEY) with your developer, because data encrypted with the old key needs handling.
  7. Get help if unsure. The NCSC points organizations that aren't confident assessing a compromise themselves to an incident response provider.16

Beyond PHP2Shell: a whole-site security checklist

  • Name a patch owner for the runtime. Write down who patches PHP, the web server and the OS for each site, since server tools can skip PHP the way Forge's automatic updates do.23 Subscribe to php.net, distro and host notices, and apply critical runtime patches within 24 hours (our recommendation).
  • Keep an inventory. CISA says to inventory every system running PHP, noting PHP is often embedded in other software.13 Palo Alto Networks, for one, confirmed all PAN-OS and Panorama versions are affected, with no fixed release as of October 22, per Help Net Security.35 Include staging sites and old subdomains.
  • Stay on supported branches. PHP 8.2 leaves security support on December 31, 2026.36 Schedule 8.3 or 8.4 upgrades now.
  • Audit dependencies. composer audit "checks for and lists security vulnerability advisories" from Packagist by default.42 Run it in CI so a failing check blocks a deploy (our recommendation).
  • Lock the origin behind your WAF. A WAF only helps if attackers can't reach your server directly, so allow web traffic only from your WAF's IP ranges.30
  • Use least privilege. Give each site its own PHP-FPM pool and Unix user, keep security.limit_extensions to .php, and set sensitive values with php_admin_value, which ini_set() cannot override. PHP's manual warns pools "are not a security mechanism," so put high-value apps on their own server or container.43 Make code directories read-only to the web server user, and block PHP execution in upload folders.
  • Keep secrets out of reach. Store keys outside the web root and repository, scope each key narrowly, and rotate on a schedule.
  • Test your backups. Keep off-server copies with several restore points, and run a restore drill.
  • Monitor behavior. Amazon advises detections "that don't rely on a signature for a specific CVE."9 Alert when a web worker spawns a shell, when PHP files change in the web root, and when the web server user opens new outbound connections.31

Your PHP2Shell checklist

Today

  1. List every server, container, host account and platform running PHP, including staging.
  2. Snapshot, then patch PHP (or confirm your host did by build date), and restart every PHP process.
  3. Verify the PHP build serving web traffic.
  4. If you can't patch, apply the mitigations above or take the site offline.

This week

  1. Review logs, processes, files and outbound connections back to October 17.
  2. Rotate secrets on internet-facing PHP hosts, and remove stopgaps such as memory_limit=-1.
  3. Book the move off PHP 8.1 and older, and off 8.2 before December 31.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name for two critical PHP engine flaws, CVE-2026-109618 and CVE-2026-109619, fixed on October 21, 2026. Both can let an unauthenticated attacker run code on a server that uses PHP for web requests, whatever framework or CMS runs on top.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Distributions, CloudLinux and some hosts also ship backported fixes under older version numbers, such as Ubuntu 24.04's 8.3.6 and CloudLinux's ea-php84 8.4.26-2, so check the changelog or build date.

Does updating WordPress, Laravel or Drupal fix PHP2Shell?

No. The bugs are in the PHP runtime, which comes from your server packages, host or container image. Drupal's security team calls a patched PHP release "the only complete mitigation."

Is PHP2Shell being exploited?

Amazon and Cloudflare report widespread attempts, and watchTowr's honeypots saw exploitation. CISA had not observed exploitation, KEV listed neither CVE on October 23, and Sophos withdrew its one report of a successful attack. Patch as if a working exploit exists.

My host still shows the same PHP version. Am I patched?

Possibly. GoDaddy and Hostinger both say the version number may not change after their fix. Look for a PHP build date of October 21, 2026 or later, or ask your host when they applied it.

Is PHP 8.1 or 7.4 patched for PHP2Shell?

Not by an official PHP release. PHP published minimal source backports, and Ubuntu, Red Hat, cPanel and CloudLinux shipped patched packages for some old branches. If none applies to you, CISA says to take those systems offline until they are patched or upgraded.

If you want help

If you run PHP sites across several hosts and need to know which are patched, which are stuck on PHP 8.1 or older, and which show signs of a breach, send us the list through /start. You'll get a scoped estimate within 48 hours.

Sources

  1. PHP Group, News Archive 2026: "Upcoming Critical PHP Security Release" (October 20, 2026), "Security advisory: Critical remote code execution vulnerabilities, update now" and the PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 release announcements (October 21, 2026). php.net
  2. PHP php-src security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618), "RCE via OOM corruption," October 21, 2026. github.com
  3. PHP php-src security advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), "RCE via stale global state," October 21, 2026. github.com
  4. The PHP Foundation, blog post on the October 2026 PHP security release and its disclosure timeline, October 21, 2026. thephp.foundation
  5. NIST National Vulnerability Database, CVE-2026-109618 and CVE-2026-109619 records (API), last modified October 22, 2026, checked October 23, 2026. nist.gov
  6. Wiz Research, PHP2Shell research blog post, October 21, 2026. wiz.io
  7. PHP2Shell researchers' disclosure site, checked October 23, 2026. php2shell.com
  8. Sansec, PHP2Shell research note, updated October 22, 2026. sansec.io
  9. AWS Security Blog, CJ Moses, "Amazon threat intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot," October 21, 2026. aws.amazon.com
  10. Cloudflare Blog, PHP vulnerabilities and WAF protection, published October 21, 2026, modified October 22, 2026. cloudflare.com
  11. SecurityWeek, Ionut Arghire, report on PHP2Shell exploitation starting before the patches, October 22, 2026. securityweek.com
  12. watchTowr Intel, PHP2Shell intelligence page, published 14:19 UTC October 21, 2026, updated October 22, 2026. watchtowr.com
  13. CISA, "Critical Vulnerabilities in PHP Require Immediate Patching," October 21, 2026. cisa.gov
  14. CISA, Known Exploited Vulnerabilities catalog (JSON feed), catalog version 2026.10.21, checked by WitsCode at 06:27 UTC on October 23, 2026. Neither CVE-2026-109618 nor CVE-2026-109619 was listed. cisa.gov
  15. Arctic Wolf, PHP2Shell threat analysis blog post, October 22, 2026. arcticwolf.com
  16. UK National Cyber Security Centre, news item on the critical PHP security issue, October 21, 2026, updated October 22, 2026. ncsc.gov.uk
  17. Red Hat, Security Bulletin RHSB-2026-013, checked October 23, 2026. redhat.com
  18. Red Hat Security Data, CVE-2026-109618 (affected releases, errata and package states), checked October 23, 2026. redhat.com
  19. Ubuntu Security Notice USN-8948-1, October 21, 2026. ubuntu.com
  20. Ubuntu Security Notice USN-8948-2 (Ubuntu Pro releases), October 21, 2026. ubuntu.com
  21. Debian Security Tracker, CVE-2026-109618, checked October 23, 2026. debian.org
  22. CloudLinux Blog, PHP CVE-2026-109618 and CVE-2026-109619 post (rolling updates through 00:08 UTC October 23, 2026). cloudlinux.com
  23. Laravel Forge Documentation, "PHP security advisory (CVE-2026-109618, CVE-2026-109619)," checked October 23, 2026. laravel.com
  24. Docker Hub, official php image tags (8.1, 8.2.35, 8.3.36, 8.4.27 and 8.5.12 queries), checked October 23, 2026. hub.docker.com
  25. AWS Security Bulletin 2026-143-AWS, PHP2Shell (CVE-2026-109618, CVE-2026-109619), checked October 23, 2026. aws.amazon.com
  26. Google Cloud Blog, guidance on responding to CVE-2026-109618 and CVE-2026-109619 (bulletin GCP-2026-070), checked October 23, 2026. cloud.google.com
  27. Pantheon Status, PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 incident, October 21, 2026 (times in PDT). status.pantheon.io
  28. GoDaddy Blog, Gary Robert, "Important PHP security update: What website owners need to do," October 20, 2026, updated through October 22, 2026. godaddy.com
  29. Hostinger Blog, post on protecting hosting customers from PHP2Shell, October 21, 2026, updated October 22, 2026. hostinger.com
  30. Patchstack, Mart Virkus, PHP major vulnerability alert (October 2026), October 21, 2026. patchstack.com
  31. SentinelOne, blog post on detecting and stopping PHP2Shell attacks, October 21, 2026. sentinelone.com
  32. Aikido, blog post on the critical PHP2Shell vulnerabilities, October 21, 2026, updated October 22, 2026. aikido.dev
  33. The Hacker News, Swati Khandelwal, report on PHP's emergency patches for two critical flaws, October 21, 2026. thehackernews.com
  34. The Hacker News, Ravie Lakshmanan, report on pre-disclosure PHP2Shell exploitation, VulnCheck exposure counts and JFrog's fake PoC findings, October 22, 2026. thehackernews.com
  35. Help Net Security, report on the patched PHP2Shell vulnerabilities, October 21, 2026, updated October 22, 2026. helpnetsecurity.com
  36. PHP Group, Supported Versions, checked October 23, 2026. php.net
  37. PHP Group, Unsupported Branches (end-of-life dates), checked October 23, 2026. php.net
  38. Drupal Security Team, "Critical PHP update on Wednesday, October 21, 2026 (14:00 UTC)," PSA-2026-10-20, October 21, 2026. drupal.org
  39. WordPress.org, PHP version statistics API, checked October 23, 2026. Versions below 8.2 add up to 34.7%. api.wordpress.org
  40. PHP Group, PHP 8 ChangeLog, checked October 23, 2026. php.net
  41. CVE Program, CVE-2026-109618 record (reserved October 12, 2026, published October 21, 2026, CISA ADP exploitation status "none"), checked October 23, 2026. cve.org
  42. Composer Documentation, Command-line interface: audit and outdated, checked October 23, 2026. getcomposer.org
  43. PHP Manual, FPM configuration, checked October 23, 2026. php.net
  44. Sophos, post on the proof-of-concept exploit for CVE-2026-109618 and CVE-2026-109619, with updates through 21:21 UTC October 22, 2026. sophos.com
  45. cPanel, EasyApache 4 Change Log 25, releases 25.91 and 25.92 (October 21, 2026), checked October 23, 2026. docs.cpanel.net

Facts checked on October 23, 2026.

Written by

Sudhakaran, Head of Technology

Published

Web build

Comparing web agencies?

Send the brief. You get a scoped plan, a real timeline, and we tell you when another shop is the better fit.

  • Rebuilds, redesigns, and migrations
  • You own the code and the domain
  • Scoped estimate within 48 hours
Get a scoped plan