PHP2Shell: Critical PHP Vulnerabilities and How to Fix Them

Two critical vulnerabilities in PHP could allow attackers to execute code on vulnerable servers without authentication. Tracked as CVE-2026-109618 and CVE-2026-109619, these vulnerabilities were addressed in security releases published on October 21, 2026.

Update, October 26, 2026: a separate PHP vulnerability, CVE-2026-115560 (session upload progress), was announced on October 23. The October 21 releases described in this article do not address it. The PHP security announcements and the Canadian Centre for Cyber Security alert say that, until a security release is available, setting session.upload_progress.enabled to 0 is a recommended mitigation. Check the PHP security announcements for the current status.

The pair is called PHP2Shell by security researchers and some advisories (for example Wiz Research and the Canadian Centre for Cyber Security); it is not an official PHP project name. The vulnerabilities affect PHP's runtime, which means updating WordPress, another CMS, or a website plugin alone will not fix a vulnerable PHP installation.

If you manage a PHP website, verify your server's patch status and apply the appropriate security updates as soon as possible.

What Are the PHP2Shell Vulnerabilities?

PHP2Shell refers to two critical vulnerabilities in PHP's internal request-processing behavior. Under certain conditions, these flaws can cause PHP to handle internal memory or request state incorrectly.

CVE-2026-109618: Remote code execution through out-of-memory handling

PHP has internal mechanisms for handling situations in which memory is exhausted. This vulnerability involves an interruption during request processing that can leave internal request data only partially initialized.

During cleanup, PHP may then treat that invalid data as valid, potentially leading to memory corruption and remote code execution.

CVE-2026-109619: Remote code execution through stale internal state

This vulnerability involves internal request state that can remain accessible after the memory backing it has been freed.

A later request handled by the same worker may use this stale state before normal initialization resets it. Under the right conditions, this can also lead to remote code execution.

Both vulnerabilities are serious because an attacker may be able to trigger them without logging in or exploiting a specific CMS plugin. The precise exposure depends on the PHP runtime, server configuration, and whether the relevant security patches have been applied.

For technical details, refer to the official PHP security announcement.

Exploitation status

When the Canadian Centre for Cyber Security first published its alert on October 21, 2026, it reported that a proof-of-concept was publicly available and that it had not identified active exploitation, while warning that this can change quickly. Its later update (Update 2) says open-source reporting indicates that both vulnerabilities are being exploited in the wild, and that on October 26, 2026 CISA added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog. The security firm watchTowr says its honeypot network observed both vulnerabilities being exploited in the wild from October 21, 2026. Google Cloud's response post also describes public proofs of concept and monitoring for probing activity. Treat unpatched, internet-facing PHP as urgent.

Which PHP Versions Are Affected?

The vulnerabilities affect upstream PHP versions from 5.4 through 8.5.11. The PHP project released fixes for these supported branches:

PHP 8.1 and earlier have reached end of life and no longer receive regular security updates from the PHP project. According to the PHP security announcement, its security team provided minimal source backports for PHP 7.4, 8.0 and 8.1 (in separate source branches) to help people building from source or without access to an LTS vendor. The announcement lists no fixed release for those branches.

However, this does not automatically mean that every older installation remains unpatched. Some Linux distributions, hosting providers, and long-term support vendors provide backported security fixes for older PHP packages.

Do not judge patch status by the version number alone. Check the security advisory for your operating system, hosting provider, or PHP package source. If a verified patch is unavailable, prioritize upgrading to a supported PHP branch.

You can find the official release information in the PHP security announcements.

How to Fix PHP2Shell on cPanel

If your website runs on cPanel, updating PHP requires more than selecting a version in MultiPHP Manager.

MultiPHP Manager controls the PHP version assigned to a domain. The server administrator separately manages PHP packages and other components that may require security updates.

If you manage the cPanel server

1. Update cPanel and WHM. Check the official cPanel advisory and install the applicable patched release.

2. Update EasyApache 4 packages. Ensure that every installed PHP package used by your websites has received the appropriate security fix.

3. Check every PHP version in use. A server may have several PHP versions installed, and different domains may use different versions.

4. Restart services if required. Follow the package and hosting documentation for any necessary service restarts.

5. Verify the web-serving runtime. Confirm that the PHP handler processing actual website requests is patched.

For the supported branches, the EasyApache 4 packages should be at least the upstream fixed versions:

For PHP 8.1, 8.0 and 7.4, support and patch availability depend on the applicable vendor or extended-support arrangement. Backported fixes may not change the version number, so check the cPanel advisory rather than relying on the version number.

Check the cPanel advisory for the patched cPanel & WHM releases that apply to your installed version.

Read the official cPanel PHP2Shell security advisory before making changes.

If you use shared hosting

You usually cannot update the server's PHP packages yourself. Contact your hosting provider and ask them to confirm:

• Whether CVE-2026-109618 and CVE-2026-109619 have been patched.

• Whether the PHP runtime serving your website is covered by the fix.

• Whether you need to change your domain's PHP version or take any additional action.

If you can access MultiPHP Manager, check your domain's selected version, but do not assume that this alone proves the underlying server is secure.

How to Update PHP on a VPS or Dedicated Server

If you manage your own VPS or dedicated server, first identify how PHP is installed and how your web server executes PHP code.

Your setup may use PHP-FPM, Apache with mod_php, CGI, LiteSpeed, containers, or another runtime configuration. The correct update procedure depends on the environment.

Follow these steps:

1. Identify the PHP runtime. Check your operating system, package manager, web server, PHP handler, and any container images.

2. Check the vendor advisory. Use the instructions provided by your Linux distribution or PHP package maintainer.

3. Install the security update. Upgrade to a fixed upstream release or install a vendor package that explicitly includes the security fix.

4. Rebuild containers if necessary. If PHP is included in a Docker image or another deployment artifact, rebuild it using a patched runtime and redeploy.

5. Restart or reload services when required. Follow the instructions for your specific deployment.

6. Verify the result. Check the PHP runtime that actually handles website requests, not just the command-line executable.

For example, running php -v displays the version used by the command-line PHP executable. It does not necessarily show the version used by PHP-FPM or Apache.

If you have several applications, servers, or containers, verify each relevant runtime rather than assuming that updating one instance secures everything.

What If Your Hosting Provider Has Not Released a Patch?

Contact your provider and request a clear remediation timeline. Prioritize internet-facing applications and systems that process untrusted requests.

The PHP project states that there are no complete mitigations for these vulnerabilities. Updating to a fixed release is the only safe choice. Its advisory lists a few partial configuration measures, but says they do not make an installation safe, so do not use them as a substitute for the update.

A web application firewall, request filtering, or other defensive controls may help reduce exposure, but they are not substitutes for patching.

If a critical service cannot be patched promptly, consult your hosting provider or security team about temporarily isolating it from public access until a fix can be applied. This may mean restricting network access or taking the affected service offline.

For additional guidance, see the Canadian Centre for Cyber Security advisory.

What If Your Website May Have Been Compromised?

Applying a security patch fixes the known vulnerability in the updated runtime, but it does not automatically remove malicious files or undo actions an attacker may already have taken.

If you suspect exploitation, take the following steps:

• Preserve logs. Keep relevant web server, application, system, and authentication logs for investigation.

• Check for suspicious changes. Review unexpected files, administrative accounts, scheduled tasks, processes, and outbound network connections.

• Review application and server integrity. Look for unauthorized modifications to application files, server configuration, or executable scripts.

• Rotate potentially exposed credentials. Change affected passwords, API keys, and other secrets from a clean, trusted environment.

• Restore carefully if necessary. Use a known-good backup only after identifying and addressing the cause of compromise.

• Seek professional help when needed. If you cannot establish the extent of a potential incident, contact your hosting provider or an incident-response specialist.

Do not assume that a website is clean simply because it loads normally after an update.

PHP2Shell Security Checklist

Use this checklist to track your remediation:

• Identify every server, website, container, and environment running PHP.

• Check the PHP version and security status for each runtime.

• Review the relevant hosting provider or operating-system advisory.

• Install the appropriate security patches or redeploy patched runtime images.

• Update cPanel and EasyApache packages where applicable.

• Verify the PHP runtime that actually serves web requests.

• Investigate suspicious activity if compromise is possible.

• Plan to migrate unsupported PHP installations to a supported, patched branch.

Official PHP2Shell Security References

For the most reliable technical information and environment-specific instructions, start with these sources:

• PHP: Official security announcements

• cPanel: Critical PHP security release

• Google Cloud: Responding to CVE-2026-109618 and CVE-2026-109619

• Canadian Centre for Cyber Security: Critical PHP vulnerabilities

Last verified: November 2, 2026, against the PHP security announcements, the Canadian Centre for Cyber Security alert (updated October 27), the Google Cloud post and watchTowr's report. The cPanel advisory could not be re-read during this check, so open it directly for the current package and release information.

Final Thoughts

PHP2Shell is a reminder that website security depends on more than application code. The PHP runtime, server configuration, hosting environment, and patching process all play an important role.

If you manage a PHP website, verify the security status of the runtime serving real traffic and apply the appropriate update. If your hosting provider manages the server, ask them to confirm that the fix has been applied.

Do not rely on the version label alone. Verify the patch, and investigate if you suspect a compromise.