PHP Version Check
Find the PHP version a site exposes and compare it with the official fixes for CVE-2026-109618 and CVE-2026-109619. Every verdict comes with its raw evidence — and unknown is a valid answer.
Fixed versions for CVE-2026-109618 and CVE-2026-109619
Two unauthenticated remote code execution flaws, rated CVSS v4.0 9.2 and patched on 2026-10-21. Any release below the fixed version of its branch is affected upstream.
| Branch | Affected | Fixed in | Status |
|---|---|---|---|
| 8.5 | 8.5.0 – 8.5.11 | 8.5.12 | Supported |
| 8.4 | 8.4.0 – 8.4.26 | 8.4.27 | Supported |
| 8.3 | 8.3.0 – 8.3.35 | 8.3.36 | Supported |
| 8.2 | 8.2.0 – 8.2.34 | 8.2.35 | EOL 2026-12-31 |
| ≤ 8.1 | 5.4.0 – 8.1.x | — | No upstream fix |
Source: php.net
If you cannot upgrade right now
These measures reduce exposure to specific attack paths but do not make an installation safe. php.net is explicit: updating is the only complete solution.
- Set memory_limit=-1, preferably through php_admin_value in the FPM pool or Apache config so applications cannot override it.
- Keep post_max_size low (8M without uploads, 32M with uploads) and upload_max_filesize below it. Enforce request size limits at the proxy as well.
- Set session.upload_progress.enabled=0 in php.ini or the pool config, then restart every worker. ini_set() and .user.ini are applied too late to help.
- On PHP 8.5 also set fatal_error_backtraces=0 and restart all workers.
- Use a container or cgroup memory limit as an availability boundary. Do not use RLIMIT_AS or RLIMIT_DATA.
Frequently asked questions
It looks for PHP version fingerprints a website exposes publicly, mainly the X-Powered-By response header, and compares the result with the official fixed releases for CVE-2026-109618 and CVE-2026-109619. It never sends exploit payloads and never verifies a vulnerability.
First passively: one GET request, and only the response headers are read. If you opt in to deep probing, up to six additional GET requests go to fixed paths such as /info.php and /phpinfo.php to look for a public phpinfo page. No POST requests, no request bodies, no path brute forcing.
Most production sites set expose_php=Off, put a CDN in front, or are not running PHP at all. Without a version number no comparison is possible, so the tool reports unknown instead of guessing. The signals it tried are listed with the result.
No. It means the version number the site reports is at or above the official fix. Headers can be spoofed, a proxy can rewrite them, and one domain may host several PHP versions behind different pools. Treat the verdict as evidence about a version number, not as a vulnerability scan.
Distribution packages keep the upstream version number and add a package revision, for example 8.3.6-0ubuntu0.24.04.13 on Ubuntu 24.04, which already contains the fix. Public headers only show 8.3.6, so the number alone proves nothing either way. Check the installed package build with your package manager.
8.5.12, 8.4.27, 8.3.36 or 8.2.35, whichever matches the branch you run. PHP 8.1 and older no longer receive releases from the PHP project; the project published minimal source backports for 7.4, 8.0 and 8.1, and some distributions and LTS vendors ship their own fixes.
Up to six GET requests from a fixed list of paths (plus the PHP credits endpoint when the budget allows), at most three at a time and three seconds each, reading at most 64 KB per page. It is off by default and should only be used on a site you own or are authorised to test.
Only a short-lived server-side cache keyed by hostname, so repeated checks do not hammer the target. Results are never published, never indexed and never given a shareable URL.