Hostinger PHP2Shell status: what it says and how to check

At our check on 26 October 2026, Hostinger's status page said PHP fixes were complete on all managed hosting (Web, Agency and cPanel Hosting) from 22 October, 06:44 UTC, and asked those customers for no action. VPS customers manage PHP themselves. To confirm your own site, read the Build Date in hPanel PHP Info.

For the PHP2Shell bug itself and how to fix a server you run, see PHP2Shell: affected versions, fixes, and what to do now.

Which Hostinger products does the status page cover?

The incident is titled "PHP Security Update for Web, Agency and cPanel Hosting". It names those three. VPS is covered by a customer guide. Cloud Hosting is not named in the incident. Hostinger's guide, in its 22 October update at 07:20 UTC, says the fix is now installed on all its hosting servers except VPS. We checked that on 26 October 2026. Confirm it with the Build Date for your own domain.

The status entry had no Resolved update at our check on 26 October 2026. Its latest update was posted 23 October 2026 at 12:53 UTC.

Why does my Hostinger site still say PHP 8.5.11?

Hostinger says it added the fix to the PHP version a site already runs, so the number stays the same. This is a backport-style fix, and a version string cannot show it. Distribution packages work the same way, which is why a version check from outside cannot settle the question.

Hostinger's own test, in its status update and guide, is the Build Date. In hPanel, open Websites, then Dashboard, then PHP Info in the sidebar. Hostinger says a Build Date of 21 October 2026 or later means the site has the fix. An older date means ask support, with a screenshot.

Two cautions. The Build Date shows the build the page was served from, not the state of every other PHP version you may have set on other domains or folders. And it does not tell you that every worker restarted. Neither Hostinger's status incident nor its guide says whether every worker serving a site was restarted, so that stays unknown until Hostinger confirms it.

Did "not vulnerable" mean I could skip patching?

Hostinger's 21 October update said its platform was not vulnerable and that it would roll out patched PHP anyway. The PHP project's notice says all installations serving web requests are at risk, and names PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. We have no test that settles the difference and we do not claim one. What matters for you is that Hostinger did roll out fixes, and that it has since described the work as upgrades, with a Build Date you can read.

If support chat tells you "you are not affected", ask for the build date and the date it was installed. A sentence is not evidence.

How do I fix it?

What should I do on Hostinger Web, Agency or cPanel Hosting?

Hostinger says no action is needed. If your plan runs cPanel, updating PHP in cPanel is covered on its own page. To confirm, send support this, and keep the reply:

For [your domain], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the fixed build date or backport identifier, confirm the workers serving it were restarted or replaced, and say whether I need to change a setting. My hPanel PHP Info shows Build Date [date].

• Open hPanel, Websites, Dashboard, PHP Info and note the Build Date.
• Check each domain or subdomain separately if you set different PHP versions.
• Save the support reply with its date.
• Do not rely on a WordPress, theme or plugin update. The bug is in PHP, and Hostinger says so too.

What should I do on a Hostinger VPS or a server I run myself?

Hostinger says VPS clients manage PHP themselves. Its guide calls updating to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 the only complete fix.

• Update PHP from your distribution or vendor. The package changelog should name both CVE ids, because distributions keep the old version number.
• Restart PHP-FPM, or Apache if you use mod_php.
• Rebuild and redeploy any container image that bundles PHP.
• If you cannot update today, Hostinger's interim step is to turn off session upload progress in php.ini or the PHP-FPM pool config and restart all workers. Hostinger says it will not work if set from code. It lowers risk and does not replace the update.

Am I affected?

Was anything exploited before the fix?

AWS reported exploit attempts against its honeypots from 17 October, four days before disclosure, and more on 21 October. It says it is unclear whether the early attempts would have worked on real systems, and its report names no victim. That makes no statement about any Hostinger customer. We found no primary source naming a compromised site at our 24 October 2026 check.

If your PHP was unpatched and reachable in that window, look for PHP files you did not upload, scheduled tasks you did not create, new admin accounts, and unexpected outbound connections. A patch does not remove anything planted earlier. See Is PHP2Shell being exploited? for the dated record.

What about CVE-2026-115560?

On 23 October the PHP project published an informational notice for a separate issue, CVE-2026-115560, with a full advisory due with the next release. It concerns session upload progress under specific session settings, and the notice recommends disabling that feature until the release. Hostinger's 23 October update says managed plans are covered by its 21 October mitigation. We will not describe the issue further until the advisory is out.

Where does this fit, and what next?

Other hosts differ in what they have published, and the other host guides cover the rest. See SiteGround and what Kinsta has published, the fixed versions table, and what a checker can and cannot confirm. The wider month is in why October 2026 is so heavy.