What to ask your host about PHP2Shell

Who this is for

You pay someone else to run the server. You may have a control panel, a WordPress dashboard or only a support queue. The PHP fixes for CVE-2026-109618 and CVE-2026-109619 still have to reach the PHP runtime that serves your site, and the workers have to be restarted.

This checklist helps you ask for evidence rather than reassurance. It does not replace your host’s incident process, and it does not prove that a site was never attacked.

The short answer

If your site is on managed hosting, ask the provider four things in writing:

1. Which PHP branch and exact package version serves this site?
2. Does that package contain the vendor fix or a distribution backport?
3. When were the PHP-FPM, Apache or container workers restarted after the update?
4. Are there other PHP pools, staging sites or containers on the same account that were not included?

“We are on the latest version” is not an answer to those questions. A version string can be old while a backport contains the fix, and a patched package can sit on disk while old workers keep serving traffic.

What to collect before you ask

Write down the service boundary first:

• the domain and the hosting account or plan;
• whether PHP is shared, containerised or a dedicated pool;
• who controls PHP configuration and restarts;
• any staging, multisite or agency-managed copy;
• the last time you changed the site or deployed code.

That list prevents a common failure: one environment is patched and another copy of the same site is missed.

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.

Questions to send

Use these as a message, not as a demand for a public diagnostic page:

1. Runtime. Which PHP version and SAPI serves the site: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed or something else?
2. Package. Is PHP a distribution package, a vendor build or a container image? What is the exact package version or image digest?
3. Patch evidence. Which advisory or changelog entry shows that the package contains the fix for CVE-2026-109618 and CVE-2026-109619? A link or ticket reference is enough.
4. Restart. When was the PHP service, web server or container replaced after that package was installed? A package timestamp is not a restart timestamp.
5. Scope. Does the same account have additional PHP pools, subdomains, staging environments or containers? Which of them are on the same runtime?
6. Exceptions. If any service is not fixed, what interim control is in place, who owns it and when will it be removed?
7. Contact. Who will confirm the work and what evidence will they keep?

Do not ask the host to publish a phpinfo() page on the public internet. The verification guide explains safer ways to inspect the serving runtime.

How to read the answer

A useful answer names the runtime, a package or image, a date and a restart. It may also explain a backport: distributions can keep an older visible version while including the security fix. That is normal, but it should be backed by the vendor advisory or changelog.

These answers are weaker:

• “Our platform is secure.” No runtime or package is named.
• “PHP is up to date.” No branch, version or restart is given.
• “The WAF blocks it.” A WAF rule can reduce exposure; it is not a complete fix.
• “It is a managed service, so nothing is needed.” The service still runs a PHP runtime.
• “We restarted last month.” The restart must follow the patch, not precede it.

If the host cannot confirm the runtime, ask for the escalation path. A support reply that cannot name the PHP package is not verification.

What you can check yourself

On WordPress, Tools → Site Health → Info → Server exposes server and PHP-related details to an administrator. The Status tab can also flag an outdated PHP version. That helps you start the conversation, but it does not replace the host’s package and restart evidence.

If you have shell access, the commands in the verification guide show how to compare the CLI with the serving SAPI. On a control panel, look for the PHP version and handler for the specific domain, not only the account default. A host may run different PHP versions for different sites.

Keep a record

For each site, keep a short entry:

This record is more useful than a screenshot of a version number. It shows the runtime that actually served traffic and who accepted the residual risk.

Boundaries

A host’s confirmation is evidence about the runtime, not proof that no exploitation occurred. If you need a compromise assessment, use the indicators and limits in the mitigation guide. Patch status, exploitation status and KEV status are separate questions.

The fixed upstream releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older have no upstream release; a host may use a distribution backport or a vendor-supported branch. Ask which support path applies instead of comparing only the visible version string.

Sources: PHP security advisory, CERT-EU 2026-018, NCSC UK and CISA. Last verified 23 October 2026.