Last checked: · Source review; separate from content updates.
Short answer: The local checker compares supplied text with recorded upstream and vendor thresholds. It does not establish that a website runs the matched build, test exploitability or rule out compromise.
Data sources and maintenance
Upstream thresholds come from PHP’s announcement; vendor backports need the linked vendor security advisory and exact release/source record. The source directory retains UTC check times. Content update dates, source review times and vendor publication dates are distinct. A routine recheck without changed evidence does not change a page’s content date.
Missing or unconfirmed vendor evidence remains “Status not confirmed — check vendor advisory”. A fix for one distribution, branch or package family is not evidence for another. See changes and corrections and maintenance details.
Comparison rules
- Parse PHP versions from the supplied text; infer a platform from recognizable package/path markers unless a platform is selected. That inference is not proof of the operating system.
- For a known vendor threshold, require the recorded platform, branch, distribution-release marker and upstream package base to match. Compare complete revisions with the local Debian-style ordering implementation. This is a text comparison, not package authentication; validate Debian/Ubuntu ordering with the vendor’s package tools. Debian version comparison reference.
- Otherwise compare a stable upstream version with the fix threshold in that same branch. Unknown vendor revisions, incomplete inputs and prereleases do not confirm a fix. An end-of-life upstream branch needs separate vendor evidence.
- Keep website verification separate for every outcome. A source selected as “website runtime” is user-provided context, not independent verification. A public header cannot establish the build, even when its number meets a threshold.
Evidence levels and result wording
- Below recorded fix / unsupported branch
- A version below a recorded threshold needs an update. An end-of-life upstream branch needs a verified vendor backport or migration; its age alone does not establish vendor patch status.
- Matches documented vendor fix
- The complete revision matches a recorded vendor threshold for that distribution release. The comparison supports that this package build contains the fix; it does not authenticate the installed package or verify the website uses it.
- Meets upstream fix threshold
- The supplied stable version meets its branch threshold. The corresponding upstream release contains the fix; custom build provenance and the running website remain unverified.
- Build fix not confirmed
- The input is missing, incomplete, a prerelease or outside the verified vendor data. Obtain the exact build and advisory before drawing a conclusion.
- Header hint — build not verified
- A public header is only a version hint, even at a fixed version number. Neither the installed build nor the website workers are verified by that header.
A matched advisory is an advisory comparison. A repository publication record, a downloaded artifact with a verified checksum and an installation test in a named environment are separate evidence. The checker does not promote a version match to artifact verification or installation testing. Any environment tests in platform records cover only their named scope and time.
Reproduce these checks locally
Use the local checker with these synthetic examples from the project’s test fixtures. They are not observations of a real website.
PHP 8.3.36 (cli): an upstream threshold match; website runtime remains unverified.PHP 8.3.35 (cli): below the upstream threshold. A different fixed CLI reading does not resolve an older web reading.php8.3-fpm 8.3.6-0ubuntu0.24.04.13: a vendor advisory comparison for Ubuntu 24.04. Enter only its short upstream portion and select Ubuntu: the backport remains unconfirmed. Recorded vendor source · checked at 2026-10-22 03:28:58 UTC.- Arbitrary text or no header: no version evidence. An unknown package revision needs its own vendor advisory.
The local repository contains the comparison code, data and executable regression cases. Public repository details pending; no public code-hosting URL has been confirmed.
What these tools cannot establish
The local tool does not inspect binary provenance, custom builds, extensions, configurations, every worker or historical activity. Headers can be absent or misleading. The optional online tool makes a limited HTTPS homepage HEAD request under its existing consent and verification controls; it is not a vulnerability test. Read the data policy and use website verification before closing an update task.
Common questions
What does a matching fixed-build result establish?
It establishes a comparison between the supplied text and a recorded fix threshold. It does not authenticate the build, prove the website uses it, inspect every worker or rule out a past compromise.
Sources: PHP security announcement and release archive · PHP manual: server API / SAPI
Does an old-looking PHP version mean the fix is missing?
Not necessarily. A distribution may backport the fix without changing the upstream number. Match the complete package revision, operating system release and package source to the vendor advisory. A short version alone cannot establish a backport.
Does a missing PHP response header mean the website is patched?
No. A missing header provides no PHP version evidence. A visible header is only a hint and cannot establish the installed package or the state of every web worker.
Are all listed builds installation-tested?
No. Advisory confirmation, publication, artifact verification and installation testing are different evidence levels. Only a record explicitly naming a tested environment supports an installation-test claim. Source check times alone do not establish testing.
Site policy: About this guide.