If a security headline has left you wondering whether your website needs attention, the next useful step is a specific question to your host—not a guess based on the appearance of your homepage.
Start here: Ask your hosting provider or administrator whether the PHP runtime serving your site is fixed for CVE-2026-109618 and CVE-2026-109619, commonly called PHP2Shell. Ask for confirmation about the running service, not just an available update in a dashboard.
This checklist is for systems you own or are authorized to manage. It is a defensive verification workflow, not an exploit guide or a diagnosis of a particular website.
1. Identify the layer that needs the fix
A WordPress update, a plugin update and a PHP runtime update are different operations. Find out who maintains the server-side PHP installation. On managed hosting that may be the provider; in a container deployment it may involve the team maintaining and deploying the image.
Write down the site or application, hosting environment and responsible person. This avoids the common handoff problem where everyone assumes a different team has completed the same task.
2. Check the current vendor advisory
Docker’s October advisory listed upstream fixed releases including PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Those numbers are a reference point from that advisory, not a command to install an old release later. Use the latest applicable vendor-supported security update.
Package vendors may backport fixes while retaining a different version label. Red Hat’s bulletin is an example of product-specific guidance. Ask the vendor whether its package contains the relevant fix rather than assuming an upstream number is the only evidence that can count.
3. Prepare recovery before changing production
Confirm that a recent backup exists and that the people doing the work know how to restore it. Decide who will make the change and who will check the site afterward. If compatibility is uncertain, use a staging environment where practical and follow the provider’s incident guidance for any period of exposure.
A backup helps recover a broken deployment. It is not a security patch and does not establish that an incident has been contained. Keep those purposes separate in your plan.
4. Verify the running service after deployment
Ask the administrator to confirm the runtime used by the web application. A command-line version and the web-serving runtime can differ. For containers, an updated local image is not evidence that a running workload has been rebuilt and redeployed.
Use the provider’s supported process for the update and any required service restart. Do not publish a diagnostic page exposing server details just to prove the version. The verification can remain in your private support or administration record.
5. Check the functions your visitors rely on
After the update, check representative public pages and the workflows that matter to the site: sign-in, forms, search, publishing and, where relevant, checkout. Ask the administrator to review application and server errors as well. A homepage that loads successfully is a useful check, but it is not the whole application.
Record what was checked and by whom. If something fails, follow the change or incident plan. Do not quietly leave a known vulnerable configuration in place simply because it makes a broken feature work again.
6. Treat suspected compromise as a separate investigation
A patch closes a software weakness; it does not prove that an earlier intrusion did not happen. If the administrator finds suspicious activity, preserve relevant records and follow the organization’s incident-response process. Credential rotation, recovery and notifications should be based on the actual incident assessment.
Avoid posting logs containing tokens, customer information or private paths in a public comment thread. Share relevant material through the support or response channel authorized for that system.
A message you can send your hosting provider
Please confirm whether the PHP runtime currently serving my website includes the fixes for CVE-2026-109618 and CVE-2026-109619. Please identify the applicable vendor advisory, confirm whether deployment and any required restart are complete, and tell me what post-update checks or further incident actions you recommend.
Keep the reply with the date, environment and support reference. That creates a much more useful record than a screenshot saying updates are generally enabled.
Quick questions
Does updating a WordPress plugin fix PHP itself?
Not necessarily. Confirm the server-side runtime separately with its maintainer.
Does a different package version automatically mean it is unsafe?
No. Vendor backports and packaging matter; use the advisory for the installed package.
Is this the same as the entire Black October story?
No. This checklist focuses on PHP2Shell. Our Black October explainer separates the broader label from individual incidents.
Sources and verification
Checked October 30, 2026. Availability, product features and schedules can change.
