The short answer

On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, widely referred to as PHP2Shell. Both can allow unauthenticated remote code execution. The PHP project's advance notice rated them CVSS v4.0 9.2, and NVD lists the same v4.0 score. This is a problem in PHP itself, not in WordPress core, a plugin, or a theme. WordPress.org said no WordPress update is required or planned. Check which PHP version the site runs (in WordPress: Tools, then Site Health, then Info, then Server) and ask your host whether one of those patched releases, or a vendor package that includes the same fixes, is actually running. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 26, 2026.

What PHP2Shell actually is

On October 20, 2026, the PHP security team gave advance notice of a release scheduled for October 21 at 14:00 UTC. It said the release would address two critical vulnerabilities, both rated CVSS v4.0 9.2. The following day it shipped PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 and published a security advisory.

The two flaws are:

  • CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), which PHP describes as remote code execution by way of out-of-memory corruption. When PHP handles an out-of-memory condition, request data can be only partly initialized. Cleanup may then treat that invalid data as valid. NVD's description matches that account and lists a CVSS v4.0 score of 9.2 (Critical) and a CVSS v3.1 score of 9.8 (Critical).
  • CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), which PHP describes as remote code execution by way of stale global state. Request-owned internal state can survive after its memory has been freed, and a later request handled by the same worker may use that stale state. NVD lists a CVSS v4.0 score of 9.2 (Critical) and a CVSS v3.1 score of 8.1 (High).

PHP says everyone running PHP that serves web requests is in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It considers the risk highest for mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." That last point matters for WordPress owners: the application does not have to be poorly written for the server to be exposed.

NVD's affected-version data lists CVE-2026-109618 from PHP 7.3.0 up to, but not including, the October 21 patched releases, and CVE-2026-109619 from PHP 5.4.0 up to those same patched releases. Use the PHP project's own fixed versions as the target: 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or a vendor package that includes those fixes.

Why a WordPress update will not help

The same day as the PHP release, WordPress.org published "Critical PHP Security Release" by John Blackbourn. The notice is short and easy to misread. The important line is that these vulnerabilities "are not specific to WordPress and affect any server that hosts a PHP application." Then: "No WordPress update is required or planned for these issues."

Your host may already be updating PHP and adding web application firewall rules. WordPress.org still tells you to check with the host and, if needed, update PHP yourself. Inside WordPress, the documented place to read the runtime is Tools, then Site Health, then Info, then Server.

WordPress.org also notes that PHP versions before 8.2 no longer receive security updates from the PHP project. If you manage your own hosting on one of those versions, it says you should consider taking the server offline while you prepare to update, and it quotes the UK National Cyber Security Centre: "Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated."

What CISA has said

CISA's October 21 alert, updated through October 26, uses the name "php2shell" and urges organizations to patch CVE-2026-109618 and CVE-2026-109619 immediately. It repeats PHP's list of affected server setups and PHP's judgment that mod_php is the highest risk. It tells organizations to update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35.

CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 26, 2026. The catalog entries list a federal due date of October 29, 2026 under Binding Operational Directive 26-04. CISA also says organizations that cannot update immediately, or that still run PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched. A web application firewall may help until then, but it is not a substitute for the update.

What to ask your host

  1. Which PHP version is serving this site right now? You want 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or a distribution package whose changelog includes the October 21, 2026 security fixes. PHP says Linux distributions and LTS vendors received the patches in advance.
  2. If the panel still shows an older number, has the vendor backported the fix? Package names can hide a patched build. Ask for the package changelog or advisory, not only the marketing version string.
  3. Were PHP workers restarted after the update? A patched package that has not replaced running workers can leave the old process in memory.
  4. If the site is on PHP 8.1 or older, what is the plan? The PHP project no longer ships security updates for those lines. It did publish limited source-backports for PHP 7.4, 8.0, and 8.1 for people building from source or without an LTS vendor, but the supported path is to move onto a current release. PHP 8.2 itself reaches end of life on December 31, 2026, according to the 8.2.35 release announcement, so even a patched 8.2 install should have a planned upgrade.
  5. Are plugins or the theme blocking a PHP upgrade? That is common on aging WordPress sites. Compatibility problems are a reason to get help, not a reason to stay on an unpatched runtime.

The PHP project is clear that only an update is a complete solution. It listed temporary configuration changes that reduce exposure to specific paths (including setting memory_limit=-1 in a way applications cannot override, lowering post_max_size, disabling session.upload_progress.enabled before request parsing, and on PHP 8.5 setting fatal_error_backtraces=0). Those steps are documented on php.net for administrators who cannot update immediately. They do not make an unpatched server safe.

On October 23, 2026, PHP published a separate informational advisory about an unlikely session-upload-progress vector, later identified as CVE-2026-115560, to be fully fixed in the next regular bugfix release. If you already disabled session.upload_progress.enabled as part of the October 21 guidance, PHP says no further action is needed for that follow-up item.

Why this shows up on aging WordPress sites

Many sites we see in Rescue and Updates work stay on an old PHP version because a plugin, page builder, or custom snippet was never tested on a current runtime. Owners then treat the PHP version as frozen. PHP2Shell is why that freeze is no longer a reasonable holding pattern.

The work is straightforward to describe and often messy to do: identify the runtime, confirm whether the host has applied the October 21 fixes, restart workers, and if the application cannot run on a supported PHP line, stabilize the site and plan a modernization or replacement rather than hoping an abandoned plugin will start working. That is security work first, then a product decision about whether WordPress stays.

Keep this separate from two other October issues that are easy to mix together. CVE-2026-119977 is a WordPress Core upgrade-window race condition patched in WordPress 7.1.4. CVE-2026-111497 is a Brotli decoder bug. PHP later shipped updated Windows builds (8.5.12-1 and the matching 8.4, 8.3, and 8.2 rebuilds) that bundle Brotli 1.2.1 for that separate issue. A site can need a PHP update, a Brotli or library update, and a WordPress update.

How NTx can help

If you cannot tell which PHP version the site runs, your host has not patched it, or an upgrade would break plugins you still depend on, we can review the install and talk to the host with you. The first step is a clear picture of the runtime, the WordPress version, and what would break if PHP moved. We agree on that work before any rebuild conversation.

FAQ

What is PHP2Shell?

PHP2Shell is the name commonly used for two critical PHP vulnerabilities disclosed with the October 21, 2026 security release: CVE-2026-109618 and CVE-2026-109619. The PHP project says they can allow unauthenticated remote code execution. CISA uses the name php2shell in its October 21 alert.

Does a WordPress update fix this?

No. WordPress.org's notice, written by John Blackbourn, says these vulnerabilities are not specific to WordPress and that no WordPress update is required or planned. Updating WordPress, a theme, or a plugin does not patch PHP.

Which PHP versions are safe?

The PHP project released fixes in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21, 2026. Linux distributions and LTS vendors may ship the same fixes under their own package numbers, so confirm the vendor changelog rather than assuming an older displayed version is unpatched. PHP versions before 8.2 no longer receive security updates from the PHP project.

How do I see which PHP version my WordPress site uses?

WordPress.org says you can look under Tools, then Site Health, then Info, then Server. Many hosts also show the runtime in the hosting panel. If you cannot log in, ask the host or a developer to check the PHP version on the server.

Is this the same issue as the WordPress 7.1.4 upgrade-window flaw?

No. CVE-2026-119977 is a WordPress Core upgrade-process race condition patched in WordPress 7.1.4 on October 28, 2026. PHP2Shell is in the PHP language, patched on October 21, 2026. A site can need both updates. It is also separate from CVE-2026-111497, a Brotli library flaw.

What if we cannot update PHP today?

The PHP project says there are no complete mitigations and that updating is the only safe choice. It published temporary measures that reduce exposure to specific attack paths, but those do not make an unpatched install safe. WordPress.org, quoting the UK National Cyber Security Centre, says that if you manage your own hosting on PHP older than 8.2 and cannot remediate immediately, you should consider taking the server offline until it can be updated. CISA gives the same offline guidance for organizations that cannot patch or that still run PHP 8.1 or earlier.

Sources

  1. PHP.net, "Upcoming Critical PHP Security Release," October 20, 2026. https://www.php.net/archive/2026.php#2026-10-20-1
  2. PHP.net, "Security advisory: Critical remote code execution vulnerabilities, update now," October 21, 2026. https://www.php.net/archive/2026.php#2026-10-21-5
  3. PHP.net release announcements for PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, October 21, 2026. https://www.php.net/archive/2026.php
  4. PHP.net, "Informational advisory: Session upload progress," October 23, 2026. https://www.php.net/archive/2026.php#2026-10-23-1
  5. John Blackbourn, "Critical PHP Security Release," WordPress News, October 21, 2026. https://wordpress.org/news/2026/10/critical-php-security-release/
  6. CISA, "Critical Vulnerabilities in PHP Require Immediate Patching," October 21, 2026, updated October 26, 2026. https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
  7. CISA Known Exploited Vulnerabilities catalog entries for CVE-2026-109618 and CVE-2026-109619, date added October 26, 2026, due date October 29, 2026. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  8. NVD, CVE-2026-109618. https://nvd.nist.gov/vuln/detail/CVE-2026-109618
  9. NVD, CVE-2026-109619. https://nvd.nist.gov/vuln/detail/CVE-2026-109619