PHP Site AuditHosting and runtime checks
What should I ask my shared host about PHP2Shell?
Ask the host to confirm the PHP package or backport serving your specific domain, the applicable fix for both PHP2Shell CVEs, and when the serving workers restarted. Shared-host customers usually cannot verify those server-side facts from the public website alone.
What belongs in the support ticket
Provide your account identifier through the host's authenticated support portal, the exact domain and subdomains, and a concise reference to CVE-2026-109618 and CVE-2026-109619. Request the PHP handler and package build serving those hosts, the vendor advisory or release that contains the fixes, and the time all relevant workers were restarted. Ask whether any older pool, staging site, scheduled task or legacy application remains on another runtime.
You do not need to include passwords, session cookies, payment data or a copy of your customer database. Ask for a written confirmation or a support article that names the package and CVEs. If the provider uses an internal package number, ask how that build maps to the security advisory; avoid demanding that the displayed version exactly match the upstream number when backports may be used.
What is a useful provider answer?
A useful response identifies the web-serving package, its vendor, whether both CVEs are addressed, and any action required from you. The PHP release notice and related fixed-version guide list upstream builds; distributions and long-term-support vendors may deliver backported fixes. A different version string can therefore be correct if the provider ties it to a documented package fix.
The host should explain whether the update was automatic or requires a panel change, whether a restart or pool recycle is complete, and whether your plan can run a supported PHP branch. If the provider cannot state what package serves your domain, ask for escalation to its platform or security team and keep the ticket open until you have actionable evidence.
If the host cannot patch immediately
PHP says its temporary mitigations reduce exposure to specific attack paths but do not make an installation safe; updating is the complete solution. Do not copy low-level php.ini directives into a shared account without the provider's advice. A setting applied with .user.ini or application code may not take effect early enough for a request-parsing issue.
The NSA advises prioritizing vendor patches and says organizations should assess taking a system offline if an immediate update is not feasible. For a shared plan, ask the provider what safe option it offers: move to a patched runtime, isolate or temporarily disable an affected site, or migrate the account. Keep a record of temporary steps and the date the actual package update lands.
Common questions
Can I patch shared PHP myself?
Usually not; the provider controls the shared runtime. Do not attempt to replace system files from an account without authorization.
Should I cancel the account because the panel shows an old version?
First request package-level backport evidence. A banner or panel string alone cannot establish vulnerable status.
Can an outside scan settle this?
No. It cannot read the host's package database, confirm all pools, or prove worker restarts.