PHP2Shell: How to Patch Your Website and Check for Signs of Compromise

Published October 21, 2026

Two critical vulnerabilities in PHP—the software that runs WordPress and many other websites—require immediate attention from website owners and hosting providers.

Known together as PHP2Shell, the vulnerabilities can allow attackers to execute code on an affected server without logging in. PHP released emergency security updates on October 21, 2026. If your website uses PHP, confirm that your hosting environment has received the fix. PHP’s official announcement

What are the vulnerabilities?

Both issues involve how PHP handles memory when processing a request goes wrong.

These vulnerabilities are in PHP itself. Updating WordPress, a theme, or a security plugin does not install the PHP runtime fix.

PHP’s security announcement includes PHP-FPM, Apache with mod_php, CGI, FrankenPHP, and LiteSpeed among the environments that need attention. Exploit conditions vary, but switching handlers should not be treated as a substitute for patching. PHP’s affected-environment guidance

Which PHP versions contain the fixes?

As of this article’s publication, the upstream fixed releases are:

Some Linux distributions and long-term support providers backport security fixes into packages with older-looking version numbers. Verify the complete package revision against the provider’s advisory.

PHP 8.1 and older require particular attention: confirm a documented vendor fix or arrange an upgrade. PHP’s release and backport guidance

Who is responsible for updating PHP?

Your hosting arrangement determines who can install the fix.

Plesk and cPanel are control panels. They provide tools for managing websites and server software. Having access to one does not necessarily mean you have permission to install server updates.

GoDaddy, Kinsta, and other hosting providers sell different levels of service. A shared hosting account, managed WordPress plan, and self-managed virtual server may place very different responsibilities on the customer.

The useful question is: Who maintains the PHP installation serving this website, and have they confirmed these specific fixes?

A dashboard showing “PHP 8.3” identifies a branch. It does not, by itself, establish that the required security update is installed.

How to patch your website

Ask your hosting provider or server administrator to:

1. Inventory the PHP versions in use. Include live websites, staging environments, subdomains, and other PHP applications.
2. Install the fixed packages. Updating within the current supported branch usually involves less compatibility risk than changing branches during an emergency.
3. Restart or replace the affected PHP workers. Installing a package does not establish that every running process has loaded the updated software.
4. Verify the runtime serving each website. A command-line PHP installation can differ from the one handling web traffic.
5. Test important functions. Check logins, contact forms, uploads, scheduled jobs, and checkout where applicable.

Plesk

For a Plesk server administrator, the dashboard update path is generally Tools & Settings → Updates → Update Components.

Install the available PHP component updates, then review the PHP version assigned to each domain under Websites & Domains → PHP Settings. Updating only the Plesk panel does not necessarily update its PHP components. Plesk update instructions

If you only have subscription or customer access, contact the server administrator or hosting provider. Selecting a different installed PHP version is separate from installing patched server packages.

cPanel and WHM

In cPanel, MultiPHP Manager lets an account owner select from PHP versions already installed and made available by the server administrator. Server-level PHP management is handled through WHM and EasyApache 4. cPanel’s MultiPHP Manager documentation

Ask the administrator to confirm the installed PHP package builds and apply the required updates. cPanel documents updates to existing PHP installations, but you should verify that the relevant update actually completed. cPanel’s PHP update explanation

Changing a domain’s selection from one branch to another does not prove that either branch contains the fix.

GoDaddy

GoDaddy’s instructions differ by product: Web Hosting with cPanel, Windows Hosting with Plesk, and Managed Hosting for WordPress have separate PHP management procedures. GoDaddy’s PHP update guide

For its cPanel hosting product, GoDaddy documents the version selector under Manage → Settings → Server Settings → PHP Version. GoDaddy’s cPanel instructions

Use the instructions for your actual hosting product, then ask support to confirm the full PHP build or vendor backport addressing both CVEs. Don’t assume that selecting the highest option in a menu completes that verification.

Other shared hosts and managed WordPress platforms

With shared hosting, your provider generally controls which server packages are available. With managed WordPress hosting, ask support to confirm the patch status of both live and staging environments.

A useful support request is:

“Please confirm that the PHP runtime serving my websites includes fixes for CVE-2026-109618 and CVE-2026-109619, identify the installed version or backported package revision, and confirm that affected workers have restarted.”

Virtual servers, cloud servers, and containers

If your business or agency manages the operating system, it needs to arrange the package update and service restart. For container-based deployments, rebuild from a verified patched PHP image and replace the running containers.

Check every instance serving traffic. Updating one server or changing a deployment file can leave older processes or replicas running.

What if the update fails?

Investigate the specific error. A missing package-signing key, for example, can prevent an available update from installing. Correct the trust configuration using vendor guidance rather than disabling signature verification.

If an immediate update is impossible, discuss temporary access restrictions with your provider. PHP states that configuration changes do not provide a complete generic mitigation for the stale-state vulnerability. An ordinary WordPress maintenance page may also leave PHP processing requests underneath it. PHP mitigation guidance

What protection does Cloudflare provide?

Cloudflare reports that it deployed PHP2Shell protections for customers using its free or paid web application firewall, with default protection beginning at 03:02 UTC on October 21. It also reports observing attack traffic targeting customers.

Its response includes “full transaction detection,” which considers signals from both a request and the application’s response. This helps identify suspicious behavior that request inspection alone may miss. Read Cloudflare’s PHP2Shell article

That provides a valuable additional layer, but the PHP update remains necessary.

Have your administrator verify that relevant traffic passes through the intended protection, review security events, and check whether alternate hostnames or direct server access leave another route to the application. A Cloudflare account alone does not establish that every application endpoint is covered.

What about websites hosted at Kinsta?

Kinsta documents an infrastructure-level Cloudflare integration that includes firewall and DDoS protection for its managed WordPress hosting. Kinsta’s Cloudflare integration

Kinsta also announced Vulnerability Protection powered by Patchstack on October 9, with rollout to existing sites beginning October 14. The service targets known vulnerabilities in WordPress core, plugins, and themes. Kinsta’s announcement

For a Kinsta-hosted site:

• Ask support to confirm that the PHP runtime includes fixes for both PHP2Shell CVEs.
• Check MyKinsta → your site → Info for the Vulnerability Protection status.
• Continue updating WordPress, plugins, and themes.
• Review live and staging environments.

Kinsta’s documentation explains that Vulnerability Protection prevents certain attacks; it does not scan for or remove existing malware. Its documented WordPress coverage should not be treated as confirmation that an underlying PHP vulnerability is patched. Kinsta protection details

At publication, we have not located a Kinsta advisory specifically confirming its PHP2Shell patch deployment. Its published security features provide useful context, while confirmation for an individual environment should come from Kinsta support.

How to check for signs of compromise

Patching closes the vulnerability. It does not remove an attacker’s existing access or undo information exposure.

A useful review combines several kinds of evidence.

Review logs around the exposure window

Look for unusual requests followed by memory-limit errors, repeated HTTP 500 responses, unexpected PHP worker restarts, or crashes.

Researchers also identify malformed or unusually large PHPSESSID response cookies as a potential signal. Standard access logs may not capture the request bodies or response headers needed to investigate this fully. These are investigation leads, not proof of successful exploitation. Wiz’s detection guidance

Check dates carefully. Searching archived logs can return years of ordinary application errors.

Inspect changed files

Review recent changes to PHP files, wp-config.php, .htaccess, .user.ini, and must-use plugins. Investigate unfamiliar executable files in upload and temporary directories.

Some plugins create legitimate PHP-named logs or placeholder files. A recent timestamp can also reflect an authorized update. Compare suspicious files with trusted backups or official release packages before drawing conclusions.

Avoid sharing complete configuration files publicly; they may contain database passwords, API tokens, and security keys.

Check accounts and scheduled tasks

Review WordPress administrators, hosting accounts, SSH access, cron jobs, and system timers. Investigate unfamiliar users and commands that download or execute unexpected code.

A strange-looking task name may belong to legitimate software. Inspect what it runs before disabling it.

Run a malware scan

Use an established scanner and review its findings. Preserve suspicious files and logs before automatic cleanup where practical.

A clean scan adds confidence, but it cannot prove that no exploitation or data exposure occurred. If you find convincing evidence of compromise, involve your provider or an incident-response specialist. Confirmed server compromise may require rebuilding from trusted sources. Plesk’s response guidance

Get a verified answer about your website

A complete response should establish which PHP packages were installed, whether running processes loaded the update, and what the follow-up checks found.

Whether your website runs on Plesk, cPanel, GoDaddy, Kinsta, or another platform, someone needs to own those checks and document the result.