PHP Site AuditOperations
PHP2Shell developer handoff: evidence to include in the ticket
A useful PHP2Shell handoff names the domains and runtimes in scope, the authoritative vendor fix, the package or image to deploy, the serving processes to restart, the verification steps, and an owner for each task. Separate confirmed facts from assumptions so the ticket can be closed with evidence.
Create an actionable scope
List every production hostname or service that executes PHP, its serving SAPI, environment owner, and deployment path. Note whether the runtime comes from a distribution package, managed host, container image, or source build. If any row is unknown, assign an owner to identify it rather than silently excluding it.
Reference PHP's October 21 advisory for CVE-2026-109618 and CVE-2026-109619. Use the fixed upstream versions when applicable, or attach the operating-system/provider advisory and package ID when a backport is supplied.
Write acceptance criteria that can be checked
Ask the operator to record the deployed package or image digest for each runtime, the time serving workers restarted, and evidence that the relevant service is healthy. Ask the application owner to exercise a short list of high-value public and authenticated workflows. Include the upload-progress configuration recommendation and note whether any application changes the session serialization handler at runtime, since PHP's October 23 notice describes CVE-2026-115560 under that uncommon configuration.
Use separate checklist items for the PHP runtime patch and application health. A successful page load alone does not demonstrate that every pool uses the fixed build; a patched build alone does not demonstrate that checkout or login still functions.
Name one person responsible for obtaining host evidence and another for application tests. Set a due time for unanswered vendor questions, note any temporary controls, and record what evidence will allow the issue to be closed; this avoids treating an update request as completed remediation.
Close with a bounded statement
The ticket should say which systems were verified, which evidence supports that status, what remains unknown, and who owns remaining work. Avoid broad claims such as 'all PHP sites are safe' unless the inventory truly covers every runtime and a separate security review supports the claim. A public response scan can add context but does not replace deployment evidence.
Common questions
Who confirms the PHP package is fixed?
The host or server operator supplies package and restart evidence; the developer tests application compatibility and code paths.
What evidence belongs in the ticket?
Save the vendor bulletin, hostname-to-runtime mapping, deployment record, worker restart and representative verification results.
Does a working browser page close the ticket?
No. A successful response does not prove the server package or that every worker uses it.