Completion evidence for each site
- Package/image proof: exact PHP package revision, image digest or built binary identifier, plus official evidence that it contains both fixes. For upstream releases use the branch thresholds; for backports use the vendor notice and full revision.
- Serving-process proof: actual PHP version/build on a new dynamic request through the same origin/handler as the site; identify every replica/pool. A CLI version, response header, CDN cache hit or package install log alone is insufficient.
- Process replacement proof: deployment/service records show that old web workers, queues, Octane/FrankenPHP workers and other affected long-running processes exited. Verify the replacement’s executable/image and start time. Check newly scaled instances too.
- Functional proof: login/logout, session persistence, forms/CSRF, small upload, database read/write, background job and scheduled task; checkout/payment sandbox if relevant. Check PHP/web/queue logs, 5xx rate, latency and memory.
Prefer WordPress Site Health, existing protected diagnostics, provider evidence or an internal health route. If you must add a temporary version endpoint, restrict it to administrators/internal access, return only the required fields, and remove it afterward. Do not publish phpinfo() output.
Failure and rollback
- Decide failure thresholds before rollout: failed login, missing critical extension, rising 5xx errors, broken payment/job processing or unacceptable latency.
- Drain or restrict the failing instance. Preserve logs and package transaction/deployment records; avoid destroying incident evidence.
- Restore the previous application release on a patched compatible runtime where possible. If a runtime rollback would reintroduce vulnerable PHP, keep that instance isolated from public traffic until repaired. An old snapshot is a recovery asset, not a safe public end state.
- Restore database state only when the change actually requires it, using the application’s consistency/backup process. Runtime-only repairs should not introduce unrelated schema migrations.
- Recheck all serving nodes after recovery. Record the residual exposure, owner and next action in the change record; do not close the incident while vulnerable public workers remain.
Signs of possible compromise
Unexpected PHP files/webshells, unknown admins, unusual child processes/outbound connections, altered scheduled tasks or suspicious upload activity require the incident-response process. Preserve evidence, isolate affected hosts, and rotate potentially exposed secrets from a trusted system as warranted. Patching prevents the known paths; it does not remove an existing compromise. No exploit test is needed to prove the installed fixed runtime.
These are operator checklists. Official advisories: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).