How to Update PHP on Hostinger and Verify the Security Patch

First establish whether this website uses PHP

Identify the application, not only the company providing the server. A WordPress site uses PHP, while a Next.js/Node.js application is a different runtime. The same hosting account can contain both. A PHP maintenance instruction should not be applied blindly to a Node application's build configuration.

List the relevant websites and explain why each is in scope. Include older installations, preview domains and products that may contain PHP behind the scenes. If the owner does not know, ask support to identify the runtime for the specific hostname rather than making a global assumption about the account.

For the current security event, keep our PHP advisory overview open as a reference. The purpose of this article is navigating ownership and verification in Hostinger, not duplicating an upstream version table that may be superseded.

Use PHP Configuration, with the hosting-plan scope in mind

Hostinger's PHP version-change instructions describe opening Websites, selecting the website's Dashboard and using PHP Configuration to select a version and apply Update. The documentation says a plan-level selection can affect multiple websites, with exceptions for some products/configurations.

Before clicking, identify that scope in your actual panel. Do not assume a label visible beside one domain means the change is isolated to that domain. If several client sites share the plan, tell their owners which maintenance window and checks are planned.

Use the support article for the current interface. Hosting menus change; instructions for hPanel are not automatically instructions for a VPS, cPanel or a different application-hosting product. An absent control is a reason to identify the product, not to paste a random server configuration into the site.

A branch selector does not prove a security patch level

A selector showing “PHP 8.4” identifies a release family, not necessarily the full patched build or a vendor backport. Obtain the full runtime information through the documented PHP Info view or the application's protected diagnostic interface.

Hostinger's PHP checking guide documents PHP Info and notes that folders or subdomains can use different versions. Treat configuration overrides as a separate verification item. Its example screenshots are illustrations, not current patch evidence for your account.

Prefer those authenticated diagnostics to a publicly reachable phpinfo page. If support needs a temporary diagnostic, protect it, expose the minimum information needed and remove it immediately afterward. A full diagnostic dump can reveal much more than a version.

Send a support request that cannot be answered with only “updated”

Here is an original support template you can adapt: “I need confirmation for these hostnames against the current PHP security advisory. Please provide the full serving PHP build/package revision, whether the fix is upstream or backported, when affected workers were restarted/replaced, and whether folder/subdomain overrides remain outside the plan-level update. Please identify any action required from me.”

Do not include passwords in the message. Add the account or website identifiers through the authenticated ticket system. Keep a copy of the answer with your maintenance record rather than relying on a chat notification that another administrator cannot find later.

If the provider reports temporary filtering, record it separately from the runtime fix. Ask when permanent remediation will be verified. Avoid announcing that the account is secure simply because a filter has been enabled or a new branch is available in the selector.

Plan compatibility checks around real activity

Before the change, confirm backup availability and decide who will handle failures. A WordPress brochure site may need login and contact-form checks; an online store also needs cart, checkout and scheduled-job verification. A custom application may depend on particular extensions or queue processes.

Create a test matrix with columns for journey, expected result, responsible person, observed result and evidence location. Use controlled test addresses and test payment modes where applicable. The matrix is a planning tool, not proof that FinderPress executed any of these checks.

After the change, test through a route that reaches the application, not only a cached homepage. Check the relevant server diagnostics and review new errors. Confirm the configuration of any separately managed subdomain or directory identified earlier.

Avoid an improvised .htaccess rollback

Hostinger documents per-folder and subdomain version overrides. Those overrides can make the runtime different from the plan-level setting. A copied handler directive can also select an unsuitable build or omit an expected configuration.

Do not use an older handler as a routine workaround for a critical security update. If a dependency fails on the fixed environment, ask support and the application maintainer for a supported resolution. Document any temporary restriction or downtime rather than concealing an unpatched exception.

Completion evidence for a managed-hosting account

Keep the account/product name, affected hostnames, original observation, new serving build, supplier confirmation, override checks and functional results together. Include the source-check date because security advisories and hosting instructions can change.

This workflow was prepared against official documentation checked on 22 October 2026. It intentionally does not assert a Hostinger-wide deployment status. Only account-specific provider evidence and verification can establish the state of your site.