Does Updating WordPress Fix PHP2Shell?

A WordPress update does not fix PHP2Shell. The vulnerabilities sit in PHP, which processes incoming requests before WordPress runs, and the fix requires a patched PHP runtime. Check Tools > Site Health > Info > Server today, then get your host to confirm the exact PHP package build, fixes for both CVEs, and restarted PHP workers.⁠¹⁠²

The complete PHP2Shell and Node2Shell guide covers the underlying vulnerabilities. For WordPress owners, the first question is who controls the PHP runtime, and whether that person has actually patched it.

PHP2Shell runs before WordPress can stop it

WordPress is an application written in PHP. Its login controls, security plugins and application code run after PHP has begun processing the request. That order matters for PHP2Shell.

Measured Datadog Security Labs reproduced CVE-2026-109618 on PHP 8.5.11 using an unauthenticated HTTP POST request. The request caused a memory allocation failure during PHP's input processing. During request cleanup, PHP mishandled partially initialized data and executed a command before the application script ran. The researchers demonstrated unauthenticated remote code execution (RCE) without needing a WordPress login or a vulnerable plugin.⁠³

The separate CVE-2026-109619 involves stale internal state surviving between requests handled by a PHP worker. Both flaws affect the runtime, although their exploitation conditions differ. PHP identifies several affected web-serving configurations and says its highest assessed risk is with Apache mod_php, where exploitation before application code was demonstrated.⁠²

Updating WordPress core cannot change PHP's internal request parser. Neither can a WordPress plugin or theme. WordPress.org confirmed on 21 October that no WordPress update was required or planned specifically for PHP2Shell.⁠¹

Check the running PHP build, not its version alone

Open WordPress Site Health under Tools > Site Health > Info > Server. Record the PHP version, then determine who installed and maintains that runtime. The displayed number is useful for inventory, but it may not prove the installation includes the fix.⁠¹

Managed WordPress hosting

With Managed WordPress Hosting, the provider normally controls the PHP packages. Reported GoDaddy stated that every PHP version on its Managed Hosting for WordPress platform had been patched by 19:30 UTC on 21 October. Its shared Web Hosting update also explained why a fixed PHP package might still show the previous version number: the vendor had backported the correction into a new package build.⁠⁴

That is a provider-specific statement, not proof for another host or an individual server. Ask your provider to confirm the exact build running your site, the advisory naming both CVEs, and whether all affected PHP workers were restarted. How to verify your host's PHP2Shell patch covers the evidence to request.

Shared hosting and self-managed servers

On shared hosting, the provider may deploy PHP through cPanel, Plesk or CloudLinux. On a VPS, dedicated server or container, your team may be responsible for updating the package and restarting or replacing workers. A command-line PHP installation can differ from the PHP handler serving WordPress, so check the web-facing runtime separately.⁠³

If your site uses PHP 8.1 or older, an upstream PHP release is not available for these flaws. Confirm an independently supported vendor backport or plan migration. Temporary controls for older PHP installations explains the incomplete mitigations available while an upgrade is arranged.

WordPress core has separate security fixes

A patched PHP runtime does not replace WordPress Core security updates. WordPress 7.1.4, released on 28 October, is the latest stable release listed by WordPress.org as of 5 November 2026. It addresses multiple separate vulnerabilities, including weaknesses involving the upgrade process, stored scripting and unpublished Customizer data.⁠⁵⁠⁶

One earlier issue is particularly important: CVE-2026-87902, fixed in WordPress 7.1.2 on 22 September. This was an unauthenticated Local File Inclusion (LFI) vulnerability in page-template resolution. WordPress's security announcement says an attacker could, under particular theme and server conditions, cause a readable local PHP file outside the active theme directories to be included. Under additional conditions, that could lead to remote code execution. It was a WordPress core vulnerability, not PHP2Shell.⁠⁷

WordPress 7.1.4 also fixed several Stored Cross-Site Scripting (XSS) issues and unauthenticated discovery of unpublished WordPress Customizer changesets. Those problems have different causes and consequences from PHP2Shell and CVE-2026-87902. A WordPress plugin or WordPress theme can introduce additional vulnerabilities independently, so update those components when security fixes are available.⁠⁵

A site can pass one row and fail another.

Automatic updates can be disabled by deployment settings

WordPress Automatic Updates are handled in part by the WP_Automatic_Updater class. Its source code contains conditions that can stop background updates even when a site looks healthy. File modifications may be disallowed, the installation may be in progress, or the updater may encounter a configuration or filesystem condition that prevents unattended changes.⁠⁸

Check wp-config.php and any configuration loaded alongside it. The AUTOMATIC_UPDATER_DISABLED constant can disable the automatic updater, while the automatic_updater_disabled filter can override that decision. Separate core, plugin and theme update settings also matter. Do not assume that receiving an update notification means an update was installed.⁠⁸

A version control checkout is another reason background updates may be skipped. The updater searches for .git, .svn, .hg and .bzr directories in relevant locations, including parent directories. Its automatic_updates_is_vcs_checkout filter can change that result. The open_basedir PHP restriction affects which directories the check can inspect; it is not itself proof that WordPress automatic updates are disabled.⁠⁸

Teams deploying WordPress through Git may intentionally disable automatic updates because releases are managed through a build pipeline. That is workable only if the pipeline actually ships security fixes. Review the installed version under Dashboard > Updates and compare it with WordPress.org's release archive.⁠⁶

How you'd notice

Measured A successful PHP2Shell request is not guaranteed to fail visibly. In Datadog's reproduction, execution returned HTTP 200 OK and left the Apache worker running. The researchers also documented a PHP error log entry reporting memory exhaustion with Unknown on line 0, indicating failure during request initialization. Neither an HTTP 200 response nor a memory error alone establishes compromise.⁠³

Correlate suspicious HTTP POST requests with PHP error logs, unexpected worker crashes and process activity. An unfamiliar shell launched by a web-server process is stronger evidence of execution than a response status alone. CISA added both PHP2Shell CVEs to its Known Exploited Vulnerabilities catalog on 26 October, confirming exploitation in the wild without establishing that any particular WordPress site was compromised.⁠⁹

Review WordPress for changes outside normal deployment activity: unfamiliar administrator accounts, modified core or plugin files, and unexpected PHP files under wp-content/uploads. With authorized server access, WP-CLI provides wp core verify-checksums for checksum verification against the official WordPress core files. It does not verify plugins, themes, uploads or database content, and a clean result cannot rule out compromise.⁠¹⁰

Do this

Do today

1. Open Tools > Site Health > Info > Server and record the PHP version serving WordPress.
2. Request your provider's exact PHP package build, confirmation of fixes for CVE-2026-109618 and CVE-2026-109619, and evidence that the updated workers are running.
3. Install the fixed runtime and restart or replace the affected workers if you manage the server. Test the site after the update.
4. Update WordPress Core to 7.1.4 using Dashboard > Updates, after taking a suitable backup.
5. Restrict public access to an unpatched deployment if no verified fix is available, and arrange a supported-version migration.

Do this week

6. Inspect wp-config.php, automatic-update filters and version-control checkout directories for conditions preventing background updates.
7. Update plugins and themes with available security fixes, and remove components that are no longer needed.
8. Run wp core verify-checksums using WP-CLI from the WordPress installation directory, with the correct version and locale, then investigate unexpected differences.
9. Review PHP error logs, suspicious web requests, web-worker process activity, administrator accounts and executable files under uploads.
10. Confirm with the host whether the separate PHP session-upload-progress mitigation remains necessary for CVE-2026-115560.

Can wait

11. Schedule migration away from an older PHP branch once a verified vendor backport is installed and immediate exposure is addressed.
12. Document the responsibilities for PHP, WordPress Core, plugins and themes so future security releases have a named owner.