PHP2Shell on Hostinger: check your hosting protection

What Hostinger reported, and when

At the time checked, Hostinger’s article was updated on 22 October at 07:20 UTC. It states that PHP’s fix has been installed on its hosting servers except VPS, which customers manage themselves. The provider also describes firewall protections. Read the live advisory for later changes and keep the date of the statement you rely on; a screenshot or article from an earlier rollout stage may describe a different position.

Treat that announcement as a provider statement about its platform, not independent evidence that an individual website was never compromised. It also does not describe every hosting business that uses a similar control panel. If your website has moved between plans or runs through an outside server, establish the actual origin and service first. The commercial name on an invoice is not always a complete infrastructure map.

The first question: managed hosting or your own VPS?

A website builder, DNS zone, CDN and origin server can be supplied separately. Follow a dynamic request such as an enquiry submission to the system that executes it. If an agency manages your account, ask for the runtime supplier and patch confirmation rather than requesting your control-panel password over email. Responsibilities should be clear enough that each party can name the action it has completed.

Why the visible PHP version may not settle the question

PHP’s version function reports the parser’s version string. That is useful identification, but it is not a signed statement of security maintenance. A provider can apply a backported correction while retaining the same familiar version label. Conversely, a new-looking label viewed on the wrong domain or in a command-line session does not verify the interpreter handling a production web request.

Ask for evidence that corresponds to the actual service: the provider’s advisory, the affected plan, the corrected build or backport mapping, and confirmation that the serving processes use that build. On managed hosting, a customer may not have access to package logs or worker start times. A scoped provider confirmation is then more meaningful than repeatedly refreshing a version selector that cannot expose those details.

Use build dates as supporting evidence, not a universal safety rule

A build date tells you when a binary was built, not which changes were included. Its interpretation depends on the supplier’s documented process. If a provider explicitly maps a particular build to a correction, that mapping can support verification within that provider’s stated scope. A date copied from another host or distribution does not establish the same result on your account.

For a stronger record, connect the date to the named provider build, the two CVEs and the service that runs it. A newly compiled custom binary could still omit a patch; a distribution package with an older upstream base can contain a maintained backport. The useful question is not “Is the date recent?” but “Which trusted evidence shows that this running build contains the required fix?” This distinction prevents both false reassurance and unnecessary emergency migrations.

Check safely without leaving a public phpinfo page

Prefer the hosting control panel’s existing authenticated information and a support confirmation. Hostinger currently points customers to Websites, Dashboard, then PHP Info, and maps a build date of 21 October 2026 or later to its corrected managed builds. Treat that as a statement about Hostinger’s documented build process, not a rule for every PHP server.

Do not add a public diagnostic file just so anyone can inspect the server. A broad phpinfo response can expose configuration and environment details that are unnecessary for a customer’s patch record. Share the minimum information through an approved private support channel.

1. Identify the account, plan and affected domain without sending credentials.
2. Read the provider’s current advisory and confirm it covers the plan.
3. Check which PHP handler is assigned to the affected website in the authenticated hosting view.
4. Ask support to confirm the origin-runtime correction and whether old serving workers have been replaced.
5. Retain the answer, its date and any limits; verify the website’s normal functions after any change.

If an administrator requires additional runtime information, use a pre-existing protected diagnostic or a temporary endpoint that is access-restricted before it is deployed. Return only the necessary fields and remove it promptly. Do not rely on an obscure filename as access control, and do not paste the full response into an initial public support forum.

A useful support request that asks the right questions

Subject: PHP2Shell runtime confirmation for our hosting service

Domain: [your domain]
Plan or server identifier: [non-secret identifier]

Please confirm whether this service is covered by your current
CVE-2026-109618 and CVE-2026-109619 remediation.
Does the confirmation cover the origin PHP runtime as well as firewall rules?
Is the corrected build or backport active in the processes serving this site?
If the visible PHP version is unchanged, what advisory or build mapping
supports the fix? Please identify any customer action still required.

This template deliberately asks about coverage and process state rather than demanding a particular upstream version from every managed platform. If the response concerns only CDN rules, ask again about the origin. If it confirms a platform rollout but excludes your VPS, move the request to your server administrator. A clear answer can be short; completeness depends on scope, not the amount of technical language in it.

What a VPS owner still needs to arrange

For a self-managed VPS, identify the operating-system or panel supplier of PHP. Use that supplier’s update path and verify the active services after the change. Include additional domains, containers and background components rather than updating only the default command-line interpreter. If server management is contracted out, require a completion record that covers the named VPS, not a general statement about the hosting provider’s managed platform.

Before the update, prepare a recoverable configuration and a protected management route. Afterwards, test business functions and monitor errors. If there are suspicious files, unexplained accounts or other compromise indicators, begin a recovery investigation as well. Package maintenance repairs a runtime vulnerability; it does not automatically remove changes an attacker may already have made to the website.

Check the website after provider or administrator work

• Test an uncached dynamic page and the real enquiry form using non-sensitive test content.
• Confirm both successful submission and safe failure feedback rather than relying on the homepage alone.
• Check authenticated sessions, background jobs and required extensions where applicable.
• Confirm the public domain, staging service and any external API have separate closure records.
• Keep provider correspondence and operational evidence in a private change record with an owner.

In an illustrative agency setup, the main website may use managed hosting while a booking integration runs on a VPS. The managed platform announcement can close the runtime question for the first service after scope confirmation, but not for the second. Recording those as two rows prevents one reassuring email from being overextended to systems it never covered.