WordPress vs PHP: where the fix belongs

Who this is for

You can update WordPress, themes and plugins, but you do not control the server. Or you run a small agency and need to explain why a WordPress update is not the same as a PHP update.

The short answer: CVE-2026-109618 and CVE-2026-109619 are flaws in the PHP runtime, not in WordPress core, a theme or a plugin. Updating WordPress is still normal maintenance, but it does not replace updating PHP and restarting the workers that serve the site.

The three layers

Keep these separate when you ask for evidence:

1. WordPress and its extensions. Core, themes and plugins are application files. Updating them does not change the PHP binary.
2. The PHP runtime. This is the PHP-FPM pool, Apache mod_php module, php-cgi process or container image that executes WordPress. PHP2Shell lives here.
3. The web server and edge. Apache, Nginx, a reverse proxy or a WAF can change how requests arrive, but they do not patch the PHP engine.

A WordPress dashboard can tell you about the first layer. It may show information about the second, depending on the host. It usually cannot prove that the third layer is configured as you expect.

Scope. This guide addresses CVE-2026-109618 and CVE-2026-109619. PHP also published a separate 23 October advisory for CVE-2026-115560 with narrow configuration conditions; it does not change the four PHP2Shell fixed releases. See the 23 October update.

Find the PHP information you already have

WordPress exposes server details under Tools → Site Health → Info. The Server section shows server and PHP-related information to an administrator, and the Status tab can flag an outdated PHP version. The official Site Health documentation describes both tabs.

Use that screen to answer:

• Which PHP version does WordPress report?
• Is the site running on the host’s default PHP version or a per-site version?
• Is there a separate staging site or multisite network using the same account?

Do not publish a phpinfo() page to answer these questions. Site Health is available to authenticated administrators and is a safer starting point. If you need the serving SAPI, use the restricted checks in the verification guide.

What WordPress’s requirements do and do not tell you

WordPress’s official requirements page recommends PHP 8.3 or greater and notes that older PHP versions are end-of-life and may expose a site to security vulnerabilities. That is a useful baseline for the application.

It is not a PHP2Shell patch check. The fixed releases are branch-specific:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

A host may run PHP 8.3 with a distribution backport, or PHP 8.2 with the 8.2.35 update. The visible version string is not enough. Ask which package or image contains the fix and when the service was restarted. If your host is unsure, use the hosting provider checklist.

What to ask the host

Send a short message with the site and the layer you need checked:

• Which PHP version and SAPI serve this WordPress site?
• Is it the account default or a per-site pool?
• Which package version or image digest contains the PHP2Shell fix?
• Was PHP-FPM, Apache or the container restarted after that update?
• Are staging, multisite or other domains on the same account covered?
• If not, what interim control is in place and when will it be removed?

A reply that only says “WordPress is up to date” has answered the wrong layer.

Verify after the change

After the host updates and restarts PHP:

1. Reload Site Health → Info → Server and record the PHP version it reports.
2. Confirm the host’s package version or image digest, not only the version in WordPress.
3. Confirm the restart or rollout time.
4. Check a second site or environment if the account hosts more than one.
5. Keep the evidence with the date and the person who supplied it.

If the site uses a persistent object cache or a page cache, clearing it may be necessary for application changes, but it is not a substitute for restarting PHP workers. The runtime is the layer that matters for this vulnerability.

Common mistakes

• “I updated WordPress, so I am fixed.” The PHP runtime can still be vulnerable.
• “The host says PHP is current.” Ask for the branch, package and restart time.
• “The WAF is on.” A WAF can reduce exposure but does not remove the runtime flaw.
• “The CLI says 8.3.36.” The web SAPI may use a different binary or pool.
• “The site looks fine.” A lack of visible symptoms is not evidence that the runtime is patched.

Boundaries

This guide is about the WordPress hosting layer, not about exploiting or cleaning a compromised site. The PHP advisories describe remote code execution; they do not provide a victim count or a list of affected WordPress sites. Patch status, exploitation evidence and KEV status remain separate questions.

If you need a compromise assessment, start with the indicators and limits in the mitigation guide. If you manage the server yourself, use the full runtime verification guide. For the incident overview, see the PHP2Shell dossier.

Sources: WordPress requirements, WordPress Site Health documentation, PHP security advisory and the two GitHub advisories linked from the dossier. Last verified 23 October 2026.