Home / PHP patch verification: evidence to request from your hosting provider
PHP patch verification: evidence to request from your hosting provider
A completed update ticket is useful, but it does not tell you which applications were covered or what evidence supports closure. Start with an inventory, connect each system to its vendor fix, and record what remains unresolved.
1. Identify the systems behind the website
List the public website, customer portals, online stores, administrative tools and scheduled jobs separately. Record the system owner, hosting provider, runtime source and whether the application is internet-facing. A managed service can use PHP even when the business does not administer PHP directly. Ask the provider about the service you actually use rather than assuming that one server update covers the entire estate.
2. Ask for vendor evidence, not just a version screenshot
The PHP security advisory dated 21 October 2026 identifies fixes in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 for CVE-2026-109618 and CVE-2026-109619. That is a dated advisory baseline, not a permanent list of the latest releases. Consult the current PHP and distribution advisories before changing a system. Distribution vendors may backport a fix without adopting the upstream version number, so a package version alone can be misleading.
Request the vendor advisory or package changelog, the installed package/build evidence, the affected system list and the completion time. Ask how running services were restarted or replaced where required. A command run in an administrator's shell does not necessarily identify the runtime used by every website or container.
3. Separate remediation from investigation
Updating closes a vulnerability when the correct fix reaches the relevant running environment. It does not establish that there was no earlier compromise. Agree which logs and evidence are available, the relevant review period and who is responsible for investigating suspicious activity. Missing logs are an evidence gap, not a clean bill of health.
4. Keep an exception register
Record systems that are unsupported, awaiting a provider response or not yet verified. Give every exception an owner, next action and review date. If an update cannot be applied promptly, follow the vendor's current guidance and involve the responsible security team. Do not treat a temporary mitigation as equivalent to a complete fix.
A closure record your team can inspect
- System and owner, including the hosting relationship.
- Applicable advisory and evidence that the vendor fix is installed.
- Evidence that the intended running environment was updated.
- Review period, available evidence and unresolved investigation questions.
- Exception owner, action and next review date.
Use the worksheet to organise a conversation; it is not an automated vulnerability scanner or incident-response certification. Do not postpone vendor updates while arranging a review.
Use the PHP patch evidence worksheet
Sources and scope
This article explains a review approach; it does not report a customer deployment or guaranteed result.