In short: To check a CVE in the changelog, search the change log of the installed PHP package for CVE-2026-109618 and CVE-2026-109619: on Debian and Ubuntu in /usr/share/doc/<package>/changelog.Debian.gz, on RPM systems with rpm -q --changelog. A hit, together with the package status, a comparison with the official security announcement and the restart time, makes solid proof. A missing hit is not yet evidence of an open vulnerability.
Why proof is more than "we have patched"
After PHP2Shell, many people want to know whether their servers are safe: management, the data protection officer, customers with data processing agreements, sometimes the cyber insurer. "We have patched" is too little for that. What is needed is evidence that a third party can verify.
The version number is often unsuitable for this, because distributions apply fixes as backports and the number stays the same. The package changelog is the better basis. It is written by the package maintainer and, for security updates, usually lists the CVE numbers that were fixed.
Where the changelogs are
Every package format has its own location. The overview below helps you get to the right place quickly.
| System | Changelog location | Command to search it |
|---|---|---|
| Debian, Ubuntu | /usr/share/doc/<package>/changelog.Debian.gz |
zgrep |
| Debian, Ubuntu (online) | Package archive of the distribution | apt changelog <package> |
| RHEL, AlmaLinux, Rocky, Fedora | RPM package database | rpm -q --changelog <package> |
| Container images | Inside the image, as with the base system | Run the command in the container |
On Debian and Ubuntu, the documentation directory of some binary packages points by symbolic link to a shared package, for example php8.3-common. If zgrep does not find the file, look at the directory with ls -l /usr/share/doc/ | grep php.
Checking a CVE in the changelog: how to proceed
The following commands are read-only. Adjust the package names to your installation.
# Debian/Ubuntu: local, no network needed
zgrep -n -E "CVE-2026-10961[89]|CVE-2026-115560" /usr/share/doc/php8.3-common/changelog.Debian.gz
# Debian/Ubuntu: header line of the newest entry with package status and date
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20
# RHEL family: entry including date and package status
rpm -q --changelog php-common | grep -n -B3 -E "CVE-2026-10961[89]"
On Debian and Ubuntu, the package status is in the header line of each entry and the date in the closing line. With RPM, both are in the line above the entries. This shows you not only whether the CVE is mentioned, but also with which package status. Compare that status with the installed one, for example via dpkg-query -W or rpm -q. If the two match, the fix is contained in the running package.
Panel packages and containers
Hosting panels bring their own PHP packages, such as Plesk or cPanel. These too are ordinary DEB or RPM packages, and their changelog can be read with the same tools. Whether the vendors name CVE numbers in them or only the new PHP version differs. If the package names the upstream version 8.5.12, 8.4.27, 8.3.36 or 8.2.35, that is sufficient as proof; for backports with an old number you need a statement from the vendor.
With containers, the proof belongs to the image, not to the host. Check the packages in the image from which the running container was started, and also record the image digest. That way it can be traced later which version was actually running, even if the image under the same tag has since been rebuilt.
When the CVE is missing from the changelog
A missing entry has several possible causes. Work through them in this order:
- Wrong package searched: With several PHP branches or sources on one server, the answer is often in the changelog of a different package.
- Upstream version instead of CVE: If the source ships the new upstream version, for example 8.4.27, the changelog may say only "New upstream version". The version number itself is then the proof, because php.net lists the versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as fixed.
- Different wording: Some maintainers cite bug numbers or advisory identifiers such as GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp instead of the CVE.
- Comparison with the security announcement: If the official announcement of your distribution, such as a USN or the Debian Security Tracker, names a fixed package status, and that status or a newer one is installed, that is proof as well. For Debian and Ubuntu you will find the statuses in the article Is my PHP package patched?, and for the RHEL family under RHEL, AlmaLinux and Rocky Linux.
- Ask the provider: For panel packages, hoster builds or third-party sources, only a written statement helps. A template is provided by the guide Asking your hoster for the patch status.
If no evidence remains after these steps, treat the server as unpatched and apply interim measures until the question is settled.
From hit to proof
A hit in the changelog proves that the package contains the fix. It does not prove that the running processes use it. A complete proof therefore contains five details per server and PHP installation:
- Server, PHP branch and operating mode, for example PHP-FPM or mod_php
- Installed package status and package source
- Location in the changelog or reference to the official security announcement
- Time of the update and start time of the running PHP processes
- Name of the person who checked and date of the check
Save the raw output of the commands as a text file next to the proof. It is easier to follow later than a summary written from memory.
A proof only answers the question of whether the vulnerability was closed from a certain point in time. For the period before that, you need the logs from 20 October 2026 and, if necessary, a search for traces. The general procedure for checking versions is described on the page Checking the PHP version and patch status correctly.
How does PHP SOS help?
- We search the changelogs of all PHP packages on your servers and compare them with the official security announcements.
- Where changelogs are silent, we clarify the status with the distribution, panel vendor or hoster.
- We check that the running processes were restarted after the update.
- With the PHP patch service you receive the proof per server in a form you can pass on to third parties.
Frequently asked questions
Why is the PHP version not enough as proof?
Many distributions apply security fixes as backports without changing the PHP version. The version number then says nothing about the patch. The changelog of the installed package, by contrast, names the CVE numbers that were fixed.
What does it mean if the CVE is missing from the changelog?
It can mean that the fix is missing. It can also mean that the package maintainer worded it differently, for example with a bug number or an upstream version. In that case, compare the package status with the official security announcement or ask the provider.
How long should I keep the proof?
As long as it may matter for internal audits, insurers or possible data protection questions. File it together with the logs from 20 October 2026 onward. Clarify concrete retention periods with your data protection officer or legal counsel.
Can I check the changelog without internet access?
Yes. Debian and Ubuntu store the changelog of every package locally under /usr/share/doc, and RPM systems keep it in the package database. Both can be read offline.