Verify the website after updating PHP

Post-update verification checklist

This is this guide’s suggested workflow. Use the platform instructions and your vendor’s restart procedure for the actual environment.

1. Record the build: retain the full package name/revision, OS release and source, or the deployed image reference and digest. Link the advisory covering both CVEs. Use a fixed upstream release or an explicitly documented vendor backport. PHP announcement.
2. Confirm the domain assignment: have the administrator identify the PHP handler and pool used by each website. In cPanel, review the domain in MultiPHP Manager; in Plesk, review that domain’s PHP settings. A branch selection is only part of the evidence.
3. Complete worker replacement: on Ubuntu or Debian, follow the platform procedure for the serving PHP-FPM or Apache runtime. For Docker, confirm the serving containers were replaced with the updated image. Ask the administrator to account for all pools, nodes and long-running jobs; do not restart unrelated services by guesswork.
4. Take a fresh web reading: in WordPress, revisit Site Health → Info → Server. Otherwise use the restricted diagnostic method. Record the PHP version, SAPI, observation time and which site/node was covered. Request a fresh response that executes PHP rather than a cached page. WordPress · PHP SAPI.
5. Connect the two records: ask the administrator how that website-side reading maps to the fixed package/image. One request does not inspect every worker or node. A backported package can retain the same short PHP version before and after the fix.
6. Check application behavior: test the site’s key workflows and review new errors. Remove temporary diagnostic pages. Keep the build, restart/replacement and website observation records together. Investigate suspected earlier compromise separately.

When the evidence disagrees

If CLI is updated but the website still reports an older runtime, keep the website update unresolved. Ask the host to check the assigned handler, old workers, other nodes and cached diagnostic output. If a vendor backport is claimed, request its full revision and advisory; neither an old-looking version nor a new-looking header settles that question.

With limited access, send the request below through your provider’s private support portal. Replace the bracketed fields there; do not send private hostnames or logs to this site.

Copy a hosting support request

Subject: Confirm PHP2Shell update for my website

Website/domain: [fill in privately in your host's support portal]
Observed website PHP version and SAPI: [fill in, or unknown]
Observed at (UTC): [fill in]

Please confirm the PHP runtime actually handling this domain's web requests, not only the command-line PHP installation.

1. Provide the full installed PHP package name and revision, OS release and package source, or the exact deployed image reference/digest.
2. Link the vendor advisory confirming fixes for CVE-2026-109618 and CVE-2026-109619 in that build. If the short PHP version is unchanged, identify the backported revision.
3. Confirm the runtime/handler assigned to this domain and that all relevant PHP workers, pools, server nodes and long-running jobs were restarted or replaced under your vendor procedure. Please include the completion time in UTC and any remaining scope.
4. Provide a fresh website-side PHP version and SAPI observation after the change, and explain how it maps to that fixed package/image on every serving node.
5. If the update is still pending, explain the remaining exposure, temporary measure limits and planned completion time.

Please do not send credentials or a full public phpinfo dump. A package update alone does not confirm the website has switched to it. This request is for update verification; any suspected earlier compromise needs a separate investigation.