How to Verify Your PHP2Shell Patch Beyond php -v

**php -v cannot prove your website is patched against PHP2Shell. The PHP in your terminal may differ from the runtime serving web requests, and vendors can fix vulnerabilities without changing the upstream version number.⁠¹⁠² Identify the PHP build serving each site, match its exact package to a vendor security advisory, and confirm that all affected PHP workers were restarted after the update.**

PHP2Shell is the name for two critical vulnerabilities in the PHP Runtime, the engine that executes PHP applications. Each has a Common Vulnerabilities and Exposures (CVE) identifier. The complete PHP2Shell and Node2Shell guide covers the defects themselves. This article covers how to establish whether your installation has actually received the fixes.

The PHP in your terminal may not serve your website

The PHP Command-Line Interface (CLI) is one way to run PHP. Web-Serving PHP is another. On a server with multiple installations, the shell's default binary can belong to a different version, repository or configuration from the one accepting HTTP requests.

Running php -v shows a PHP Version String for the command-line binary. Running php -i reports that binary's configuration. Neither establishes which runtime your application uses. Red Hat explicitly warns that command-line configuration output cannot verify settings active in a web request.⁠²

PHP lists PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed among affected web-serving integrations. It considers mod_php the highest-risk configuration because researchers demonstrated exploitation before application code ran. A PHP-FPM deployment may have different exploitation conditions, but it still needs a fixed runtime.⁠¹

Start with the web server's PHP handler configuration or your hosting panel. If neither identifies the active binary, an administrator can use a temporary, access-restricted phpinfo() page through the affected website to inspect the web runtime. Remove it immediately after checking. Publicly accessible PHP configuration details create unnecessary information exposure.

The web server process and PHP handler need to agree with the package you intend to verify. A correct CLI result attached to the wrong executable settles nothing.

A patched PHP build can keep an old version number

An Upstream PHP Release comes directly from the PHP project. Its 21 October 2026 Security Patch releases fixed both PHP2Shell flaws in 8.5.12, 8.4.27, 8.3.36 and 8.2.35.⁠¹

A Vendor Security Backport works differently. A distributor applies the correction to an older package branch while retaining its existing PHP version number. PHP also published a minimal Source Code Backport for 7.4, 8.0 and 8.1, intended to help supported distributors and people compiling their own PHP. These were patches, not new official releases for those end-of-life branches.⁠¹

Reported Ubuntu's 21 October notice lists 8.3.6-0ubuntu0.24.04.13 as the fixed PHP 8.3 package for Ubuntu 24.04 LTS. That installation may still identify itself as PHP 8.3.6. CloudLinux separately lists alt-php85 build 8.5.11-5 as fixed despite PHP's upstream first-fixed version being 8.5.12.⁠³⁠⁴

A lower version number can therefore be the fixed build.

For reliable PHP Patch Status and Patch Verification, collect four pieces of evidence:

1. A Vendor Security Advisory naming the fixes applicable to your PHP package.
2. The installed Package Build Identifier, including its distribution-specific release suffix.
3. A Package Changelog or release record connecting that build to both CVEs, or confirming an upgrade to an upstream fixed release.
4. Confirmation that the patched binary is serving your site and its workers were replaced after installation.

The order matters. A package date alone is weaker than a security record identifying the actual fixes. A changelog without a matching installed package proves availability, not deployment.

Hosting panels and Linux packages need different checks

Build a Software Package Inventory that identifies each PHP handler, the account or service using it, the package supplier and the installed release. Do not assume the system's default PHP covers every site.

cPanel and Plesk

cPanel and WebHost Manager (WHM) have separate management responsibilities. cPanel's MultiPHP Manager shows which PHP version a domain is assigned, while EasyApache 4 manages relevant PHP packages and web-server components. The selected version does not by itself identify the complete patched package release.⁠⁵

Reported cPanel's EasyApache 4 release 25.91 on 21 October updated PHP 8.2 through 8.5 to the upstream fixed versions and backported both fixes to its PHP 7.4, 8.0 and 8.1 packages. It did not provide the same fixes for its PHP 7.3-and-older packages. cPanel also updated the PHP used by its management software, which is separate from the runtime serving customer sites.⁠⁵

Plesk's Linux advisory lists fixed builds of PHP 7.4.33, 8.0.30 and 8.1.34 with a 21 October build date, alongside the normal upstream fixed versions. Those older version strings also existed before patching. Confirm the package build and Plesk's matching security record, not the date in isolation.⁠⁶

How to verify your hosting provider's patch covers the evidence to request from support.

Ubuntu, RHEL and CloudLinux

On Ubuntu, APT Package Management records the full package version, including distribution revisions. Ubuntu's 21 October advisory provides this inventory command for installed PHP interpreter packages:

# Ubuntu: inventory PHP interpreter packages
apt list '?installed ?name(^php[0-9.]+$)'

Use the package information as a starting point, then identify the installed web-handler component—such as PHP-FPM or the Apache PHP module—and compare its release against Ubuntu's published fixed package for that OS version.⁠³

For RPM Package Management on RHEL-family systems, identify the installed PHP package and compare it with the applicable vendor advisory. CloudLinux's official instructions include checking its release package and inspecting the relevant RPM changelogs. Its alt-php, ea-php and operating-system PHP packages may come from different repositories, so a successful update of one family does not establish coverage for the others.⁠⁴

An empty CVE search is not always proof that a package lacks a fix. CloudLinux notes that some packages rebased directly onto fixed upstream versions do not repeat the CVE identifiers in their changelogs. Use the documented fixed build threshold for that repository.⁠⁴

Containers and build systems require separate verification

Installing fixed PHP packages on the host does not update PHP embedded inside Docker or another container runtime. A Container Image can retain the affected runtime even after the underlying host has received its security updates.

Red Hat advises rebuilding customer images based on updated Red Hat or Universal Base Images. A Container Rebuild must actually include a fixed PHP dependency; rebuilding against a stale pinned base image may reproduce the vulnerable installation. Container Redeployment must then replace running instances. For an orchestrated application, check that each Kubernetes Pod is running the newly built image rather than an older deployment revision.⁠²

The same inventory problem reaches development infrastructure. A Continuous Integration (CI) Runner may have PHP installed for tests or builds even when it serves no public requests. That alone does not establish remote PHP2Shell exposure, but the image and tooling still belong in the patch inventory, particularly where artifacts are reused in production. cPanel specifically advises checking CI runners and tools embedding PHP.⁠⁵

Architecture matters too. cPanel warns that some repositories delivered fixes for AMD64 Architecture before ARM64 Architecture. Verify fixed packages separately for each architecture actually deployed, including container-image variants. A successful deployment on one architecture does not prove that every fleet node received the same corrected binary.⁠⁵

Checking PHP inside Docker, FrankenPHP and PaaS environments covers these deployments in more detail.

How you'd notice

A patch-status investigation may begin with a healthy website. PHP2Shell exploitation can happen during request processing before application code runs, so normal application logs and responses may not tell the full story. Look for unusual memory-exhaustion errors, request-processing failures, repeated PHP worker crashes and unexpected activity initiated by a web-server or PHP process.⁠¹⁠²

A memory error alone does not prove exploitation.

Reported CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog on 26 October 2026. That establishes exploitation in the wild, not that your server was compromised. Preserve relevant logs and process telemetry when reviewing suspicious events, especially if the server remained unpatched after disclosure.⁠⁷

A public PHP version scanner may also misclassify a correctly backported package. Treat its warning as a reason to investigate, then compare the installed package with the vendor's fixed-build record. Do not execute public exploit code against a production site as a substitute for package verification.

Confirm the build and restart every PHP worker

Installing a package does not necessarily replace every PHP Worker Process already running. A PHP Worker Restart ensures the fixed executable is loaded, while a Service Reload can leave existing workers alive. Red Hat's PHP2Shell bulletin explicitly requires restarting every worker after its mitigation settings change and warns that a reload is insufficient.⁠²

For Red Hat's documented default configurations, the relevant alternatives are:

# RHEL 7 with the default Apache mod_php setup
systemctl restart httpd

# RHEL 8 and later with the default PHP-FPM setup
systemctl restart php-fpm

These are configuration-specific examples from Red Hat, not universal commands. Use the service name and restart procedure for the PHP handler actually serving your application. For LiteSpeed, containers, cPanel or custom PHP-FPM installations, follow the relevant vendor instructions and confirm that no old worker is still accepting requests.⁠²⁠⁴

Do today

1. Identify the web-serving PHP handler for every application, including the package source and exact build.
2. Compare each build against the upstream fixed release or its vendor's security backport record for both PHP2Shell CVEs.
3. Install missing security updates through the appropriate vendor-supported package mechanism.
4. Restart or replace the affected PHP workers and verify the running service uses the updated build.
5. Request written patch confirmation if a shared or managed host controls the runtime.

Do this week

6. Rebuild container images and redeploy running containers or pods with verified fixed PHP packages.
7. Check AMD64 and ARM64 deployments, alternate PHP handlers, CI runners and internal tools.
8. Review web logs, PHP errors and process activity from before the patch for possible exploitation.
9. Document package build identifiers, advisory references and worker restart evidence in your inventory.

Can wait

10. Schedule migration from an end-of-life PHP branch only after you have confirmed a working vendor backport and addressed immediate exposure. Without that fix, migration remains urgent.
11. Review PHP's separate CVE-2026-115560 advisory and its session-upload-progress mitigation when its next stable fix is available. The 21 October PHP2Shell releases did not address that third flaw.⁠¹

The PHP2Shell server patching guide covers applying updates to common Linux web-server configurations.