PHP Site AuditHosting
What to ask your host to confirm a PHP security patch
Ask the hosting provider which runtime serves your domain, which fixed release or vendor backport covers the PHP vulnerability, which package or build is deployed, and when serving workers restarted. Ask whether each production domain, pool, and container is covered. A banner or control-panel label by itself may not prove the patched package is active.
Send a question the support team can answer
Give the provider the affected domain and ask: Which PHP SAPI or managed runtime handles its web requests? What PHP package, platform build, or container image is assigned? Which vendor advisory confirms a fix for CVE-2026-109618 and CVE-2026-109619? When was the relevant runtime rolled out and its workers restarted? Is the account using a different runtime for subdomains, cron tasks, or separate application pools?
PHP's advisory and the related fixed-version guide list the upstream releases. If a provider uses backports, ask for its own advisory and package identifier rather than requiring an identical upstream version label.
Include the account's affected hostnames and ask support to route the question to the team managing PHP packages. Request a response that distinguishes the production handler from CLI tools, staging environments and background workers, and retain the case number with the advisory.
Check the site after the change
After the host confirms the rollout, review WordPress Site Health or the application's server diagnostics in an authenticated dashboard. Check public pages and the workflows users rely on, such as login, forms, uploads, and checkout. Report any new errors to the provider with the time and affected path.
A public header can show a clue but cannot confirm how the provider built its package. Avoid creating a public phpinfo() script; PHP documents that it can reveal configuration and environment details.
If the provider cannot give an answer
Escalate through the host's security or operations channel and ask for an expected update window and supported-runtime options. If the provider confirms the branch is unsupported and cannot provide a backport, ask how to move the site to a supported PHP branch. Do not treat a firewall or header change as equivalent to the PHP project's complete fix.
Common questions
What is a useful support response?
It identifies the package or build, advisory covering both CVEs, hostname or pool, and worker restart or activation time.
What if support gives only a version number?
Ask whether it describes the web-serving package and whether a backport is present; do not send passwords or customer records.
Should I reject an older-looking package?
Not before checking the vendor bulletin. Upstream numbers and distribution revisions can differ.