PHP2Shell on Shared Hosting: cPanel, Plesk, DirectAdmin, CloudLinux

On shared and reseller hosting, the PHP2Shell fix (CVE-2026-109618 and CVE-2026-109619) has to come from your host, through control panel packages such as cPanel's ea-php, CloudLinux alt-php, Plesk's PHP builds or DirectAdmin CustomBuild. Site owners should confirm which PHP build serves each site, ask the host for the patched package and restart, and leave PHP 8.1 or older.

Our PHP2Shell explainer covers the flaws and the fleet playbook covers distro packages and containers. This post covers the sites that run on control panels, where the person who owns the website does not own the PHP.

Why hosting is different

Four parties sit between the PHP project and a shared hosting site:

1. The PHP project ships source releases: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, plus minimal source backports for 7.4, 8.0 and 8.1 (php.net).
2. The panel or OS vendor turns source into packages: cPanel's ea-php, CloudLinux alt-php, Plesk's PHP, DirectAdmin's CustomBuild recipes.
3. The host installs those packages and restarts PHP.
4. You pick the PHP branch for your site from a panel menu.

Each link waits on the one before it. The Hacker News noted that hosts can only build packages after PHP ships. Plesk staff told their forum they could not give an ETA before the release.

The chain also creates a version trap. Sites on 8.1, 8.0 or 7.4 get no new upstream release. They are fixed only if the panel vendor backported the patch into the package they run, and the version number does not change when that happens.

What happened, from the hosting side

Times are UTC on 21 October unless noted.

Exploitation status is disputed; the parent explainer sets out who reported attacks and who had not. Treat an unpatched shared server as at risk now.

Who is responsible for patching

Whoever has root on the server. This is the usual split; your contract is the final word.

Unlimited Web Hosting's customer notice shows the split clearly. It updates PHP on shared and reseller servers using control panel and OS vendor builds, while VPS customers with root update PHP themselves. The Hacker News makes the related point that updating WordPress or Laravel does not touch the PHP runtime underneath.

The branch always stays with you. Reclaim Hosting said it was moving managed sites on 8.1 or earlier to 8.2. Unlimited Web Hosting asked customers to move sites on 8.1 or older up in cPanel themselves.

How each panel ships PHP

cPanel and WHM: EasyApache 4 and ea-php

cPanel's docs say EasyApache 4 installs each branch as an ea-phpNN package. The CLI binary is /usr/local/bin/ea-phpNN, the CGI binary /usr/bin/ea-phpNN, and each branch has its own php.ini under /opt/cpanel/ea-phpNN/root/etc/. Sites pick a branch in WHM's MultiPHP Manager, where the handler (PHP-FPM, CGI, suPHP or DSO) is also set.

The EasyApache 4 change log lists release 25.91, dated 21 October 2026:

cPanel's docs say unsupported branches normally get no further updates, so these three backports are an exception. The 25.91 entry lists nothing older than ea-php74. For older branches, cPanel's docs point to TuxCare's Extended Lifecycle Support.

cPanel delivers ea-php through the OS package manager. Its docs say to set Operating System Package Updates to Automatic in WHM's Update Preferences or update as root. Either way, PHP-FPM and Apache must restart afterwards.

DSO is cPanel's name for mod_php, the setup PHP rates highest risk. Any branch on DSO should be patched and restarted first.

CloudLinux: alt-php, PHP Selector and Imunify360

Many shared hosts run CloudLinux under cPanel, Plesk or DirectAdmin. CloudLinux adds its own builds, called alt-php, under /opt/alt/phpNN/ (for example /opt/alt/php82/usr/bin/php, per TuxCare's docs). Customers choose them through the CloudLinux PHP Selector.

So a cPanel server on CloudLinux can carry two separate PHP sets, ea-php and alt-php, patched by separate releases. A host that applied EA4 25.91 has fixed ea-php, but a site switched to alt-php needs the alt-php update too.

CloudLinux planned patched alt-php for every branch from 5.2 to 8.5. By its 16:08 UTC update, only alt-php74 was confirmed released; later builds may have landed since. Its blog gives yum update 'alt-php*' for RHEL family systems and apt-get upgrade on Debian and Ubuntu.

The same blog explains Imunify360 ruleset 8.83. On Apache it blocks the publicly circulating exploit shape. On LiteSpeed the rule only logs. Servers with the WAF disabled, ImunifyAV, or no Imunify product get nothing, and variants of the known pattern may slip through. In CloudLinux's words: "This is an interim mitigation, not a fix."

Plesk

Plesk ships its own PHP builds alongside the operating system's. Plesk's docs say Tools and Settings, then PHP Settings, shows every version and handler combination with the number of domains using each. From the shell, plesk bin php_handler --list lists handlers, and -json true gives JSON.

Plesk's handler guide calls mod_php and CGI "severely outdated and/or insecure" and recommends Dedicated FPM for shared hosting, which gives each site its own pool of PHP-FPM processes. Since one PHP2Shell bug involves state left behind between requests on the same worker, per-site pools are a sensible default, though not a fix.

Plesk published a support article titled "Vulnerability CVE-2026-109618 and CVE-2026-109619: Remote code execution in PHP shipped with Plesk". It returned an error when we tried to load it. Search summaries of it list fixed Linux packages for 8.2.35, 8.3.36, 8.4.27 and 8.5.12, with 8.1, 8.0, 7.4 and Plesk for Windows still in development and a planned hotfix for sw-engine, the PHP that runs the panel itself. Treat those details as unconfirmed and read the article. Plesk forum users noted that dedicated FPM pools need their own restart, with a pattern such as plesk-php*-fpm*.

DirectAdmin and CustomBuild

DirectAdmin compiles PHP from source with CustomBuild. Up to four versions run side by side, set by php1_release to php4_release in /usr/local/directadmin/custombuild/options.conf. A forum post listing the options shows php1_mode accepting php-fpm (the default), fastcgi or lsphp.

On 21 October a DirectAdmin administrator posted that a new build was on the current and stable channels, applied with da update and then da build php. Staff added:

• The PHP rebuild is manual unless the CustomBuild cron feature is on.
• An asterisk by a version means the number is unchanged but patches were added. For 7.4, the file custombuild/patches/php-7.4/143-php-7.4-cve-2026-109618.patch with no pending update means you are current.
• 7.3 down to 5.6 had no patch yet, and 8.1 did not build cleanly on some systems with the new patch.

What hosts published

Vendor statements are covered above. Two hosts' public notices show the range of responses:

Many hosts announce through status pages and email rather than blogs. A missing post does not mean nothing happened. Ask.

How a site owner can check

1. Find the branch for each site

In cPanel, open MultiPHP Manager, and on CloudLinux hosts also Select PHP Version, which can override it. In Plesk, check the domain's PHP settings. In DirectAdmin, use the PHP version selector under Domain Setup.

2. Ask the web server, not the shell

php -v over SSH shows the command line binary, which may not serve your site. Upload a file with a random name, load it once, then delete it:

<?php
// check-7f3a.php: delete after use
echo PHP_VERSION, ' | ', PHP_SAPI, ' | ', php_ini_loaded_file();

The middle value is the SAPI: fpm-fcgi (PHP-FPM), cgi-fcgi (CGI or FastCGI), litespeed (LSAPI) or apache2handler (mod_php). The php.ini path usually names the vendor: /opt/cpanel/ea-php83/..., /opt/alt/php83/... or /opt/plesk/php/8.3/....

3. With SSH, list the builds

# cPanel ea-php
for b in /usr/local/bin/ea-php*; do echo "$b: $($b -r 'echo PHP_VERSION;')"; done
# CloudLinux alt-php
for b in /opt/alt/php*/usr/bin/php; do echo "$b: $($b -r 'echo PHP_VERSION;')"; done
# Plesk PHP
for b in /opt/plesk/php/*/bin/php; do echo "$b: $($b -r 'echo PHP_VERSION;')"; done
# Package versions, if rpm is readable
rpm -qa 'ea-php*' 'alt-php*' 'plesk-php*' 2>/dev/null | sort

4. Read the result

5. Move up a branch

If you are on 8.1 or older, test on 8.3 or 8.4 in staging and switch in the panel. PHP 8.2 reaches end of life on 31 December 2026, so 8.3 or newer is the better target.

What to ask your host

Send this as a ticket and keep the reply.

Subject: PHP2Shell (CVE-2026-109618, CVE-2026-109619) status for my account

1. Which PHP build serves each of my domains (ea-php, alt-php, Plesk PHP,
   CustomBuild or distro packages), and with which handler?
2. Has it been updated to 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, or for
   7.4 / 8.0 / 8.1 to a release with the backport? Which package or
   release (for example EA4 25.91)?
3. When were PHP-FPM, Apache and any LiteSpeed lsphp workers restarted?
4. Does my server use mod_php (DSO)?
5. What mitigation ran before the update (WAF ruleset version)?
6. Have you checked logs on my server for PHP workers spawning shells
   since 20 October?
7. If my site is on PHP 7.3 or older, what is your plan and deadline?

Resellers should pass the answers on and offer to move clients on old branches.

For hosts running the panel themselves

1. Update vendor packages. cPanel: dnf upgrade 'ea-php*' (or yum). CloudLinux: yum update 'alt-php*'. DirectAdmin: da update, then da build php. Plesk: apply updated PHP components once its article lists your branch.
2. Restart every PHP process. On cPanel, /scripts/restartsrv_apache_php_fpm and /scripts/restartsrv_httpd. On Plesk, systemctl restart 'plesk-php*-fpm*'. On LiteSpeed, restart the server so lsphp workers respawn. Then verify as the fleet playbook shows.
3. Check the Imunify360 ruleset if you rely on it meanwhile. CloudLinux's blog gives cat /etc/apache2/conf.d/modsec_vendor_configs/imunify360-full-apache/VERSION for cPanel with Apache, and imunify360-agent update --force modsec-rules if it is below 8.83.
4. Find sites with no fix. On cPanel, the WHM API function php_get_vhost_versions (run as whmapi1 php_get_vhost_versions) returns every virtual host's PHP version. Plesk's php_handler utility also has a usage option. Contact owners on 7.3 or older.
5. Retire unused branches and watch process trees. Huntress advises alerting when PHP or web server processes spawn shells, interpreters or download tools.

If a server cannot be patched soon, CERT-EU and UK NCSC advice applies: take it offline or restrict access. See how public bodies made that call in governments take websites offline over PHP2Shell.

Common mistakes and troubleshooting

• The shell says 8.3.36 but the site is old. The SSH CLI and the web SAPI can be different builds. Use the web check.
• The host updated ea-php but the site did not change. The site may run alt-php through PHP Selector, or its FPM pool has not restarted.
• 7.4.33 never changes. Expected. Only the host can confirm the backported package.
• Relying on .user.ini or ini_set(). php.net says not to rely on either for the mitigations, and mod_php ignores .user.ini. A PHP developer quoted by The Hacker News: "ini settings won't save you."
• Trusting the WAF. The Imunify360 rule only logs on LiteSpeed; Cloudflare only sees traffic routed through Cloudflare.
• Unmanaged VPS owners waiting for the host. With root and a panel licence, the rebuild is often yours. DirectAdmin's PHP rebuild is manual without its cron feature.
• Forgetting the panel's own PHP. Check your vendor's advisory for the panel's internal PHP too.

What would have helped

PHP2Shell gave about a day of warning. For hosting, the bottleneck was the length of the chain from php.net to a running worker.

Practices any host or site owner can use:

• Stay on supported branches. Sites on 8.2 or newer got an ordinary release. Sites on 8.1 or older depended on one vendor's backport, and 7.3 or older had no fix on release day.
• Know which build serves each site. A host should answer "ea-php or alt-php, which branch, which handler" for any domain in seconds.
• Drop mod_php and shared pools on shared servers. Per-site PHP-FPM pools limit what one site's worker state can touch.
• Tie package updates to restarts. Automatic OS updates and CustomBuild cron help only if PHP restarts afterwards.
• Write the customer message in advance. The clearest notices on 21 October said what the host does, what the customer does, and where status lives.
• Test restores. Unlimited Web Hosting advised restoring compromised sites from a backup dated before 20 October. That needs a backup that restores.

Where Safeguard fits

Safeguard does not patch hosting servers, cannot see inside a host's PHP packages, and does not restart workers or block attack traffic. On shared hosting, the fix is entirely the host's job, and Safeguard would not have prevented PHP2Shell.

It helps with the parts you control:

• Images, SBOMs and repos. If you have moved sites into containers, safeguard scan --image <name> builds an SBOM of the image, including OS packages such as PHP, and matches it against vulnerability databases. safeguard scan --sbom <file> covers SBOMs a vendor gives you and safeguard scan --dir . covers a repository. Results land as JSON under ./output.
• Where a version lives. The platform shows which projects contain a given component and version, so an agency with many client builds can see which ones ship PHP 8.1.
• Gates. Policies and gates evaluated in the platform can stop an image that still carries a vulnerable PHP from being promoted.
• Changes with approval. On a VPS or build machine you control, the Safeguard CLI's assistant can run the checks in this post, edit a Dockerfile base tag and run tests, asking before each command under its default mode. The desktop and phone apps can send that work to a computer running the CLI and approve each step.

Reachability analysis does not lower the priority, because the bug fires before application code runs. Matching can lag a same-day advisory, and backports such as ea-php74 keep old version numbers, so confirm against the vendor's change log.

Zero-Day Discovery and Gold

Two other Safeguard capabilities are worth knowing about, with clear limits for this incident.

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. PHP core is a runtime, not a package in those ecosystems, so it is outside that scope.

Gold Open Source at gold.safeguard.sh is a free, no-login CVE intelligence directory with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh (paid) offers hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3+ and Sigstore-signed, with evidence pages, and an artifact loses its badge if it regresses. The habit Gold supports is the one that mattered on 21 October: pull patched, signed components from a curated source and rebuild fast.

To try Safeguard, download it at https://safeguard.sh/download and read the CLI docs at https://docs.safeguard.sh/docs/cli . For the wider month, see October 2026 security incidents and what would have helped.

FAQ

I am on shared hosting. Do I need to do anything?

Yes, but not the patch. Check your site's branch, move off 8.1 or older, and ask the host to confirm the patched build and the restart in writing.

My site shows PHP 7.4.33. Am I patched?

The number cannot tell you. cPanel, DirectAdmin and CloudLinux shipped 7.4 backports that keep the old string. Ask which package release is installed, and plan to move off 7.4.

Will WordPress automatic updates fix PHP2Shell?

No. They update WordPress, plugins and themes. PHP belongs to the server and to whoever runs it.

Can I protect my site with .htaccess or .user.ini settings?

Not reliably. php.net calls the INI mitigations partial and says not to rely on .user.ini or ini_set(). Leave mitigation to the host and focus on your branch.

I have a VPS with cPanel. Who patches?

On an unmanaged VPS you hold root, so you apply EA4 25.91 or later and restart PHP-FPM and Apache. On a managed plan the host usually does it; confirm.

Is the Imunify360 rule enough?

No. CloudLinux calls ruleset 8.83 interim. It blocks one known exploit shape on Apache, only logs on LiteSpeed, and does nothing where the WAF is off.

Should I rotate passwords and keys?

If your site sat on an unpatched internet-facing server, it is reasonable. The Hacker News reports the flaws can expose worker memory, which may hold database passwords and API keys. Rotate after the host confirms the patch, and at once if you see signs of compromise.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions. None shows PHP2Shell; each shows a flow you could apply to it.

The first is a CLI session that fixes a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, runs npm install and npm test with approval, and pushes nothing. For PHP2Shell on a VPS you run, you would ask the same assistant to list the ea-php or alt-php builds and bump the PHP base image tag in your Dockerfile, approving each command.

Click through it at your own pace, or open it full screen.

The second is the desktop app: the CLI session appears in the conversation list, you ask for work on your computer, pick the folder, and Approve or Deny each command and file edit until the upgrade is done and tests pass. An agency could use the same flow to run this post's version checks against a client project folder and approve each step.

Click through it at your own pace, or open it full screen.

The third is a real Android session: you send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. On a day like 21 October, a rebuild or restart on your build machine can wait for your approval while you are away from your desk.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• PHP news archive 2026: advance notice, advisory and 21 Oct releases (php.net)
• cPanel: EasyApache 4 change log 25 (release 25.91)
• cPanel docs: about PHP in EasyApache 4
• cPanel WHM API: php_get_vhost_versions
• CloudLinux status page: PHP critical security release incident
• CloudLinux blog: Imunify360 ruleset 8.83 and the PHP CVEs
• TuxCare docs: ELS for PHP
• Plesk support article on CVE-2026-109618 and CVE-2026-109619 (could not be loaded; details from search summaries)
• Plesk forum: ETA for critical PHP security updates
• Plesk docs: configuring PHP handlers
• Plesk docs: choosing the PHP handler
• Plesk CLI docs: php_handler
• DirectAdmin forum: Critical PHP updates (page 1)
• DirectAdmin forum: Critical PHP updates (page 3, staff release notes)
• DirectAdmin docs: CustomBuild overview
• DirectAdmin forum: overview of options.conf values
• The Hacker News: PHP2Shell, what actually protects you before the patch
• Help Net Security: PHP2Shell vulnerabilities patched
• Huntress: php2shell, leaked critical PHP vulnerabilities
• Unlimited Web Hosting: what the PHP2Shell flaws mean for your website
• Reclaim Hosting: PHP2Shell vulnerability

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.