A WordPress PHP security update happens at the hosting layer, not through Dashboard > Updates. For the critical PHP vulnerabilities disclosed on 21 October 2026, you need confirmation that the PHP process serving your particular website contains both fixes. A host’s general announcement or a selector labelled PHP 8.3 is only a starting point.
This guide is for the owner asking, “Has my host actually patched my WordPress website?” The incident details and upstream fixed versions are in our PHP2Shell advisory guide. Here, the job is to turn a vague reassurance into a checkable result without exposing private server information.
Why WordPress updates do not apply this PHP patch
PHP is the interpreter that runs WordPress on the server. WordPress core, a theme and a plugin are application code running on it. Updating those components can be necessary for their own reasons, but it does not install a patched PHP binary.
The official WordPress security notice explicitly separates these issues from WordPress itself. Do not wait for a new core release or install an unfamiliar “PHP emergency fix” plugin. Use the hosting provider’s established account or support route.
Step 1: check the PHP version WordPress actually uses
- Sign in directly to your own WordPress dashboard.
- Open Tools > Site Health.
- Select the Info tab.
- Expand Server and record the PHP version and PHP SAPI if shown.
- Record the domain and time of the check, then compare them with the provider’s patch confirmation.
Keep the record private. There is no need to post the complete Site Health export or put a public phpinfo file on your website. If wp-admin is unavailable, ask the host for the same runtime details rather than creating a new diagnostic endpoint during an incident.
PHP’s phpversion documentation describes the value as the version of the currently running parser. That makes context important: a command run over SSH can inspect a different PHP binary from the one handling website traffic. A terminal screenshot alone does not establish the web worker’s state.
Step 2: distinguish a branch label from a patched build
A selector that says 8.2, 8.3, 8.4 or 8.5 identifies a branch, not the complete release. It may stay unchanged when the host applies a security package. Equally, selecting that branch again does not force the provider to install a fix it has not deployed.
In cPanel’s MultiPHP Manager, the domains list shows each domain’s PHP assignment, including inherited versions. If your host exposes this interface, use it to identify the correct domain and assignment. Do not change every domain or toggle PHP-FPM just to refresh the display. Package availability is the administrator’s responsibility.
Other hosting panels use different names. Ask which runtime serves the affected domain, not simply which PHP versions the account offers. Include separate subdomains or an old live site if they still accept requests.
Step 3: accept documented backports, not unsupported assurances
Some operating-system vendors apply security changes to an older base release while retaining its upstream-looking version. For example, Ubuntu notice USN-8948-1 lists its corrected PHP packages for this incident. Its Ubuntu 24.04 package is 8.3.6-0ubuntu0.24.04.13, rather than the upstream PHP 8.3.36 release string.
This example does not mean every PHP 8.3.6 installation is patched. It means the full vendor package revision and applicable advisory matter. The host must connect its installed package to the notice and confirm the running service uses it. Do not compare distribution version numbers as if they were ordinary decimal numbers.
| What you receive | What it establishes | What is still missing |
|---|---|---|
| “We support PHP 8.4” | A branch is available. | The patched package and your site’s assignment. |
| “Our servers are being updated” | A rollout is underway. | Completion for the affected domain and workers. |
| An upstream fixed release in Site Health | The WordPress request sees that release. | Other sites, separate workers and any independent investigation. |
| A vendor package revision and matching advisory | A documented patch route exists. | Confirmation that this package serves your domain. |
| “The WAF blocks attacks” | The host reports an additional control. | A runtime fix and the scope of the protection. |
Step 4: send the host a precise request
A useful support message names the domain and both vulnerabilities. You can ask:
Please confirm whether the PHP runtime serving my WordPress domain contains fixes for CVE-2026-109618 and CVE-2026-109619. Please identify the running web PHP version or full vendor package revision, the applicable security advisory, and whether old PHP workers have been replaced. If this domain is not yet patched, please explain the immediate containment and patch plan.
Add your domain inside the provider’s private support ticket. Do not include an administrator password or grant broad access in a public forum. If support replies with a platform-wide announcement, ask whether that rollout has completed on your assigned server.
If you manage the server yourself, the equivalent work belongs to its administrator: reconcile package provenance, installed versions, the active handler and all relevant workers. A successful package-download command is not the same as a running patched service.
A worked example: two sites, one hosting account
Imagine a business has a main website and a booking subdomain in the same account. The main site uses PHP 8.4; the booking application inherits another assignment. The host announces that its PHP 8.4 packages are patched.
The owner checks the main site’s Site Health and receives a domain-specific confirmation. That is progress, but it does not answer the booking application’s status. The next useful question is which package and handler serve the booking subdomain, not whether the homepage still looks normal.
Write one line per installation: domain, runtime assignment, patch evidence, confirmation time and responsible person. Mark an unconfirmed installation as unknown. This is a hypothetical example, not a report of a client incident or a claim that a particular host missed a site.
Step 5: verify the site still performs its job
After confirmation, test a normal visit and an uncached application path. Open wp-admin, a representative content page and the key form, booking or shop journey. A cached landing page can remain available while a dynamic action fails.
Use a controlled test appropriate to the site. For a store, our WooCommerce checkout checklist explains the wider acceptance work. Do not repeatedly create live payments or orders as an informal test. Agree on the test method, records and cleanup first.
If the website breaks after the host changes PHP, preserve the error and use the WordPress PHP-update recovery guide. Recovery should retain a verified patched runtime, not silently reverse the security work.
What if the host cannot confirm a fix?
Ask for an immediate escalation to the server or security team. CERT-EU recommends considering isolation where immediate remediation is not feasible. Have the operator assess how to restrict the affected application before requests reach vulnerable PHP. A front-end maintenance message alone does not demonstrate that boundary.
If the provider cannot supply a supported patch route, agree on containment and a migration or upgrade plan rather than experimenting with production configuration. Record what is not verified and who owns the next action.
Webless’s WordPress maintenance service can help coordinate application checks and a documented handoff. Server package access and hosting responsibilities must still be confirmed. A WordPress maintenance login is not automatically root access to the host.