Get a written answer from your host — and check it

01Does this apply to you?

02Steps

A hosting ticket is a technical record. Ask closed questions with specific values, keep the reply, and treat an answer that does not name a version as unanswered.

1. Site owner

   Establish what you control and what the host controls

   Write down the product: shared hosting, managed WordPress, a platform with a PHP version selector, or a container service where you own the image. The answer changes who is responsible for the fix.

   If you control the image or the package, use the self-managed patch path. If the host controls PHP, continue here.

   Record the domains and subdomains on the account, including staging and preview names. A host may patch production and leave a preview environment on an older runtime.

   You should see A short scope statement: which environments you control and which the host controls.

   If it fails If the contract is unclear, ask the host in the same ticket. Do not assume that “managed” includes every environment.
2. Site owner

   Read the version from the web runtime

   Use the host control panel's PHP version display and, where available, a web-level report from the application. For WordPress, Tools → Site Health → Info → Server reports the PHP version used by the web request.

   Record both values. If they disagree, the control panel may be showing an available version rather than the one assigned to your domain, or the site may have a per-directory override.

   Do not use a CLI command as the primary evidence on shared hosting. The CLI may run a different version from the web worker.

   You should see Two recorded values, with the panel path and the date, and an explanation for any disagreement.

   If it fails If the panel shows only a branch such as 8.4 and not a patch level, record that as partial evidence and ask for the exact version.
3. Site owner

   Send a precise enquiry

   Use the hosting provider enquiry template and fill every bracketed field. Ask for the web SAPI version, package source, installation date, worker restart confirmation, and the status of every environment on the account.

   Ask whether any interim PHP settings are applied, such as memory_limit, post_max_size, session.upload_progress.enabled or fatal_error_backtraces. These settings affect what the fix actually covers.

   Ask for the best contact if your own verification does not match the reply. Keep the ticket reference.

   You should see A sent enquiry with a ticket reference and a specific list of questions.

   If it fails If the support form limits the message length, send the version list first and the remaining questions in a follow-up on the same ticket.
4. Technical reviewer

   Judge the reply against acceptable evidence

   Acceptable: an exact web SAPI version, the package source or image digest, the date, a statement that all workers were restarted, and the status of each environment.

   Partial: a control panel version without a patch level, or a statement that the platform is “up to date” without a number. Ask for the missing value.

   Not acceptable: “we are aware”, “your site is protected by the WAF”, “no action is required from you”, or a link to a general status page with no version. These do not identify the runtime.

   If the reply includes a version that is older than the fixed version for that branch, ask for the vendor advisory or backport reference. A distribution package can be fixed without matching the upstream number.

   You should see The reply is classified, and any missing evidence is written into a follow-up question.

   If it fails If the host will not give a version, record that as an unresolved control gap and escalate through your account manager or contract contact.
5. Site owner

   Apply the controls you do have while you wait

   If the control panel exposes PHP settings, set session.upload_progress.enabled=0 where the application does not depend on upload progress, and keep post_max_size conservative. These are interim measures, not a fix.

   Keep any WAF or CDN protection in blocking mode and review events. Cloudflare says its managed rules cover the two critical CVEs, but also says customers must patch PHP.

   If the host provides a PHP version selector, do not switch to an unsupported or release-candidate branch just to look current. Use a supported branch with the fixed patch level.

   You should see Interim controls are recorded with their scope and the date they will be removed.

   If it fails If the panel offers no settings and no patch date, the remaining option is a migration plan. Record that decision rather than leaving the site in an indefinite “waiting” state.
6. Site owner

   Record the outcome and set the next checkpoint

   Record the host's answer, the evidence level, the residual risk and the next follow-up date in the workbook and handover record.

   If the host has not confirmed a patch, set a date for escalation and a date for deciding whether to migrate. A ticket that stays open without a checkpoint is not a control.

   Do not describe a host's assurance as your own verification. Attribute the evidence to the host and state what you could not check.

   You should see A dated record with an owner, an evidence level and a next action.

   If it fails If the host confirms a patch but your own web check still shows an older version, reopen the ticket with both values. Do not choose the answer you prefer.

03What usually goes wrong

05Where to go next

06Sources and revision

Every operational claim on this page was checked against the documents below on 23 October 2026. This page was last substantively changed on 23 October 2026.

See the full revision log for what changed on this site.