How to Check Whether a PHP Security Patch Is Installed

The core problem: version numbers can mislead

There are two ways PHP reaches a server, and they need different verification methods.

Source	Example version string	How fixes arrive
Upstream builds (php.net source, official Docker images, many hosting panels)	`8.3.36`	New upstream patch release
Distribution packages (Debian, Ubuntu, RHEL and derivatives)	`8.1.2-1ubuntu2.x`	Fix backported into the existing version, package revision increases

With upstream builds, the version number is a reliable signal. With distribution packages, the upstream portion of the version (8.1.2 above) can stay the same for years while security fixes are applied underneath. This practice is called backporting: the distribution takes the fix from a newer release and applies it to the older code base it ships, so that it can deliver security updates without introducing other changes.

Both mistakes are common: assuming an old-looking package is vulnerable when it has been patched, and assuming a package is patched because the system was “updated recently” when the fix was never published for that release.

Step 1: Identify where your PHP comes from

php -v

Look at the version string. An upstream build shows a plain version such as PHP 8.4.27. A distribution package often includes extra text after the version, for example PHP 8.1.2-1ubuntu2.x (cli), though not always.

Then ask the package manager:

# Debian / Ubuntu
dpkg -l | grep -E '^ii\s+php'

# RHEL, AlmaLinux, Rocky, Fedora
rpm -qa | grep -i '^php'

If the package manager lists your PHP packages, they come from a repository. Note the repository too: a package from a third-party repository (a PPA, Remi, or a hosting vendor’s repository) follows that maintainer’s policy, not the distribution’s security team.

apt-cache policy php8.3-fpm     # Debian / Ubuntu
dnf info php                     # RHEL family

Remember that the CLI and the web server can run different PHP builds. Check the binary that actually serves your site, as described in how to check your PHP version.

Step 2: Find out which release fixes the issue

Start from the advisory or CVE you care about. Note:

The CVE ID.
The upstream fixed versions per branch.

For example, CVE-2024-4577, a PHP-CGI argument injection issue on Windows with certain code pages, was fixed upstream in 8.1.29, 8.2.20 and 8.3.8. More recently, CVE-2026-109618 and CVE-2026-109619 were fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 2026-10-21.

The CVE checker and the vulnerability list show the affected ranges and fixed versions for published PHP CVEs.

Step 3a: Verify an upstream build

For upstream builds, compare your version with the fixed version in the same branch.

Your version	Fixed in branch	Patched?
8.3.36	8.3.36	Yes
8.3.35	8.3.36	No
8.4.27	8.4.27	Yes
8.1.34	No fix (branch EOL)	No

You can automate the comparison with PHP itself:

php -r 'var_dump(version_compare(PHP_VERSION, "8.3.36", ">="));'

This only makes sense within the same branch. Being on 8.4.0 does not mean you have a fix that shipped in 8.3.36; check the fixed version for 8.4.

After an upgrade, restart PHP-FPM or the web server. The new binary is on disk, but long-running processes keep using the old one until restarted.

sudo systemctl restart php8.3-fpm

Step 3b: Verify a distribution package

For packaged PHP, check whether the distribution says it fixed the specific CVE.

Debian and Ubuntu: the package changelog

Security fixes are usually recorded in the changelog with the CVE ID.

# Changelog of the installed package
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -i 'CVE-2024-4577'

# Changelog of the candidate version from the repository
apt changelog php8.3-common | grep -i 'CVE-'

Replace the package name with yours. If the changelog for your installed version mentions the CVE as fixed, the patch is present in that package.

RHEL and derivatives: rpm changelog

rpm -q --changelog php-common | grep -i 'CVE-2024-4577'

On RHEL-family systems you can also query update advisories:

dnf updateinfo list --cve CVE-2024-4577

Vendor CVE trackers

The trackers show the status of a CVE for each release and package, including “not affected”, “needed”, “deferred” or “fixed” with a version number.

Search for the CVE ID, find your release (for example Ubuntu 22.04 or Debian 12), and compare the fixed package version with what dpkg -l or rpm -q reports. If your installed version is equal to or newer than the fixed package version, you have the fix.

Some vendors mark a CVE as “not affected” because the vulnerable code is not built or not reachable in their configuration. CVE-2024-4577 is an example of a context-dependent issue: it concerned PHP-CGI on Windows, so Linux packages were generally not exposed in the same way. Read the vendor’s notes rather than relying on the label alone.

When the tracker shows no fix

If the vendor has not published a fix for your release, you are not patched, whatever the date of your last update. This happens for EOL distribution releases, for packages in community repositories without security coverage, and for vulnerabilities still being processed. Your options are to wait for a fix with mitigations in place, switch to a supported repository, or upgrade to a newer PHP branch.

Step 4: Confirm the running process

Installing a package does not change processes that are already running.

# When did the FPM master process start?
ps -o pid,lstart,cmd -C php-fpm8.3

# Has the package been updated since then?
ls -l --time-style=long-iso /usr/sbin/php-fpm8.3

If the binary is newer than the process, restart the service. On Debian and Ubuntu, needrestart can list services still using outdated libraries.

Shared hosting

On shared hosting you usually cannot run these commands. Use the panel’s PHP version selector or a short-lived phpinfo() page to read the version, then delete the page. If the host builds PHP from upstream, compare the version as in Step 3a. If you are unsure, ask the host directly: “Is CVE-2026-109618 fixed on the PHP 8.3 build serving my account?” A specific question tends to get a specific answer.

How this relates to PatchScope

The PHP version checker compares the version you enter against upstream affected ranges. For upstream builds, that answer is direct. For distribution packages, a “vulnerable” result means “the upstream version in this package string is in the affected range”; use the steps above to confirm whether your vendor has backported the fix. The methodology page explains this limitation in more detail.