PHP Site AuditDeployment and operations
What should I back up before a PHP security update?
Before a runtime update, confirm that you have a recent, restorable backup of the application files, database and deployment configuration, plus a rollback method for the PHP package. Test restoration or the release process where possible. A backup is preparation for recovery, not a reason to delay an urgent security fix.
Back up the parts needed to recover
For a site you operate, identify the source of truth for code and configuration, the database, uploaded media, and any environment-specific secrets or settings needed to restore service. Verify that the backup completed, is protected from unauthorized access, and can be restored to a test environment. A file archive without its database, or a database dump without uploaded content, may not recover the actual site.
For hosted systems, ask the provider what is covered and when the latest recoverable snapshot was taken. Confirm whether the backup is independent of the runtime update and how long restoration takes. Do not put passwords or payment data into a support ticket to prove the backup exists. Keep a change record with the snapshot reference, time, owner and restoration result.
Plan the runtime change and rollback
Record the current PHP package, handler, configuration, extensions and serving pools. Confirm the target package fixes both CVE-2026-109618 and CVE-2026-109619, either as an upstream release or through documented vendor backport evidence. Plan how the host will activate it and restart the worker processes; a backup of application data does not update those workers.
Define rollback criteria before the change: for example, a sustained availability issue or a critical application regression. Preserve the patched package and vendor instructions. Rolling back PHP may restore an outage but also reintroduce the known vulnerability, so treat it as a short emergency bridge with an owner, deadline, compensating controls agreed by the security team, and a replacement plan.
Test the restored and updated site
When practical, apply the update first to a staging copy and test representative pages and workflows. After the production change, check the application through the real web runtime, inspect service health and error logs, and verify that all hostnames or replicas were updated. For a store, test checkout in the correct non-production mode before completing a carefully controlled production smoke test.
A successful restore test proves that one backup can be recovered under the tested conditions; it does not prove every file, secret or external integration is covered. A successful page load likewise does not prove the PHP package patch. Keep the two kinds of evidence distinct: recovery readiness and runtime security status.
Common questions
Should a backup be kept on the same server?
A copy on the same system may not survive a host-level failure; follow your organization's protected backup design.
Should I delay patching until I have a perfect backup?
PHP calls updating the complete fix. Escalate immediately to the host/security owner and balance recovery readiness with exposure.
Does restoring a snapshot restore the patched PHP?
Only if that snapshot or image includes the patched runtime; verify the package afterward.