PHP2Shell fix: check your PHP version, patch safely and verify your server

Summary. If anything you run uses PHP, including WordPress, Drupal, Joomla, Laravel or a vendor appliance, patch the runtime that serves web requests now. On 21 October 2026 PHP fixed two critical flaws, CVE-2026-109618 and CVE-2026-109619 (known as PHP2Shell), that allow unauthenticated remote code execution, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Debian, Ubuntu, Red Hat, Alpine, cPanel and the official Docker images had fixed packages by 22 October, often under lower version numbers because the fix is backported. Three mistakes cause most misses: checking the command-line PHP instead of the web runtime, updating packages without restarting PHP-FPM or Apache, and patching the host while containers keep the old PHP. Patching also does not prove you were not hit: a successful exploit can return HTTP 200 without crashing anything, so review logs for memory-exhaustion errors and shells spawned by the web server. PHP says no configuration change makes an installation safe; if you cannot update today, take exposed sites offline.

About this article. Versions, package builds and advisories were checked against PHP, distribution security trackers, cPanel, Docker Hub, national cyber agencies and Datadog Security Labs on 22 October 2026. Package status changes daily, so confirm with your vendor before you act. Commands are examples; adapt them to your systems. Researched with AI assistance and reviewed by our editorial team.

At a glance: fixed PHP versions

Anything below these releases in the same branch is affected unless your vendor documents a backported fix. PHP's supported-versions page lists each branch's end-of-life date. Distribution packages often keep older version numbers with the fix applied, so check the vendor's advisory or changelog, not just the version string.

What is at risk

PHP's advisory says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and rates mod_php highest because a demonstrated exploit fires before any application code runs. Red Hat makes the same point, rating default PHP-FPM setups harder to exploit than mod_php.

The flaws are in PHP itself, so a site can be vulnerable even if its own code is clean. Updating WordPress, a Drupal module, a Joomla extension or a Composer package does not patch the PHP engine. Products that bundle PHP, such as control panels, appliances and container images, need their own updates; the Dutch NCSC keeps a list of affected third-party software. For the background on how the flaws were found, see our explainer on how AI helped find PHP2Shell, and for the shutdowns it triggered, our PHP2Shell news explainer.

Step 1: find every PHP runtime

Start with an inventory of everything that executes PHP: production and staging servers, every virtual host and PHP-FPM pool, containers and CI images, queue workers, scheduled jobs, control panels and appliances. Prioritise internet-facing systems, especially those that accept forms or uploads.

On a Linux shell, these show the command-line PHP and its configuration:

            php -v
php -r 'echo "SAPI: ", PHP_SAPI, PHP_EOL, "Version: ", PHP_VERSION, PHP_EOL;'
php --ini
          

They report the CLI binary only, which can differ from the PHP that serves your website. To see what is serving requests, check running processes and the FPM binary itself:

            ps -eo pid,user,cmd | grep -E '[p]hp-fpm|[p]hp-cgi|[h]ttpd|[a]pache2'
php-fpm8.3 -v   # Debian and Ubuntu name the binary by branch
php-fpm -v      # RHEL-family systems; may need sudo
          

Then confirm in your web server configuration which FPM pool, CGI binary or Apache module handles each site. On shared or managed hosting, use the provider's PHP selector and ask them to confirm the patched build. Do not leave a public phpinfo() page online to check versions.

Step 2: apply the fix for your environment

Take a snapshot or confirm your rollback plan first, then use the update path your platform supports. Do not mix repositories or jump branches just to see a higher version number.

Linux packages and repositories

Fixed packages available on 22 October 2026, from each vendor's security tracker:

To see what is waiting, on APT systems:

            sudo apt update
apt list --upgradable 2>/dev/null | grep -E 'php|libapache2-mod-php'
          

On DNF systems:

            sudo dnf check-update 'php*'
          

These list updates; they do not prove the fix is installed. After updating, confirm the CVE is in the package changelog, for example with apt changelog php8.3-fpm | grep CVE-2026-109618 on Debian or Ubuntu, or rpm -q --changelog php-fpm | grep CVE-2026-109618 on RPM systems.

cPanel, WHM and CloudLinux

cPanel's notice lists patched EasyApache 4 packages: ea-php82 8.2.35, ea-php83 8.3.36, ea-php84 8.4.27 and ea-php85 8.5.12, plus backported ea-php74, ea-php80 and ea-php81 builds. Its documented process is to clear and rebuild the yum cache, run /scripts/rpmup, then confirm with rpm -q --changelog ea-php83-php-cli | grep -m1 CVE-2026-109618. CloudLinux says fixed alt-php packages are in its repositories, and cPanel points PHP versions older than 7.4 to TuxCare's extended support.

Managed hosting

If your provider runs PHP, ask them to confirm in writing that every PHP version assigned to your domains, including FPM pools, Apache modules and alternate versions, is patched for both CVEs, which build contains the fix, and that the workers have been restarted, not just that an update is available.

Docker and Kubernetes

Updating PHP on the host does not touch PHP inside containers. The official php images for 8.5.12, 8.4.27, 8.3.36 and 8.2.35, including the -fpm and -apache variants, were published on Docker Hub on 21 October. Rebuild every image from a patched base, scan it, and redeploy; restarting an old container does not change its PHP binary.

            docker images --format '{{.Repository}}:{{.Tag}}  {{.ID}}'
docker run --rm --entrypoint php your-image:tag -v
          

The first lists local images; the second prints the PHP version inside an image. For Kubernetes, roll out new pods from the rebuilt image and confirm no old ReplicaSets are still serving traffic.

Windows and bundled products

For PHP under IIS or FastCGI, replace the exact PHP build the site uses. For appliances, firewalls and management tools that embed PHP, follow the vendor's update; patching a separate PHP on the same machine may not touch the embedded copy.

Step 3: restart and verify the patch is live

Updated files on disk do nothing until PHP-FPM, Apache, LiteSpeed or your container runtime loads them. Restart or reload the services, then check:

• The runtime serving each site is the fixed release or a vendor-confirmed backport.

• Every FPM pool, virtual host, worker, scheduled job and container has been checked, and no old worker processes remain.

• Health checks and key journeys pass: login, forms, uploads, checkout, APIs and background jobs.

• PHP and web server error logs show no new unexplained errors.

• The patch date and package build are recorded in your change log.

On upstream builds, the fix also adds a memory_hard_limit_percent setting, which caps how far memory can grow before PHP kills the worker outright. php -r 'var_dump(ini_get("memory_hard_limit_percent"));' returning false on an upstream build suggests it is unpatched; do not rely on this check for distribution backports. Test in staging where you can, but do not let a long test cycle leave a public site unpatched.

Step 4: check for signs of compromise

Patching closes the hole; it does not tell you whether someone used it first. Exploitation reports grew from 22 October, with New Zealand's NCSC citing reports of active exploitation, while Canada's Cyber Centre had identified none on 21 October. Datadog cites AWS seeing attempts as early as 17 October, so review from at least that date.

The Canadian Cyber Centre recommends reviewing web server, application, authentication and endpoint logs, and investigating unexpected processes, commands, files, accounts or outbound connections tied to PHP or web-server services. Datadog's analysis adds specific signals:

• Memory-exhaustion fatal errors that end with in Unknown on line 0.

• Unusually long form field names or unexpected control bytes in form submissions.

• A shell, curl or wget process started by a PHP worker or the web server, which Datadog calls the most direct evidence of success.

• For CVE-2026-109619, early configuration warnings, shutdown diagnostics, fatal errors and timeouts.

Do not rely on HTTP 500s or crashed workers: in Datadog's testing a successful exploit returned HTTP 200 and the worker kept running. Two starting points (log paths vary by system):

            grep -h 'Allowed memory size' /var/log/php*fpm*.log /var/log/apache2/error.log /var/log/httpd/error_log 2>/dev/null | grep 'Unknown on line 0'
ps -eo pid,ppid,user,cmd --forest | grep -E -A3 '[p]hp-fpm|[a]pache2|[h]ttpd' | grep -E 'sh -c|bash|curl|wget'
          

One odd error is not proof of compromise. If you find credible signs, preserve logs and snapshots before changing anything, isolate the system, rotate credentials and secrets from a clean machine, consider rebuilding from a known-good image, and follow your incident-response and reporting obligations.

Step 5: if you cannot patch today

PHP is clear that only an update is a complete solution, and that its interim measures reduce exposure to specific attack paths without making an installation safe. They are:

• For CVE-2026-109618: an administratively set memory_limit of -1 backed by a container or cgroup memory cap (not RLIMIT_AS or RLIMIT_DATA); post_max_size of 8M without uploads or 32M with them; and web server or proxy limits on decoded request size, field count, multipart parts, header count and nesting depth, including requests without a usable Content-Length.

• For CVE-2026-109619: session.upload_progress.enabled set to 0 at server or pool level with every worker restarted (not through ini_set or .user.ini); fatal_error_backtraces set to 0 on PHP 8.5; removing invalid or deprecated per-request settings; and fixing fatal errors and timeouts attackers can reach.

These settings have side effects and only cover some paths. Our news explainer shows them as a PHP-FPM pool snippet. If a public service cannot be updated quickly, restrict or remove public access until it can, as CISA, CERT-EU and Canada's Cyber Centre advise. A web application firewall rule buys time; it is not a fix.

Common mistakes to avoid

1. Checking only the CLI. php -v on a shell may not be the PHP serving your site.

1. Updating only the CMS. WordPress, Drupal and Joomla updates do not patch PHP.

1. Forgetting containers and bundled products. A patched host leaves old images and appliances untouched.

1. Trusting the upstream version string. Debian, Ubuntu, Red Hat and CloudLinux backport fixes under lower numbers; check the changelog for the CVE.

1. Skipping the restart. Old workers keep running the old code.

1. Treating a workaround or WAF as the fix. PHP says updating is the only safe choice.

1. Assuming a patched server is clean. Investigate exposure from 17 October onwards.

PHP2Shell remediation checklist

• Inventory every PHP web runtime and every product that bundles PHP.

• Record the version and package source serving each public site.

• Map each system to a fixed upstream release or a vendor-confirmed backport.

• Snapshot and prepare rollback.

• Apply the update to production and non-production environments.

• Rebuild and redeploy containers and images.

• Restart PHP-FPM, Apache, LiteSpeed and workers.

• Verify versions, changelogs, health checks and logs.

• Review logs and endpoint data for signs of earlier compromise.

• Rotate secrets and follow incident response if compromise is suspected.

• Record the evidence and keep watching vendor advisories.

• If you are on PHP 8.2, plan the move to 8.3 or later before 31 December 2026; our guide to hiring PHP developers covers that deadline.

For a repeatable process for runtime emergencies like this one, see our Node.js security release playbook, and if you run a large WordPress estate, our WordPress development team can take patching off your hands.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our PHP development team can inventory and patch PHP runtimes across servers, containers and CMS estates, rebuild images, and plan upgrades off end-of-life branches, with our cybersecurity services team reviewing logs for signs of compromise. Talk to us at /contact-us/.

Last updated: 22 October 2026.

References

1. Security advisory: critical remote code execution vulnerabilities, update now — PHP

1. CVE-2026-109618 — Debian security tracker

1. PHP2Shell: critical vulnerabilities in PHP, detection, analysis and remediation — Datadog Security Labs

1. Supported versions — PHP

1. CVE-2026-109618 — Red Hat Customer Portal

1. php2shell operational information — NCSC-NL on GitHub

1. CVE-2026-109618 — Ubuntu security

1. Critical PHP Security Release - CVE-2026-109618 and CVE-2026-109619 — cPanel

1. PHP2Shell incident status — CloudLinux

1. Official php image — Docker Hub

1. CVE-2026-109618 and CVE-2026-109619 affecting PHP — New Zealand NCSC

1. AL26-026: critical vulnerabilities impacting PHP — Canadian Centre for Cyber Security