Agency operations
Prioritize PHP2Shell updates across client websites
For agencies managing several hosts and clients, start by finding who controls each PHP installation. Track the update, running build and application checks for every server, with unresolved work assigned to a person.
In this article
Group sites by who can change PHP
A client list is not a server inventory. Several domains may share one PHP service, while one shop may use several web servers, background workers and administrative tools. Group sites by their actual runtime and update owner before assigning changes.
Start with exposed systems that have no confirmed fixed build or have signs requiring investigation. Consider business impact and recovery readiness alongside exposure. A managed-hosting announcement and a self-managed server need different follow-up.
A WordPress or plugin update does not normally replace hosting PHP. WordPress directs site owners to their host for this release. WordPress's PHP security notice.
Build a site and server inventory
| Field | Include |
|---|---|
| Client and scope | Client, live domains and agreed responsibility |
| Hosting | Provider, plan, server or container and environment |
| PHP owner | Named host team, agency administrator, client IT or product vendor |
| Runtime | Branch, full build, package supplier and where the details came from |
| Other entry points | Administrative tools, direct origin addresses, appliances and jobs |
| Decision owner | Who approves interruption, application changes and recovery |
| Current task | Update, runtime check, app test or supplier answer, with owner and next review |
WordPress administrators can read Tools → Site Health → Info → Server. Record the environment and time. That request does not account for every backend. See the WordPress and WooCommerce checklist.
Assign the next action to the right owner
| Setup | Next action | Keep open until |
|---|---|---|
| Your server with no confirmed maintained build | Find supplier coverage or plan an upgrade and temporary access limits | Supported fix and running PHP are confirmed |
| Your server with an available vendor fix | Prepare recovery, install the approved package and check workers and applications | Every affected runtime and agreed task is checked |
| Managed hosting | Get the provider's account-specific confirmation and test customer tasks | Host coverage and application outcomes are recorded |
| Client IT or bundled PHP in a product | Assign the client or vendor ticket; follow the product advisory | Affected product/version and vendor action are resolved |
Use the PHP verification guide for technical checks and the older-PHP guide where maintenance is uncertain. Public version scans cannot establish a particular host's package or worker state.
Check later advisories separately from the original PHP2Shell pair. PHP's October 23 session guidance and the SimpleXML regression report are relevant follow-ups. A closed source-code issue alone does not establish that a supplier shipped the correction.
Read the notice for the actual hosting plan
| Provider | Reported action | Agency follow-up |
|---|---|---|
| Hostinger | Managed hosting upgrades completed. Its October 23 update says Web, Agency and cPanel Hosting already have the session-upload mitigation. VPS customers manage PHP themselves. | Confirm the plan. Follow its build-date check for managed hosting; assign VPS update and configuration work to the administrator. |
| GoDaddy | October 22 notice says managed services, including Web Hosting and Managed Hosting for WordPress, were patched. Self-managed servers and VPS require customer updates. | Do not apply a managed-plan statement to a client's VPS. |
| Cloudways | October 22 notice says active servers were updated and a subset of customers would receive help. The incident was marked resolved October 23. | Keep any server-specific support issue open and ask about stopped servers. |
Hostinger says its backport can retain a number such as 8.5.11. Its stated check is a PHP Info build date of October 21, 2026 or later. That test belongs to Hostinger's described managed builds; do not apply it as a universal PHP rule.
For another provider or a bundled appliance, use that vendor's current advisory. Save the relevant statement and time, then request the missing detail for the client's exact product or account.
Keep one clear update record per client
Record the responsible administrator, affected sites and runtimes, supplier notice, full build, update and restart times, running-worker findings and application checks. Include the person who confirmed each item and any remaining failure.
A shared server's update record may support several clients, but keep each client's domains, tests and open items identifiable. Share only the information that client needs. Keep passwords, tokens and other clients' information out of the report.
When a client asks about certification or insurance timing, attach the relevant evidence and identify the person interpreting the requirement. The deadline guide separates patch requirements from policy examples.
If access must stop, serve a useful status page
Agree the interruption with the client and administrator. A static page outside affected PHP can explain what users should do and when the next update will appear. Check alternate hostnames and direct server access so the restriction covers the intended system.
Google recommends a 503 response for a short emergency closure, with a suitable Retry-After header. Keep robots.txt available. Avoid using 404, 410 or noindex as a temporary closure mechanism. Longer closures need a different plan and can affect search visibility. Google's site-closure guidance.
Check the response for the actual public URL:
curl -I -X GET 'https://www.example.com/'Replace the example address with the authorized site. A maintenance page does not automatically stop payment callbacks, background jobs or other writes. Include those in the interruption plan.
Investigate suspicious activity separately
Preserve available web, PHP, host and deployment logs before they expire. Record the period and systems examined. If evidence suggests compromise, use the client's incident process and coordinate containment with the update.
JPCERT/CC recommends investigating for compromise alongside mitigation. Its guidance also cautions that finding no traces cannot prove no compromise occurred. JPCERT/CC advisory, in Japanese.
A useful finding names the systems, dates, evidence examined and limitations. Avoid turning a routine package update into a claim that every earlier attack has been ruled out.
Give clients a short, specific status
Use these fields for a status note, filling in only confirmed facts:
- Checked: sites, servers and environments.
- Changed: packages or settings and time.
- Passed: running-PHP and application checks completed.
- Open: failures, missing supplier evidence and investigation limits.
- Next: responsible person and next review time.
Attach or link the relevant update record through the client's approved channel. Do not include another client's server details.
Use free tools to interpret supplied details
The PHPFixes version lookup compares details you enter. The free Codex and Claude Code skills can help interpret supplied package and process records. Neither turns a host's generic announcement into a verified result for every client.
Paid PHPFixes services remain paused. If work is already assigned to a host or client administrator, keep that task with its owner while evidence is gathered.
Questions agencies need to resolve
Can a public scanner settle a client's status?
Use it as a lead. A reported version may omit backports or describe only one response path. Request package and runtime evidence.
What if the server hides its PHP version?
Ask its owner for authenticated inventory or provider confirmation. A hidden banner does not establish either vulnerability or a completed fix.
How long should a temporary 503 last?
Keep it brief and review the closure daily. Follow Google's current guidance for longer interruptions and tell the client about search consequences.
Does insurance pay for a voluntary closure?
Ask the client's broker or insurer using the issued policy. Record the answer before making assumptions about interruption losses.
How should we answer an insurer's alert?
Provide the client's dated update record, remaining tasks and responsible people. Refer coverage interpretations to the insurer or authorized adviser.
What if an appliance vendor gives only an estimated fix date?
Record the product, affected version, advisory and estimate. Assign follow-up and approved access controls. Do not present an estimate as a shipped release.
Can a third-party product list close vendor tickets?
Use it to locate possible affected software. Close the ticket only with the exact vendor's status and evidence for the installed version.
Sources
Provider statements above come from their linked status notices, checked October 23, 2026. They are provider reports, not PHPFixes tests of customer accounts. Google and JPCERT/CC supply the linked closure and investigation guidance. The inventory and client-record format are practical recommendations.
For each server your agency controls, work through the package and running-PHP checks.