Exposure assessment ≠ compromise detection. This guide cannot determine whether a particular system was compromised. Verify the current advisory and your exact runtime.
Send a precise provider request
Ask: “Which PHP runtime and complete package revision serve my domain? Does that build fix CVE-2026-109618 and CVE-2026-109619? Which advisory confirms it, and have all serving workers been restarted or replaced?”
Include the domain through your provider’s authenticated support channel. Do not send passwords, private keys or a public phpinfo() link. A generic “we use a WAF” answer does not establish a patched runtime.
Before you change the runtime
Record the current package revision, runtime handler, configuration and deployment topology. Confirm a current fix for both CVEs from the responsible vendor. Back up application data and configuration using a tested restore process. If an incident is suspected, preserve evidence before changing processes or files.
Test the intended PHP build with the application, extensions, scheduled jobs and database in staging. Plan a maintenance window or a rolling change with health checks. Keep a configuration and application rollback plan; do not restore a vulnerable runtime to public traffic without restricting exposure.
Check the account-level controls
Record the PHP version and handler assigned to each domain. A host can offer multiple branches; selecting a fixed branch may require an Apply action. A lower version can contain a supported vendor backport, so ask for package evidence before drawing conclusions.
Before switching a branch, back up the database and files and test application compatibility where the host offers staging. Check forms, login, payments, uploads, extensions and scheduled jobs afterward.
If the host cannot provide a fixed runtime
Escalate the request and discuss restricting affected services until a fix is available. Evaluate a supported hosting alternative if needed. Do not upload exploit tools or attempt to modify system PHP from a shared account.
If you suspect unauthorized access, ask the host to preserve relevant account, web, PHP and authentication logs. A provider’s successful patch does not answer whether the account was previously compromised.
Verify the result and handle a delayed patch
Check the actual web-serving binary, package revision or image on every instance. Replace old workers and verify their startup times. Validate application health, uploads, sessions, queue workers and scheduled jobs. CLI output alone does not prove what serves HTTP requests.
If a fixed deployment fails compatibility checks, restrict access and escalate to your vendor or administrator. Temporary WAF or configuration changes may reduce specific attack paths but are not a complete substitute for patching. Investigate suspicious activity separately: a successful update cannot establish that the system was never compromised.
CHECK THE ORIGINAL GUIDANCE
Sources & further reading
PHP project · October 2026 security releases↗Automattic · Hosting security guidance↗Advisory snapshot: 2026-10-22. Next review due: 2026-10-29. Recheck sources before acting; this site does not update advisories automatically.