GUIDED REMEDIATION
A careful update.
A clear record.
Work through ten steps. This guide never runs an update or accesses your infrastructure.
Published · Sources checked · Next review due 29 October 2026
WordPress: use the existing authenticated Site Health information or hosting panel, then coordinate the PHP update with your host. Keep a tested database-and-files backup and test theme/plugin compatibility in staging. A WordPress update alone does not patch PHP.
Progress stays in memory until you close or reload the page. Download a local record if you need to retain it. Tick a step only after you have completed it in your own authorised process.
STEP 01 / 10
Identify every runtime
Inventory the web server, PHP handler, hosting account, containers, background jobs and applications that bundle PHP. Check the PHP version in the authenticated hosting panel or existing application health view. CLI PHP can differ from the web runtime. Do not publish a phpinfo() page.
STEP 02 / 10
Confirm who manages the installation
Identify the provider, OS release, package source and person authorised to approve changes. Confirm scope, a contact route and an outage window. Do not change a customer’s infrastructure without explicit permission.
STEP 03 / 10
Verify the affected status
Use the version checker with the confirmed installation source. For distribution packages, record the full package revision and match both CVEs in the vendor’s record. Ask managed hosts to confirm the fix and restart status in writing.
STEP 04 / 10
Create and verify backups
Back up application files, databases, configuration and the information needed to restore service. Keep a protected copy away from the web server. Test a restore in isolation and record the recovery point and access needed. A compromised snapshot is evidence, not automatically a trusted restore source.
STEP 05 / 10
Test in staging
Use a representative isolated environment. Check PHP compatibility, required extensions, configuration, login, forms, uploads and key business flows. Disable real payments, email delivery and third-party actions in staging. If staging is unavailable, agree a vendor-led maintenance and recovery plan.
STEP 06 / 10
Apply approved updates
Use your hosting panel or the established signed vendor package channel. Review the intended changes and follow vendor instructions for your exact release. Do not run a one-line command copied from an untrusted page or switch package sources casually.
STEP 07 / 10
Replace running workers
Follow the vendor’s restart or reload procedure, checking that all old PHP workers are gone. Include PHP-FPM pools, Apache/mod_php or Windows application pools as applicable, plus containers and replicas. Package files on disk alone do not prove that running processes use the fix.
STEP 08 / 10
Validate functionality and version
Recheck the running web PHP and full installed package. Test the homepage, login, forms, uploads, scheduled jobs and critical business journeys. Perform checkout tests only in a test environment. Record successful checks and any new errors.
STEP 09 / 10
Review signs of compromise
Preserve and examine web, PHP, authentication, deployment and application logs around the exposure window. Investigate new administrator accounts, unexplained file changes, scheduled tasks, outbound connections and repeated worker crashes. These signs are not specific proof of either CVE; no obvious sign does not rule out compromise.
STEP 10 / 10
Document and follow up
Record the owner, evidence, package revision, restart time, validation, decisions and outstanding actions. Monitor after release. If a rollback would restore vulnerable PHP, keep the affected service restricted or offline while an authorised responder agrees a safe alternative.
Sources: UK NCSC: Critical security issue affecting PHP · PHP official security announcement.
Suspected compromise needs an incident process. Use the incident resources and ask for qualified assistance before destroying or overwriting evidence.