Free tool, passive check
Is your website exposed to the October 2026 PHP vulnerabilities?
On October 21, 2026 the PHP project shipped fixes for two critical bugs, CVE-2026-109618 and CVE-2026-109619, that let an unauthenticated request run code on the server. The fix is PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Enter your site and we read what it tells the world about its PHP version, then say plainly how exposed it looks and what to check next.
What the check can and cannot tell you
From outside, a website gives away a little about its stack: an X-Powered-By header, a Server header, a session cookie, links ending in .php, a WordPress theme path. If the version is advertised we compare it with the fixed release for that branch. If it is not, we say so, because guessing would be worse than useless.
What no outside check can see: whether your Linux distribution backported the fix under the old version number (Debian, Ubuntu and Red Hat do this), whether PHP runs as mod_php or PHP-FPM behind a proxy, and whether the interim settings from the PHP team are applied. Those answers live on the server, and the result tells you exactly where to look.
- Below the fix
- The site reports a version older than the fixed release. Treat it as exposed unless your vendor confirms a backport.
- Unsupported branch
- PHP 8.1 or older. No upstream fix exists; you need a vendor backport or an upgrade.
- Patched
- The reported version is at or above the fix. Confirm on the server, since a proxy can set that header.
- Hidden
- PHP is in play but the version is not advertised. Good hygiene, and the outside view ends here.
- No PHP found
- Nothing points at PHP on this page. Other hostnames and internal apps may still run it.
What the PHP project says to do
Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's patched package, then restart every worker. PHP 8.1 and older get no upstream release; the security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source.
If you cannot update today, these settings reduce exposure to the confirmed attack paths. They are a stopgap, not a fix, and the PHP team says so in the same breath.
- Set memory_limit to -1 in a place applications cannot override (php_admin_value in the FPM pool or Apache config), and make sure nothing sets a finite limit back.
- Set a low post_max_size: 8M for sites without uploads, 32M where uploads are needed, with upload_max_filesize below it. Enforce request size limits at the web server or proxy as well.
- Set session.upload_progress.enabled to 0 in php.ini or the pool config and restart every worker. ini_set() and .user.ini are too late in the request to count.
- On PHP 8.5, set fatal_error_backtraces to 0 and restart.
- Fix any fatal errors and execution timeouts an attacker can trigger, and remove invalid or deprecated per-request settings that emit warnings before the request is fully set up.
Source: PHP security advisory, October 21, 2026
Read our full write-up: who is exposed and what to do this week
Common questions
Does this tool test whether my site can actually be exploited?
No. It sends one ordinary page request and reads the headers, cookies and markup that come back. It never sends malformed input or tries the vulnerability. A real exploitability test needs authorisation and access to the server, which is work we do under engagement.
The result says patched, am I safe?
The version string says the fix is present. Confirm it on the server, because a cache or proxy can set the header. Then check every other PHP host you run: web mail, intranet apps, forums and vendor appliances are usually the ones nobody remembers.
The result says below the fix, but my host says they patched. Who is right?
Possibly both. Debian, Ubuntu and Red Hat backport security fixes without changing the version number, so a site can report 8.2.29 and still be fixed. Ask your host for the package changelog line that names CVE-2026-109618 and CVE-2026-109619. If they cannot show it, assume it is not patched.
Why do you ask for my details before showing the result?
Two reasons. We want to know who is checking so the tool is not used to scan sites people do not own, and we follow up with anyone whose result needs action. The check itself is free and the result is not stored.
What do you do with the URL I enter?
We fetch it once, compute the result, and return it to your browser. Nothing about the response is written to disk. The URL and your contact details go to our inbox so we can follow up.
Need it patched today, or want the rest of your estate checked?
HuCortex runs security for Canadian businesses. For this advisory we can inventory every PHP host you have, confirm patch status on the server, apply the interim settings where an update has to wait, and give you a one-page record for your insurer or client. Most engagements take a day.
Book a 20-minute patch review