Information checked: 23 October 2026. This practical guide explains how to obtain and assess hosting evidence. It is not a security assessment of your individual website. Check the linked advisories for subsequent changes.
PHP2Shell hosting checks should end with a clear record about the environment serving your website. A general announcement, a green dashboard or a reassuring support reply is useful context, but each leaves questions unanswered. Which service was checked? Which vulnerabilities were covered? What was installed, when did it become active, and who is responsible for anything outstanding?
For a business owner, the aim is not to learn server administration overnight. It is to make the technical work accountable and understandable. This guide turns a broad request to “check our hosting” into an evidence pack that a host, developer and business owner can use together. For the incident background, start with our PHP2Shell overview for UK website owners.
Start with an inventory that matches the business
List the public website, shop, booking system and any separate application that customers use. Include campaign subdomains, previous website versions, staging environments and sites associated with older brands. A domain that redirects visitors elsewhere may still have a hosting account underneath it. Ask the technical owner to establish what remains deployed rather than assuming that a redirect removes every underlying service.
For each item, record the domain, its purpose, the hosting supplier and the person who can obtain a technical answer. Keep account identifiers in your private working record. Do not publish infrastructure details or passwords in a public comment. If the account is held by an agency, that agency may need to raise the request through its own authorised support channel.
Mark uncertainty explicitly. “Hosting owner unknown” is more useful than silently excluding a site from the list. Set an owner and a follow-up date for resolving that gap. The main website may be maintained carefully while an old demonstration installation receives no attention. An inventory makes those differences visible without assuming that every item has the same exposure.
Ask which PHP is actually serving requests
A hosting account can offer several PHP versions. The default shown in a control panel may differ from a version selected for a particular domain. A command-line tool may also use a different runtime from the process handling web requests. Ask the host to identify the active web runtime for each relevant application, not merely the versions available to select.
WordPress Site Health can help identify the runtime visible to WordPress. The official WordPress notice explains where to find it and distinguishes PHP maintenance from WordPress updates. A screenshot is useful for discussion, but it does not establish the full vendor package or prove that a specific backported fix is present.
A useful answer connects the website to its running environment. Ask whether any load-balanced nodes, separate pools or replacement containers also need confirmation. Those are questions for the administrator, not instructions to inspect servers yourself. If your provider confirms that one managed service covers the whole deployment, record that scope in the support ticket.
Require evidence covering both original vulnerabilities
The original incident involves CVE-2026-109618 and CVE-2026-109619. PHP published fixes on 21 October. Ask the provider to name both identifiers in its response, explain the applicable remedy, and confirm that the remedy is active for your service. A statement mentioning just one identifier should leave the second check open.
The two technical advisories describe different weaknesses and conditions. Avoid reducing the conversation to a claim that one server mode is always safe. The administrator should assess the actual deployment against the current advisories. The relevant primary references are PHP’s out-of-memory advisory and stale-state advisory.
Ask for the completion time and timezone. “Done yesterday” becomes ambiguous when tickets are read later or handled by teams in different countries. A precise timestamp helps distinguish the period before the fix from the period after it. It also helps the person reviewing logs understand the sequence of actions without reconstructing it from scattered messages.
Understand upstream releases and vendor backports
The fixed upstream releases announced for the original pair are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. These numbers are useful when the host supplies upstream PHP. Some operating-system vendors instead incorporate security fixes into a maintained package while retaining an older base version. The PHP announcement recognises vendor backports.
That means a short version label is insufficient in either direction. An older-looking label does not automatically prove that a maintained vendor package is vulnerable. Equally, saying “we backport fixes” does not prove that the package currently installed contains these particular fixes. Request the full package identifier, the supplier advisory and confirmation that the deployed build matches it.
Keep the evidence chain simple: supplier advisory, fixed package, installed package, active service. If one link is missing, ask for clarification. A package downloaded to a server is not necessarily the package running in every worker process. The host should confirm any restart or replacement needed to activate its update, using the procedure appropriate to its platform.
Separate emergency remediation from long-term support. An exceptional fix for an old branch does not establish that the branch has returned to ordinary upstream support. If a legacy application limits the available upgrade path, request an immediate incident response and a separate supported-platform plan, with compatibility work and responsibilities identified.
Include the new 23 October advisory
The 23 October PHP notice adds CVE-2026-115560 concerning an unusual combination of runtime session-serializer changes and enabled upload progress. PHP recommends disabling the feature pending its next regular bugfix release; applications that never change the serializer at runtime can retain it. The complete advisory is planned with that release.
Ask your host and application maintainer to assess this separately. A completion statement dated 21 or 22 October may accurately describe the original fixes while saying nothing about the later notice. Do not treat that timing difference as evidence that the host misled you. Request an updated assessment with a date and a clear statement about applicability.
Business owners should not copy configuration changes into production without understanding their application. The responsible administrator needs to evaluate the current advice and any functional consequences. Record the decision, who made it and when it will be revisited. This guide deliberately does not provide a configuration script or claim that the original patches close every related issue.
Distinguish protection measures from completed patching
A firewall rule, temporary restriction or other mitigation may reduce exposure while remediation is arranged. It should be described accurately. Ask what the control covers, where it applies, what remains outstanding and when the permanent action is expected. Avoid closing a patch task merely because an attack-blocking rule has been enabled elsewhere.
Provider statements also need a scope check. A notice may apply to one managed hosting product while excluding self-managed servers or legacy services. Match the announcement to your contract and account. If the statement predates a new advisory, ask whether it has been reviewed since that advisory appeared. Preserve the response rather than relying on a changing status-page headline alone.
If timely remediation is unavailable, ask the responsible technical team to recommend a risk-based temporary approach. The business owner should understand the customer impact and available contact alternatives. Do not assume that taking a homepage offline disables the underlying PHP service. The implementation and restoration conditions need to be agreed with the administrator.
Build a useful evidence record
Create one row per website or application. Record its owner, host, confirmed runtime, package evidence, original-CVE status, later-advisory assessment and completion timestamp. Add a column for outstanding work and another for the person responsible. The record can be a simple private spreadsheet; its usefulness comes from accurate entries and follow-through, not elaborate formatting.
Use clear statuses such as “awaiting host confirmation”, “remediation confirmed”, or “further assessment required”. Avoid a single green tick that could mean several different things. A completed installation, successful functional check and completed compromise review are separate observations. Keep their evidence separate so that a reader can see what is established and what remains uncertain.
Store support references and relevant supplier links alongside each entry. Restrict access appropriately and avoid adding credentials, customer exports or unnecessary logs. If detailed evidence contains sensitive infrastructure information, keep it in the appropriate secure location and reference it from the summary. The business record should not become an accidental directory of secrets.
A support request you can adapt
Send a concise request through your established support channel: “Please confirm the PHP2Shell status for the websites listed in this ticket. We need confirmation covering both original CVEs, the active runtime or vendor package, the applicable advisory, and the time remediation became active. Please also assess the PHP notice dated 23 October and identify any remaining work.”
Then add your actual inventory and ask who will own follow-up. If the provider replies only with a generic announcement, ask whether it applies to the named services. If it gives a package number without an advisory, ask for the mapping. If it confirms a fix without a completion time, request the timestamp. Each follow-up should resolve a specific missing fact.
Keep one coordinated ticket where practical. Several people opening overlapping requests can produce apparently contradictory answers about different services or times. Designate a coordinator to reconcile the replies, update the record and make unresolved questions visible. This is particularly useful when the domain owner, host and website developer are different organisations.
Check operation without confusing it with security assurance
After the host confirms its work, arrange representative functional checks. A page loading is only one observation. Check the enquiry journey, receipt of test messages, authorised account access and other essential features through an agreed test process. An online shop needs appropriate checkout testing that avoids unwanted real charges or stock changes.
Record the result and route failures to the correct owner. A broken form may be a compatibility or delivery issue, rather than evidence of compromise. Conversely, a working form does not prove that no earlier compromise occurred. Ask separately whether the exposure window or suspicious observations justify a specialist investigation.
For businesses reviewing their wider website arrangements, our web design services provide a starting point for discussing maintenance needs and responsibilities. The scope of any support should be agreed for the actual site. No generic checklist can certify an individual installation as secure.
Handle conflicting answers methodically
If one support reply says a site is patched and another says work is pending, first compare their scope and timestamps. They may refer to different domains, different runtime pools or different advisories. Send the two references back to the technical owner and ask for a reconciled statement. Do not resolve the discrepancy by choosing the more reassuring answer or by repeatedly changing the PHP selector yourself.
Record the final explanation alongside the earlier messages. Where a provider cannot supply the requested evidence, record the limitation and ask the person responsible for risk to decide the next action. An unresolved evidence gap is not proof of compromise, but it is also not a completed check. This approach keeps the discussion specific and gives the next person enough context to continue without starting again.
Frequently asked questions
Is a PHP version screenshot enough?
No. It can identify the runtime visible to an application, but vendor backports may require package-level evidence. Ask the host to connect the running service to the relevant fixed package and advisory, including activation time.
Does updating WordPress fix PHP2Shell?
A WordPress application update does not automatically update server PHP. The official WordPress notice treats the original vulnerabilities as a PHP-layer issue. Keep hosting remediation and routine WordPress maintenance as separately confirmed tasks.
Should I reject every older-looking version number?
No. A maintained vendor package can contain a backported fix. Request the complete package reference and supplier evidence. Do not accept or reject the installation solely from the abbreviated PHP version shown in a dashboard.
Can a host’s general announcement close our check?
Only when its scope clearly covers your services and the current relevant advisories. Obtain confirmation for your actual account and retain its date. A statement about a different product or an earlier advisory leaves a gap.
Does patch confirmation prove that no attack succeeded?
No. It establishes a remediation fact, subject to its stated scope. Reviewing earlier activity is a separate task that may require logs and specialist interpretation. Keep “patched” and “no evidence of compromise found” distinct.
What is the most useful outcome of these checks?
A dated, service-specific record with evidence, named owners and clear outstanding actions. It should let the business explain what has been confirmed, what remains unknown and who is taking the next step, without making an unsupported safety guarantee.
