After the patch,
operate the evidence.
A practical sequence for website owners, agencies and MSPs that need to move from emergency remediation to a current, bounded and re-checkable evidence position.
The operating sequence
Define the subject
Record the exact hostname, application, environment, provider, estate boundary and responsible party. Avoid statements that silently expand from one workload to an entire organisation.
Apply or confirm remediation
Use the relevant upstream or provider path. PHP’s 21 October guidance makes the fixed releases the complete solution for the two critical RCE flaws; hosting and platform providers may implement vendor-specific backports or managed remediation.
Collect evidence, not screenshots alone
Retain package/build evidence, provider advisory, deployment record, runtime observation where available, timestamps and responsibility boundaries. A public version string can be useful but may be insufficient where backports are used.
Separate what is known from what is inferred
Mark evidence as KNOWN, SUPPORTED or UNKNOWN. Do not turn “patched” into “uncompromised”, “WAF present” into “fixed”, or “current package installed” into proof of historical compromise absence.
Issue the Current-State Receipt
Record the subject, evidence, provenance, timestamp, scope, unknowns and next re-check trigger. Make the record resolvable so a stakeholder can examine the evidence position without relying on a screenshot sent by email.
Re-check on material change
Trigger a new check after runtime/package change, provider advisory, deployment, control-plane change, supplier change, expiry threshold or another material state event. Current evidence is an operating process, not a one-time certificate.
Evidence collection by environment
Managed hosting
Provider advisory, service/product scope, completion state, package or control-plane evidence where supplied, and responsibility boundary.
VPS / self-managed
OS/package manager output, repository provenance, service restart/reload evidence, runtime observation and administrator record.
Platform / cloud
Platform advisory, deployment/change record, environment or manifest evidence, provider scope and any known gap between declared and effective state.
Backports: the trap that breaks naive version checking
KnownHost publicly explains that a patched vendor package can retain the upstream PHP version string. Silverstripe separately reports patch deployment that did not necessarily uplift a platform manifest version. The operating consequence is straightforward: provenance and package/build evidence can be more important than a visible upstream version alone.
Public examples: KnownHost · Silverstripe. Citation is not endorsement.
What changes the evidence grade?
KNOWN
Directly observed or strongly established for the defined subject at the recorded time.
SUPPORTED
Supported by a provider, vendor, package or deployment source whose provenance is retained.
UNKNOWN
Not established by the available evidence. Do not infer a stronger claim.
MSP / agency estate workflow
Inventory clients by platform and responsibility model
Group managed hosting, VPS, platform and unsupported/legacy estates separately.
Record state per client, not per campaign
One client can be complete while another remains awaiting provider action. Preserve the distinction.
Give the client a resolvable evidence position
The output should support QBR, insurer, compliance, procurement or counterparty review without turning the MSP into a certification authority.
Choose the operating route.
Already patched: £195 Current-State Review. Need remediation and proof: £395 Patch & Verify™. Need an evidence-currentness path after that: Website Trust Continuity™. Managing client estates: use the MSP / MSSP route.
Website-owner packagesContinuityMSP / MSSP route