PHP security updates
PHP2Shell: verify the PHP runtime in use
PHP2Shell remediation needs runtime inventory, controlled updates, worker restarts and application checks, with remaining issues recorded separately at handover.
PHP2Shell remediation needs more than an installed package version. The PHP serving web requests and the runtime used by scheduled jobs both need to be identified.
Inventory the runtimes before changing packages
A managed server can contain several PHP installations. Websites may use different FPM pools, while scheduled jobs use the system command-line binary. Updating one installation can leave another workload on a different branch.
The PHP security advisory identifies CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell, and the security releases issued for them. It also carries later guidance on session upload progress. Those updates need to be read together with the applicable package-provider advice.
In the anonymised work behind this note, we mapped web runtimes and scheduled-job dependencies before updating. That inventory exposed an older command-line branch alongside a newer web runtime. The operational task therefore included compatibility checks, beyond changing the website's PHP version.
This is where managed server support and application maintenance meet: the server inventory needs to explain which business operations each runtime supports.
Verify the processes after the update
The documented interventions included configuration backups, PHP package updates, configuration validation and restarts of the affected FPM services. Running processes were then checked against the corrected versions. An installed package alone would have left that last question unanswered.
Where the old command-line branch required migration, compatibility scenarios were run under both runtimes before the switch and repeated afterwards. Scheduled executions were observed, while checks avoided issuing financial documents or sending operational messages just to prove that a script could run.
Keep a recovery path and a clear list of affected services. A rollback plan should explain how service would be restored and how any resulting security exposure would be managed. Reverting to a vulnerable runtime is not a completed security fix.
Temporary configuration controls also need to be tracked against the advisory that justified them. Updating packages should not silently remove a control that remains relevant to a separate finding.
Report the validation limits honestly
The recorded checks covered service configuration, running PHP versions, selected web endpoints, health responses and scheduled-job observations. No regressions were observed in those checks. That statement has a defined scope and does not mean every business journey was exercised.
Pre-existing certificate, DNS and external-service authentication failures were recorded separately. They did not become fixed because PHP had been updated, and they should not be attributed to the update without evidence.
The handover should distinguish packages updated, workers verified, compatibility checks completed and follow-up items. It should also separate vulnerability remediation from compromise investigation. A successful update does not prove that an earlier intrusion never happened.
A useful remediation review and an incident-style handover make those boundaries visible without publishing client names, server addresses or internal evidence.
Practical takeaway
- Map web, CLI and scheduled-job runtimes independently.
- Verify running workers after updating their packages.
- Check compatibility without triggering real financial or communication actions.
- Keep unrelated failures and untested journeys in the handover.