Recovery planning

What should I do if a PHP security update breaks my website?

PHP Site Audit · Updated 2026-10-25

The direct answer

If a PHP runtime update breaks the site, capture the exact failure and affected routes, then involve the application and hosting owners to isolate compatibility, extension, configuration, or process-restart causes. Prefer a tested compatible patched runtime or vendor-supported backport. Avoid routinely rolling back to a known-vulnerable package; if a temporary exception is unavoidable, document its scope, compensating controls, owner, expiry, and rapid re-patch plan.

Capture the failure before changing more

Start by recording when the failure began, which environment and hosts are affected, the change identifier, the deployed PHP package or image, and whether the issue affects every route or a specific workflow. Preserve relevant application and server logs, PHP startup errors, deployment output, and process status. Separate a blank page, HTTP error, missing extension, syntax or deprecation message, failed database connection, and background-job failure; each points to a different investigation path.

Separate runtime from application symptoms

Ask whether the web handler, CLI jobs and workers all received the same runtime. Check that the required PHP extensions and configuration are present in the serving SAPI, not merely in a shell. Compare the failing release to the last tested staging configuration and identify any other simultaneous application or dependency changes. Avoid making several emergency edits at once, because that obscures which change restored or worsened behavior.

Prefer a compatible patched recovery path

If the chosen upstream runtime is incompatible, first ask the distribution or hosting provider whether it offers a supported security backport for the existing compatible branch. Another option is a supported patched runtime that matches the application’s compatibility matrix. Roll forward with an application or extension fix when the failure is caused by unsupported code, and validate the precise combination in staging. Escalate to the host if the affected package is provider-managed and you cannot change it safely.

Time-bound any emergency exception

A rollback to the previous runtime may restore availability but can reintroduce the exposure the emergency update was intended to remove. Do not make that the default recovery path. If the incident commander approves a temporary rollback because no safer option is available, explicitly name the affected hosts, restrict exposure where feasible, assign an owner and expiry, preserve monitoring, and schedule a tested return to a patched runtime. Record the decision and make the residual risk visible to the service owner.

Use a support and acceptance template

Support ticket: ‘At [time and timezone], deployment [change ID] changed PHP runtime [package/image and revision] on [hostnames/environment]. The observed failure is [exact route, status, log excerpt or job outcome]. The last known-good application/runtime combination was [identifier]. Please confirm the vendor-supported patched runtime or backport for this OS and application version, the correct handler/worker restart procedure, and whether [specific extension/configuration] is available. We will keep the affected environment under [mitigation] until [named owner] validates the fix.’

Acceptance: staging reproduces the production service map; the selected runtime is covered by an authoritative advisory; the web handler and background workers run the intended patched build; the failing workflow and agreed critical journeys pass; logs contain no new blocking errors; and any temporary exception has an owner and removal date. Record what was not tested. A homepage load alone is not enough to close a checkout, login, API, or queue regression.

After the service is stable, preserve the timeline, exact change set and any temporary mitigations for a follow-up review. Use the evidence to add a repeatable staging case or compatibility check before the next maintenance window. The goal is to identify the actual incompatibility and remove the exception, not to turn an emergency rollback into the permanent patch strategy.

Common questions

Should I immediately roll back PHP if the site errors?

First identify the failure and seek a compatible patched runtime or vendor backport. A rollback can restore a known vulnerability and needs explicit risk handling.

What logs should I save?

Preserve timestamps, deploy identifiers, application and PHP startup errors, handler/process status, affected routes, and background-job outcomes.

When can I close the incident?

When the patched runtime is evidenced, the intended processes are active, critical affected workflows pass, and any exception has a time-bounded owner.