Patching PHP2Shell on Shared Hosting: cPanel, Plesk and Managed WordPress

Who holds the wrench on a shared server

Shared hosting is an apartment building. You decorate your unit; the landlord owns the pipes. PHP is a pipe. The host compiles it, installs it, decides which versions appear on the menu and decides when the new builds arrive. On cPanel servers that usually means EasyApache packages (ea-php), often alongside CloudLinux alt-php builds. On Plesk, it means the PHP versions the host has installed through Plesk. Either way, the fix for PHP2Shell reaches your site only after the host puts it there.

What you control is the choice, and the choice matters twice this week: once to land on a patched build, and again because an old branch may never get one. Meanwhile the host's status page may glow green throughout. It is reporting that the servers are up. An unpatched server is also up. That is rather the problem.

cPanel: what MultiPHP Manager can and cannot tell you

In cPanel, open MultiPHP Manager. Each domain on the account has a row showing its PHP version. Tick the domain, choose a version from the menu, apply. According to cPanel's documentation, a version missing from the menu is either not installed or not available to your account, and a domain set to inherit uses the server's default PHP, which only the server administrator sets.

The catch is that the menu picks a branch, and the patch level inside that branch is whatever build the host has installed. Choosing 8.3 gets you 8.3.36 only if the host has shipped that build, or a patched alt-php or ea-php package. Treat the menu as the steering wheel, not the speedometer, and read the actual build with phpinfo or WordPress Site Health after you choose.

Two cPanel habits catch people out. Addon domains and subdomains can each carry their own version, so the main site being patched says nothing about the old microsite beside it. And some of the PHP project's interim settings must apply before PHP parses the request: the session upload-progress switch belongs in php.ini, an FPM pool or the server config, not `ini_set()` and not an FPM `.user.ini` file. Whether a panel edit reaches that layer depends on how the host set PHP up, so ask the host to set it server-side.

Plesk: one domain card, one PHP decision

Plesk puts the choice on each domain. Go to Websites & Domains, pick the domain and click PHP. Choose a PHP version and a handler type from the menus, then save. The current version also shows next to the PHP icon on the domain card. Plesk's own documentation says that if the version you want is missing, you contact your hosting provider, and that depending on the subscription you may be able to change some of these settings, or none of them.

The same rule applies as on cPanel: the menu offers only what the host installed. If the patched builds are not on the server, every option on the list is an old one. If the list stops at 7.4 or 8.0, the problem is bigger than a patch, because those branches get no release from the PHP project; PHP past end of life covers what that means. One more note for the conversation with the host: the PHP project rates the risk highest for mod_php, so if your handler is an Apache module, mention it.

Managed WordPress hosts: their patch, your proof

Managed WordPress hosting takes away the panel and most of the choices. The host runs PHP, updates it and usually picks the branch, sometimes with a selector in its own dashboard. That is convenient this week, provided the host has done it. It is also opaque, so the proof matters more here, not less. And an up-to-date WordPress does not count as proof: the bug sits in PHP, below the CMS, as the page on WordPress, Drupal and Joomla explains.

Check from inside WordPress: Tools > Site Health > Info > Server shows the PHP version and SAPI the site is running. Compare the version with the fixed releases. If the host offers a branch selector and you sit on 7.4 or 8.0, resist the urge to jump straight to 8.4 on the live site at four in the afternoon. That jump is where old themes and builders fail, covered further down. If the host offers a staging copy, try the new branch there first.

The note to send your host, word for word

Hosts answer tickets better when the question cannot be answered with "we take security seriously." Send something close to the note below by ticket or email, so there is a written record, and keep the reply. Change the domain, keep the numbers.

Point three matters even after the patch. The PHP project's October 23 follow-up, CVE-2026-115560, needs an unusual application setup, and the project suggests leaving upload progress off until its next regular release. On shared hosting that is a server setting, so it is the host's switch to flip. If the reply to point one is vague ("we keep all software up to date"), send it back with the version numbers in bold.

Checking the host's work in ten minutes

A written answer is half the record. The other half is your own look, which takes less time than the ticket did. Do it for every site on the account, not only the one that brings in the money.

1. 1

   Read the build, not the branch

   Open WordPress Site Health or a temporary phpinfo file on each site and note the full version. Delete the phpinfo file as soon as you have the number. The version must match a fixed release or the backport the host named.

2. 2

   Check every domain on the account

   Addon domains, subdomains and the forgotten staging copy can each run their own PHP. The one unpatched site on the account is the one that matters.

3. 3

   Confirm the settings the host promised

   In phpinfo, find `session.upload_progress.enabled` and confirm it reads Off if the host said it set it. Promises about settings are easy to check, so check them.

4. 4

   Click through the pages that earn money

   Home page, contact form, checkout or booking, the login and the admin. A PHP change shows its damage in forms and carts before anywhere else.

5. 5

   Write down the before and after

   Old version, new version, date, and who confirmed it. You will want that record the next time a vulnerability arrives with a name and a logo.

What snaps when a site jumps from 7.4 to 8.2 or newer

Moving within a branch, say from an older 8.3 build to 8.3.36, is a bugfix release and seldom breaks anything. The trouble starts when a site on 7.4 or 8.0 has to jump, because its old branch will never get a fix from the PHP project. PHP 8 tightened rules that old code leaned on, and code written for PHP 7 tends to fail loudly rather than gracefully.

• Removed functions. PHP 8.0 removed `create_function()` and `each()`. Old themes and plugins that still call them stop with a fatal error, often a white screen.
• Warnings promoted to errors. In PHP 8.0, undefined unqualified constants and invalid types passed to `count()` throw errors instead of warnings, which turns a sloppy line into a theme PHP error.
• Bundled page builders. A theme that ships its own copy of a builder updates it on the theme's schedule, and WPBakery on PHP 8 is a familiar casualty.
• Aging framework themes. Older Genesis child themes and hand-edited functions files collect Genesis PHP errors after the jump.
• Deprecation noise in 8.2. Creating dynamic properties is deprecated in PHP 8.2. It warns rather than breaks, but it fills logs, and it shows on screen if the host displays errors publicly.

The safe order: full backup, switch the branch on a staging copy, fix what breaks, then switch the live site. If the live site broke already, the $249 repair for a site that broke after a PHP update puts it back online first and then finds the cause. A theme, builder or plugin conflict is $199 and a single WordPress error is $149, all paid on the page, with work starting within one business day of payment.

When the host is slow, silent or stuck on old builds

Some hosts patched within hours. Some will take longer, and a few offer nothing newer than 7.4. If the reply is slow, apply what you can reach from the interim settings, ask the host to set the server-side ones, and if a firewall service already sits in front of the site, check whether it has a PHP2Shell rule. None of it replaces the patch. The PHP project says there are no complete mitigations, and it means it.

If the host cannot ship a fixed build this week, the honest answer is to leave: for a plan or host that runs a fixed release, or for a setup where PHP is off the public internet entirely. DataCram's PHP2Shell emergency fix handles the first, including the move, the testing and the check for signs of compromise. The second is a Next.js front end with WordPress kept private. And if the host was already slow before any of this, the move may be overdue anyway.