PHP Site Audit

Linux distributions

How can Ubuntu and Debian owners verify a PHP security backport?

The direct answer

Ubuntu and Debian maintain release-specific package security information, and a distribution may carry a security fix without matching the latest upstream PHP version string. Look up the relevant CVE and PHP source/binary package in the distribution’s own tracker or notice for the installed release, then compare the installed package revision and repository origin. If the status is pending, undetermined, or outside support coverage, treat it as unresolved and ask the administrator or vendor.

Identify release and package origin

Before interpreting a scanner result, collect the operating-system release, support status, architecture, package name, installed package revision and source repository. A server can contain distro PHP packages, a third-party repository build, a container image, or a provider-managed runtime. The package’s visible PHP upstream component may remain on an older branch while the distribution adds a security patch, so compare like with like: same vendor, release, package stream and revision.

Understand distribution backports

Ubuntu documents that fixed-release distributions deliver many security updates as backported patches. It publishes Ubuntu Security Notices for fixes and tracks vulnerability state by package and release. Debian’s Security Tracker distinguishes stable, oldstable, testing, and backports, and includes statuses such as packages still needing checks. These are not interchangeable verdicts: a state for one suite or package does not establish status for another.

Check the exact CVE and package status

Search the Ubuntu CVE tracker or relevant USN for the CVE and exact Ubuntu release, and inspect the PHP package status and advisory reference. For Debian, search the Security Tracker for the CVE or package and check the exact release suite. Confirm whether the tracker says fixed, vulnerable, not affected, or undetermined, and note whether the package came from the expected security archive. If the installed revision predates the vendor’s fixed revision, or the suite is not covered, the finding needs follow-up.

Escalate packages outside distro coverage

For a third-party repository or a container base image, the Ubuntu or Debian record may not describe the package actually running. Identify who built that artifact and ask for their own advisory or source-package reference. Do not claim that every Ubuntu, Debian, derivative, or PHP build is fixed because one distribution has published a package update. Avoid copying a patched package number from an unrelated release into a general guide.

Close with a host-by-host evidence record

A tracker entry describes vendor knowledge; it does not prove the production host installed the update. Compare the live package inventory with the release-specific fixed revision, confirm the origin of the package, and record when the PHP request handler and any long-running jobs were restarted or replaced. If the service runs in a container, connect the package evidence to the image digest actually deployed rather than only the host operating system.

Close with a small evidence table in the change ticket: hostname or workload, OS release, package stream, installed revision, advisory/CVE record, process restart time, and application smoke checks. Mark each row fixed, unresolved, or unknown. A public scan may identify a clue in response behavior; it cannot inspect the OS package database or verify the contents of a backported binary.

Support lifecycle is part of this decision. Confirm that the operating-system release and repository remain under the relevant security maintenance program, including any subscription or extended-maintenance requirement. A package status for a supported release should not be reused for an end-of-life release, a derivative, or a manually pinned package without separate evidence.

Common questions

Does an older PHP version string mean the distro package is vulnerable?

Not by itself. Check the exact distribution release and package revision against its CVE record or security notice.

Does a fixed tracker status prove production is patched?

No. It describes the vendor package status; confirm the installed package and serving process on each production host or image.

What if the tracker says undetermined?

Keep the result unresolved and ask the distribution, derivative vendor, or image maintainer for package-specific guidance.

Sources and further reading

Related guides