PHP2Shell and WordPress: how to check whether your site is affected

Short answer: if your WordPress site handles requests through PHP, you need to check the PHP version on the server. Updating WordPress core, plugins or the theme does not fix PHP2Shell because the vulnerabilities are in the PHP runtime. The patched upstream releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12.

On 21 October 2026, the PHP project disclosed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which can allow unauthenticated remote code execution. The official PHP advisory considers PHP installations serving web requests at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

Status of this guide: checked on 22 October 2026 against advisories from PHP, WordPress and public cyber-security agencies. This is practical guidance for site owners and developers; it cannot establish whether a particular server has been compromised.

What PHP2Shell is and why it affects WordPress

PHP2Shell is the name used for two vulnerabilities in the PHP runtime. It is not a malicious plugin or a WordPress-specific bug:

• CVE-2026-109618: an error while handling out-of-memory conditions can leave internal request data in an invalid state. Request shutdown may later treat that state as valid.
• CVE-2026-109619: some global state can remain after one request’s memory is released and be consumed by a later request handled by the same worker.

Both vulnerabilities received a CVSS score of 9.2 out of 10 in the PHP security advisories. For the first issue, remote code execution has been demonstrated before application code starts in common Apache mod_php configurations. PHP includes other execution modes in its warning and recommends updating every PHP server exposed to web requests.

WordPress is written in PHP. When someone requests a dynamic page, the server runs PHP to load WordPress, query data and produce the response. A vulnerability in that layer can operate before or outside the CMS defences. This is why WordPress.org confirmed that no WordPress update is required or planned for these issues: PHP itself must be updated.

Which PHP versions fix PHP2Shell

This is the comparison published by the PHP project:

Do not compare only the first decimal. Running PHP 8.3 is not enough: you need the complete version and, on Linux, the package identifier.

A version such as 8.3.35-0ubuntu0.24.04.1 may receive a backport: the vendor applies the security patch without renaming the package to PHP 8.3.36. In that case, the visible version does not prove that the installation remains vulnerable. Check the distribution advisory or obtain confirmation from your hosting provider.

How to find the PHP version used by WordPress

In the WordPress dashboard:

1. Open Tools > Site Health.
2. Select the Info tab.
3. Expand Server.
4. Find PHP version and record the complete number.

You may also find it in the hosting control panel under names such as PHP Manager, MultiPHP Manager, PHP Settings or Server Information.

Do not publish a phpinfo() file at a public URL just to check the version. It can expose paths, modules and internal configuration. If you manage the server, compare the command-line version with the runtime that actually serves the website: php -v does not always represent the active PHP-FPM pool or container.

What to do for each hosting setup

Managed WordPress hosting

The provider normally controls the operating system and PHP. Do not assume it has already updated everything: open a support ticket and ask for three specific details.

1. The PHP version or package serving your website.
2. Confirmation that it contains the fixes for both CVEs.
3. The time at which the active PHP workers were restarted or replaced.

If the provider only mentions WAF rules, ask about the patch as well. The PHP advisory states that updating is the only complete mitigation.

Shared hosting or cPanel

Create a recoverable backup before changing branches. Select a patched version in the control panel, then test every dynamic path: login, forms, search, checkout, payments, email and scheduled tasks. If your current branch has no patched option, contact support instead of jumping to a major version without checking compatibility.

Updating within the same branch—for example from 8.3.35 to 8.3.36—usually carries less compatibility risk than moving from 8.1 to 8.4, but no update replaces a backup and a real functional check.

A VPS or self-managed server

Update from the maintained repository for your operating system rather than copying individual files over an unknown installation. Then:

1. Restart PHP-FPM, Apache, LiteSpeed or the relevant service.
2. Check that no old workers remain in service.
3. Verify the version through the application, not only the CLI.
4. Review logs, monitoring and service health.
5. Confirm the fix against your distribution advisory if it uses backports.

The NCSC-NL PHP2Shell operational repository collects references for distributions and products that bundle PHP. It is more reliable than inferring package status from a version string alone.

Docker and other containers

Changing an image tag in a configuration file does not update containers that are already running. Pull a patched base image, rebuild, deploy and replace every old replica. Check both the image digest and the PHP version inside the final container.

Avoid ambiguous tags such as latest when they prevent you from proving what is in production. A mutable tag may point to a new registry image while your deployment keeps using a cached layer.

A static site without PHP

A website delivered as static HTML, CSS and JavaScript files does not execute PHP and is not affected by these two vulnerabilities. This portfolio, for example, is generated with Astro and served as static content.

That does not make Astro universally more secure than WordPress. It changes the maintenance surface: the public PHP runtime disappears, but dependencies, integrations, external forms, the build process and hosting account still need protection. I discuss that trade-off in Astro vs WordPress.

The exact message to send your hosting provider

You do not need a generic answer to “is my website secure?”. Ask a question that can be verified:

Hello, could you confirm which PHP version currently serves my website and whether your package contains the fixes for CVE-2026-109618 and CVE-2026-109619? If it does not, please tell me when it will be updated, which temporary mitigation you have applied and whether I need to take any action. Please also confirm whether the PHP workers were restarted after the package was installed. Thank you.

A useful reply should identify the version or vendor advisory. “We have a firewall” or “WordPress is updated” does not answer the question.

Why a WAF or configuration change is not enough

A web application firewall can block known patterns and reduce exposure while the patch is being deployed. It can also generate false positives or miss variations it does not recognise. It does not change the vulnerable code inside PHP.

The PHP team published temporary mitigations for specific paths, but warns that they do not make a vulnerable installation safe. Do not copy changes to memory_limit, request limits or server rules without understanding their effect on your environment. An improvised configuration can break uploads, forms or legitimate processes without closing every route to the flaw.

The correct sequence is:

1. Install the patched package.
2. Restart the processes that load PHP.
3. Verify the effective version through the website.
4. Keep the WAF and sensible limits as additional layers.

What to test after updating PHP

Do not consider the work complete when the control panel shows a different number. Run a short but complete check:

• Open the home page and several pages while logged out.
• Sign in to the WordPress dashboard.
• Submit a real form and confirm delivery.
• Test checkout, payment or booking if present.
• Run important scheduled jobs and review transactional email.
• Check APIs, webhooks and plugins connected to external services.
• Review PHP, Apache/Nginx and hosting errors.
• Clear caches only when you know which layers are involved.

A PHP update can reveal outdated plugins or incompatible custom code. That is not a reason to retain an unsupported runtime: it shows that the maintenance debt already existed and needs a plan.

When to investigate a possible compromise

Updating fixes the vulnerable code from that point onward, but it does not prove that no earlier activity occurred. If the server was exposed with an affected release, preserve logs before they rotate and seek specialist help when you find signs such as:

• unknown administrator accounts or credentials;
• new or modified PHP files with no known deployment;
• unexpected scheduled tasks, processes or outbound connections;
• redirects, injected content or unexplained behaviour changes;
• unusual spikes in errors, memory, CPU or multipart requests;
• alerts from the host, EDR, WAF or cloud provider.

Do not delete suspicious files before preserving evidence. An absence of simple indicators is not proof that no compromise occurred. Forensic analysis needs access to the system, logs and context that a public web page cannot provide.

The lesson goes beyond this patch

PHP2Shell exposes a common problem: many websites have a content owner, but nobody knows who maintains the runtime, backups, dependencies or incident response. Those responsibilities should be agreed when the website is built, not during a critical alert.

When I plan a professional website, the choice between WordPress, Astro or another solution starts with who needs to edit it, which functions it requires and who will maintain it. An architecture with fewer moving parts does not remove risk, but it can reduce responsibilities the project has no capacity to sustain.

See how I approach a custom website and its maintenance.

For more context, continue with the web security guide for developers and the website pre-launch checklist.

Sources and update log

Primary sources used for this guide:

• Official PHP project advisory, 21 October 2026.
• CVE-2026-109618: RCE via OOM corruption.
• CVE-2026-109619: RCE via stale global state.
• Official WordPress advisory about the PHP update.
• Joint statement published by ENISA.
• Operational information maintained by NCSC-NL.

22 October 2026: initial publication. Patched versions and scope checked against the advisories above. I will update this section if official guidance changes or additional patched branches become available.