PHP2Shell Vulnerability: How to Check and Secure Your WordPress Site

Updated October 22, 2026. This guide is for site owners and administrators; it does not establish whether any particular website has been compromised.

PHP2Shell is the name given to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, disclosed on October 21, 2026. Both can permit unauthenticated remote code execution under vulnerable conditions. If you run WordPress, Drupal, Joomla, or another PHP application, your first priority is to identify the PHP runtime actually serving your site and have it updated to a fixed, supported build. Updating WordPress plugins alone does not repair the PHP runtime.

The PHP project released fixes in 8.2.35, 8.3.36, 8.4.27, and 8.5.12. These are minimum fixed upstream versions within their respective branches, not instructions to downgrade a newer installation. Older unsupported branches need migration to a supported release or a vendor-supported, explicitly backported security fix. Confirm with your hosting provider rather than assuming a version string tells the whole story. PHP release announcement · NHS England alert.

What happened on October 21?

The PHP Security Team issued emergency updates for two vulnerabilities affecting PHP’s handling of request memory and cleanup. CVE-2026-109618 involves an out-of-memory error path; CVE-2026-109619 involves state that may point to memory already freed. Both have a reported CVSS v4.0 score of 9.2. Researchers demonstrated exploitation, but that is not proof that every vulnerable server has been attacked. NHS England · Canadian Centre for Cyber Security.

A crucial distinction: these bugs exist beneath WordPress itself. A request may be processed by PHP before WordPress authentication, plugin security checks, or theme code gets a chance to intervene. A fully updated WordPress installation may therefore still be exposed if its PHP runtime remains vulnerable. Datadog Security Labs.

Fixed PHP versions: quick reference

Important for Linux users: some distributions backport security fixes without changing the major or minor PHP version in the same way as upstream PHP. Check your distribution’s package security advisory and installed package revision. Ubuntu, for example, published an advisory about its fixed packages. Ubuntu.

Step 1: Find which PHP version your WordPress site actually uses

Option A: WordPress dashboard

Sign in to your WordPress administrator area, then open Tools → Site Health → Info → Server. Find the PHP version entry. Record the exact version and, if available, the server API. The dashboard value describes the runtime handling that WordPress installation; it is generally more relevant than a shell version on a multi-PHP server. If Site Health is unavailable, ask your host to identify the PHP version serving the domain.

Option B: cPanel or managed hosting

Open your hosting dashboard and look for MultiPHP Manager, Select PHP Version, or a similarly named PHP configuration area. Locate the specific domain or subdomain, not just the account-wide default. Hosting panels differ: some selectors change the version immediately, while others only report it. Compare the dashboard value with WordPress Site Health after changes.

Option C: VPS or dedicated server

An administrator can run php -v in a shell, but CLI PHP may differ from the PHP-FPM pool or web-server module that serves HTTP requests. Inventory the active PHP-FPM services, configured pools, web-server integration, and container images. Confirm the live web runtime through trusted server configuration or application diagnostics. Avoid uploading a publicly accessible phpinfo() page; it can reveal sensitive configuration details. If you temporarily create a diagnostic endpoint, restrict access and remove it immediately afterward.

Step 2: Decide what your result means

Example 1: WordPress reports PHP 8.4.26. That is below the upstream fixed 8.4.27 release. Arrange an update to at least 8.4.27, or ask the vendor to document a backported fix. Do not assume a WAF makes delaying the patch safe.

Example 2: WordPress reports PHP 8.3.36. That meets the published upstream fixed version threshold for the 8.3 branch. Confirm the host actually deployed the corrected build and check other sites, cron jobs, and separate PHP pools.

Example 3: cPanel shows PHP 8.4.27, but WordPress shows PHP 8.3.35. The domain may be using a different PHP handler, pool, or hosting setting. Treat the live WordPress reading as a reason to investigate rather than assuming the panel’s global version protects the site.

Example 4: A distribution reports a vendor-maintained PHP package with a lower-looking upstream number. Request the exact security advisory and package revision confirming both CVEs are fixed. Upstream threshold comparisons alone cannot validate vendor backports.

Step 3: Patch safely on shared hosting

1. Take a verified backup of the site files and database; know how to restore it. A backup does not remove a vulnerability, but it reduces recovery risk.
2. Record the current PHP version and note any custom extensions, caching integrations, payment systems, or critical forms.
3. Ask the host whether its PHP builds address both CVE-2026-109618 and CVE-2026-109619. If the selector does not offer a patched build, open an urgent support ticket.
4. Use the hosting control panel to select a supported patched version only when the host confirms it is available and compatible with the site.
5. Recheck Tools → Site Health → Info → Server. Clear application and CDN caches if appropriate, then test the home page, login, forms, search, checkout, and scheduled jobs.
6. Confirm the hosting provider’s other PHP entry points, staging domains, and subdomains are covered. Keep the support ticket or change record.

Support message you can copy: “Please confirm the live PHP runtime for my domain is patched against CVE-2026-109618 and CVE-2026-109619. What exact PHP build/package revision is serving HTTP requests, and when was the fix deployed? Are my subdomains and separate PHP-FPM pools also covered?”

Step 4: Patch on a VPS, container, or dedicated server

First identify the operating system, PHP packaging source, HTTP handler, containers, and all running pools. Apply the security update from the supported distribution or PHP vendor, following its release notes. Restart or reload affected services as instructed so old PHP workers do not remain active. For containerized deployments, rebuild from a patched base image and redeploy rather than updating only the host’s CLI installation. Then verify the active runtime and deployment image digest or package revision.

Do not copy an arbitrary package-manager command from a blog without checking your distribution and release. Debian, Ubuntu, RHEL-compatible systems, and third-party PHP repositories use different packaging and lifecycle rules. In production, stage the update when feasible—but do not delay critical remediation solely to preserve a routine maintenance window.

Step 5: Check for signs of exploitation without mistaking them for proof

Patching prevents continued exposure to the known bug; it cannot retroactively establish that a system was never compromised. If the server was internet-facing while vulnerable, review available logs and telemetry for unusual high-volume or oversized POST requests, PHP memory-exhaustion errors, unexpected child shell processes from web-worker accounts, suspicious newly created files, and unexplained changes to users or scheduled tasks. These indicators are not conclusive on their own and their absence does not guarantee safety. Datadog analysis.

If you suspect compromise, preserve logs and snapshots, avoid destroying evidence, rotate exposed secrets using a trusted machine, and engage your hosting provider or an incident-response professional. Consider isolating affected services if patching is impossible and the risk is unacceptable. The UK NHS advisory emphasizes that patching is the only complete remediation and recommends risk assessment and taking affected systems offline where necessary. NHS England.

Can Cloudflare or a WordPress security plugin protect you?

Cloudflare reported deploying WAF protections ahead of public disclosure, which may help reduce exposure for traffic passing through its network. A WAF is defense in depth, not a substitute for updating PHP. Direct-to-origin access, different request paths, or newly discovered bypasses can weaken filtering assumptions. Cloudflare technical post.

Similarly, WordPress security plugins typically run at the application layer. They cannot be relied on to stop flaws triggered inside PHP before application code executes. Do not claim that disabling session.upload_progress.enabled is a complete fix: researchers specifically warned that this mitigation is insufficient. Datadog Security Labs.

A practical post-patch verification checklist

This table is a manual checklist, not the output of a test performed on your server. A WordPress plugin or online scanner that reports a PHP version without verified patch information cannot conclusively certify that the runtime is secure.

What site owners should do next

If you control only a WordPress dashboard, check Site Health now and contact your hosting company with both CVE identifiers. If you manage a server, inventory every live PHP runtime, apply vendor fixes, restart affected workers, and verify what is actually serving traffic. If your system was exposed before patching, make a proportionate incident-response assessment based on logs and risk—not on assumptions.

The durable lesson extends beyond this incident: keep an inventory of server-side runtimes, know who owns emergency patching, and distinguish application updates from platform security updates. The correct endpoint is a verified patched PHP runtime, not merely a green security-plugin dashboard.

Primary sources and further reading

• PHP project security release announcement
• NHS England cyber alert CC-4875
• Canadian Centre for Cyber Security advisory
• Ubuntu security guidance
• Cloudflare WAF protection analysis
• Datadog Security Labs technical analysis