Check a PHP package: read the changelog

To check a PHP package, compare the installed package version with its record of changes and confirmation from the administrator of your website.

Your host says PHPPHP is a programming language that builds your web pages on the computer that hosts your site, just before they reach the visitor. WordPress runs on it. has been updated, but the number you see looks unchanged. Ask for the full package details and the matching changelog. This is the record of changes to discuss with the administrator.

Note which website you are checking and when the answer was provided. That keeps the conclusion tied to a specific installation.

Start with the hosting guides if you do not know where to find the PHP versionA PHP version is a numbered edition of PHP, like 8.3. Each edition is looked after for a limited time, then gets security fixes only, then nothing.. Then ask the administrator to identify the exact package. You do not need to become a server administrator to request a useful answer.

Break the request into small questions that someone can verify.

Request the complete package version

Ask for the package name, full version, distribution and package source. Copy any suffix exactly as supplied. A distribution revision identifies the package edition alongside the original PHP version.

A changed suffix alone does not prove a CVEA CVE is a public ID number for one known security weakness in software, such as CVE-2026-109618, so everyone talks about the same problem. fix. Do not shorten the answer by removing that part. You want to identify the package covered by the documentation you are about to read.

Also ask whether those details refer to the PHP installation used by your website. Have the administrator name the domainA domain name is the address people type to reach your website, such as yourcompany.com. It points visitors to wherever your site is hosted. in their answer. A list of versions present somewhere on a server is not specific enough.

You need confirmation for this site, after the latest change, with a clearly identified package.

Read about a backportA backport takes a fix made for a newer version of software and applies it to an older version, so the old one gets the fix without a full upgrade. to understand the distinction between an older base and a fix applied to it. Our facts source says some distributions and LTS vendors provide backported fixes. That gives you a reason to ask for evidence.

It does not confirm that any particular provider or package contains the fix.

Have the matching changelog opened

For an apt package, have the administrator use apt-get changelog PACKAGENAME. Replace PACKAGENAME with the installed package serving your site. By default this requests the changelog for the installed version and tries to download it.

If no result is available, request the matching record from the package supplier.

For an rpm package, have the administrator use rpm -q --changelog PACKAGENAME. Again, PACKAGENAME means the actual installed package. This queries package information; it does not install an update.

Save the relevant entry with the complete package version.

Both commands only read information. They do not install packages or add repositories. If you have no access to the system, ask your host to perform this check.

Have the administrator confirm that the entries apply to the package serving your domain. Keep that confirmation with the record.

Find the specific fix under discussion

Open the security status to identify the recorded vulnerabilities. Ask the administrator to connect the relevant CVE references to the package. A security patchA security patch is a software update that closes one known security weakness and adds nothing else, so installing it protects you against that problem. needs a concrete description for this review: which issue, which package edition and which installation were checked?

Request an answer for each part.

Check the date of the review too. Confirmation from before the repair does not answer the current question. Ask the administrator to describe what they have established now.

Avoid a conclusion based only on words such as updated or supported. Request the document that supports those words for this exact package.

What if the CVE references are missing?

Treat a missing reference as an open question. Ask the supplier where it documents the connection between the repair and the package edition. Your administrator can review that evidence alongside the installed version.

Do not make a firm conclusion from an empty search result. Record the missing evidence and who will provide it.

You can ask: which publication confirms that this package includes the repair? Then ask: can you confirm that my domain uses this package? If the answer stays general, return it with the missing details identified.

Agree when you will receive a specific answer. Keep the review open until that evidence has been assessed.

Record the outcome and choose a next step

Keep one short record with the domain, package details, source, check date and administrator. Separate what has been demonstrated from what remains unknown. Share the record with the person making maintenance decisions.

This keeps the next discussion tied to the same installation and the same question, rather than starting again with a short version number.

Read how to backpatch PHPTo backpatch PHP is to apply a security fix to an older PHP version without moving the whole installation to a newer version. to compare the routes. Also check supported PHP versions when planning an upgrade. Discuss that move with your administrator.

A package review and a future upgrade plan can run alongside each other. One does not establish the result of the other.

Not sure which route fits?

Start with the PHP Exposure Check. Then use the help form with your domain, package version and your host’s answer. State which confirmation is still missing.

Leave out passwords and other access details so the first review can focus on the evidence needed to make the decision.