Your PHP version is hidden — what to do next

Q: Does hiding my version protect me?

Only a little, and indirectly. Hiding removes a signal attackers use to pick targets, but it does not remove a single vulnerability: an unpatched site with a hidden version is still unpatched. Patching is the protection; hiding is hygiene on top of it.

Q: Why doesn't phpscan probe harder to find the version?

Because the harder probes are exploit probes — requests crafted to trigger a flaw, or to crash the server in a way that leaks information. We never send them. Crash-based detection also misfires: patched systems can crash for unrelated reasons, so it raises false alarms exactly where certainty matters most. The comparison page (phpatch.com/compare) shows how the approaches differ.

Q: How often should I re-check my version?

Whenever a new PHP advisory lands, and after every upgrade. The Atom advisory feed (/feeds/php-advisories.xml) is machine-readable, so a feed reader or a small script can watch it for you; if you run many sites, the JSON feed (/feeds/php-advisories.json) drops into the same monitoring you already use.

Q: I don't have server access. Can I still find my version?

Usually, yes. The hosting panel shows it on most shared hosting (the panel steps above), and if yours does not, asking your host is a routine support question. If you need certainty without doing it yourself, the ownership-verified version check settles it read-only: you prove the site is yours, we check, and you get the exact version plus the patch plan.

By PHP Patch Assurance · Last updated: 2026-10-30 · Plain-text version

A hidden PHP version means the site publishes no version in its headers, error pages or a phpinfo page, so no external scan can confirm its patch level. Hidden is neither vulnerable nor proven safe — it is unknown. If the site is yours, you can make it known in minutes, from the server side.

What version hidden means

Some sites disclose their PHP version in the X-Powered-By header, on an error page, or on a public phpinfo page. A well-run site publishes none of those: hiding the version is recommended practice, because a version string is a shopping list for attackers picking targets. The cost of that hygiene is real, though — with nothing disclosed, no external scanner, ours included, can confirm whether the site runs a patched release.

That is why the free scan reports VERSION HIDDEN instead of guessing. Hidden is not vulnerable, and it is not proven safe either; it is unknown. Every other scanner faces the same wall — the honest ones say so, and none of them can settle it from outside. We do not probe harder to force the version out: the comparison page shows why exploit-style probing misfires. If the site is yours, though, unknown is a fixable state — the rest of this guide is the fix.

Check your own version: three ways

Any one of these settles the question from the server side, in minutes:

Terminal. Over SSH, run php -v. One caveat: that reports the command-line PHP, and the web SAPI — mod_php, PHP-FPM or another — can run a different version. The version-check guide explains how to confirm the version the site actually serves.
Hosting panel. In cPanel, open MultiPHP Manager or Select PHP Version — it shows the PHP version assigned to each domain. In Plesk, open Websites & Domains, then PHP Settings for the site.
Temporary phpinfo. Create a file named check.php in the web root containing only <?php phpinfo();, visit it in a browser, and read the version at the top of the page. Then delete the file immediately. A leftover phpinfo page hands anyone your paths, modules and configuration — it is a serious exposure in its own right, and phpscan flags an exposed phpinfo page as a finding. Never leave it in place for later.

Once you know the version: check it against the advisories

Knowing the version only helps if you check it against what is currently known. The free scan gives a site its verdict; if you already know your exact version, compare it with the advisory feed instead: the machine-readable JSON feed lists every PHP advisory with the release that fixes it, and the Atom feed carries the latest entries for a feed reader — the practical way to watch many sites at once.

Three outcomes are possible. Supported and patched: your version is on a supported branch and at or above the fixed release — nothing to do until the next advisory. Vulnerable: a published advisory covers your version, and the feed names the fixed release to move to. End-of-life: your branch no longer receives fixes at all, so no fixed release exists — the answer is a branch upgrade, covered in the end-of-life guide.

If it is end-of-life or vulnerable

Act on the version, not on the visibility. Upgrade through your hosting panel or ask your host to move you to the fixed release — on shared hosting the version is the host's choice, so an end-of-life branch is a question to put to them directly. Or use the managed patch service: a snapshot is taken and restore-tested first, the patch is applied and verified live, and the change reverts automatically if verification fails.

Afterwards, keep the version hidden. Hiding was never the problem — it stays good practice. You simply check from the server side from now on: once after every upgrade, and whenever a new advisory lands.

Not your site? Then it stays unknown

A hidden version on someone else's site cannot be assessed from outside — by design. Do not treat it as a red flag, and do not treat it as reassurance: it carries no information about the site's patch level in either direction. Scanners, ours included, report it as unknown, and only the site's owner can settle it, from the server side, with the steps above.

Check your site free Patch service

This guide pairs with the free scan.

Frequently asked questions

Does hiding my version protect me?

Only a little, and indirectly. Hiding removes a signal attackers use to pick targets, but it does not remove a single vulnerability: an unpatched site with a hidden version is still unpatched. Patching is the protection; hiding is hygiene on top of it.

Why doesn't phpscan probe harder to find the version?

Because the harder probes are exploit probes — requests crafted to trigger a flaw, or to crash the server in a way that leaks information. We never send them. Crash-based detection also misfires: patched systems can crash for unrelated reasons, so it raises false alarms exactly where certainty matters most. The comparison page (phpatch.com/compare) shows how the approaches differ.

How often should I re-check my version?

Whenever a new PHP advisory lands, and after every upgrade. The Atom advisory feed (/feeds/php-advisories.xml) is machine-readable, so a feed reader or a small script can watch it for you; if you run many sites, the JSON feed (/feeds/php-advisories.json) drops into the same monitoring you already use.

I don't have server access. Can I still find my version?

Usually, yes. The hosting panel shows it on most shared hosting (the panel steps above), and if yours does not, asking your host is a routine support question. If you need certainty without doing it yourself, the ownership-verified version check settles it read-only: you prove the site is yours, we check, and you get the exact version plus the patch plan.

← Guides