Kurz gesagt: Um im Changelog eine CVE zu prüfen, durchsuchen Sie das Änderungsprotokoll des installierten PHP-Pakets nach CVE-2026-109618 und CVE-2026-109619: unter Debian und Ubuntu in /usr/share/doc/<paket>/changelog.Debian.gz, auf RPM-Systemen mit rpm -q --changelog. Ein Treffer zusammen mit Paketstand, Abgleich zur offiziellen Sicherheitsmeldung und Neustartzeit ergibt einen belastbaren Nachweis. Ein fehlender Treffer ist noch kein Beweis für eine offene Lücke.
Warum ein Nachweis mehr ist als „wir haben gepatcht“
Nach PHP2Shell wollen viele wissen, ob ihre Server sicher sind: die Geschäftsführung, der Datenschutzbeauftragte, Kunden mit Auftragsverarbeitung, manchmal der Cyberversicherer. „Wir haben gepatcht“ ist dafür zu wenig. Gefragt ist ein Beleg, den ein Dritter nachvollziehen kann.
Die Versionsnummer taugt dafür oft nicht, weil Distributionen Korrekturen als Backport einspielen und die Nummer gleich bleibt. Der Paket-Changelog ist die bessere Grundlage. Er wird vom Paketbetreuer geschrieben und listet bei Sicherheitsupdates in der Regel die behobenen CVE-Nummern auf.
Wo die Changelogs liegen
Jedes Paketformat hat seinen eigenen Ort. Die folgende Übersicht hilft, schnell an die richtige Stelle zu kommen.
| System | Ort des Changelogs | Befehl zum Durchsuchen |
|---|---|---|
| Debian, Ubuntu | /usr/share/doc/<paket>/changelog.Debian.gz |
zgrep |
| Debian, Ubuntu (online) | Paketarchiv der Distribution | apt changelog <paket> |
| RHEL, AlmaLinux, Rocky, Fedora | RPM-Paketdatenbank | rpm -q --changelog <paket> |
| Container-Images | im Image, wie beim Basissystem | Befehl im Container ausführen |
Unter Debian und Ubuntu verweist das Dokumentationsverzeichnis mancher Binärpakete per symbolischem Link auf ein gemeinsames Paket, etwa php8.3-common. Findet zgrep die Datei nicht, sehen Sie sich das Verzeichnis mit ls -l /usr/share/doc/ | grep php an.
Changelog CVE prüfen: so gehen Sie vor
Die folgenden Befehle sind rein lesend. Passen Sie die Paketnamen an Ihre Installation an.
# Debian/Ubuntu: lokal, ohne Netz
zgrep -n -E "CVE-2026-10961[89]|CVE-2026-115560" /usr/share/doc/php8.3-common/changelog.Debian.gz
# Debian/Ubuntu: Kopfzeile des neuesten Eintrags mit Paketstand und Datum
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20
# RHEL-Familie: Eintrag samt Datum und Paketstand
rpm -q --changelog php-common | grep -n -B3 -E "CVE-2026-10961[89]"
Bei Debian und Ubuntu steht der Paketstand in der Kopfzeile jedes Eintrags, das Datum in der Schlusszeile. Bei RPM steht beides in der Zeile über den Einträgen. So sehen Sie nicht nur, ob die CVE erwähnt ist, sondern auch, mit welchem Paketstand. Vergleichen Sie diesen Stand mit dem installierten, etwa über dpkg-query -W oder rpm -q. Stimmen beide überein, ist die Korrektur im laufenden Paket enthalten.
Panel-Pakete und Container
Hosting-Panels bringen eigene PHP-Pakete mit, etwa Plesk oder cPanel. Auch diese sind gewöhnliche DEB- oder RPM-Pakete, ihr Changelog lässt sich mit denselben Werkzeugen lesen. Ob die Anbieter darin CVE-Nummern nennen oder nur die neue PHP-Version, ist unterschiedlich. Nennt das Paket die Upstream-Version 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, genügt das als Beleg; bei Backports mit alter Nummer brauchen Sie die Auskunft des Anbieters.
Bei Containern gehört der Nachweis zum Image, nicht zum Host. Prüfen Sie die Pakete im Image, aus dem der laufende Container gestartet wurde, und halten Sie zusätzlich den Image-Digest fest. So ist später nachvollziehbar, welcher Stand tatsächlich lief, auch wenn das Image unter demselben Tag inzwischen neu gebaut wurde.
Wenn die CVE im Changelog fehlt
Ein fehlender Eintrag hat mehrere mögliche Ursachen. Gehen Sie sie in dieser Reihenfolge durch:
- Falsches Paket durchsucht: Bei mehreren PHP-Zweigen oder Quellen auf einem Server liegt die Antwort oft im Changelog eines anderen Pakets.
- Upstream-Version statt CVE: Liefert die Quelle die neue Upstream-Version aus, etwa 8.4.27, steht im Changelog unter Umständen nur „New upstream version“. Dann ist die Versionsnummer selbst der Beleg, weil php.net die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 als korrigiert nennt.
- Andere Formulierung: Manche Betreuer nennen Bugnummern oder Advisory-Kennungen wie GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp statt der CVE.
- Abgleich mit der Sicherheitsmeldung: Nennt die offizielle Meldung Ihrer Distribution, etwa ein USN oder der Debian Security Tracker, einen korrigierten Paketstand, und ist dieser oder ein neuerer installiert, ist das ebenfalls ein Beleg. Für Debian und Ubuntu finden Sie die Stände im Beitrag Ist mein PHP-Paket gepatcht?, für die RHEL-Familie unter RHEL, AlmaLinux und Rocky Linux.
- Anbieter fragen: Bei Panel-Paketen, Hoster-Builds oder Drittquellen hilft nur die schriftliche Auskunft. Eine Vorlage bietet der Ratgeber Hoster nach dem Patch-Status fragen.
Bleibt nach diesen Schritten kein Beleg, behandeln Sie den Server als ungepatcht und setzen Übergangsmaßnahmen, bis die Frage geklärt ist.
Vom Treffer zum Nachweis
Ein Treffer im Changelog belegt, dass das Paket die Korrektur enthält. Er belegt nicht, dass die laufenden Prozesse sie nutzen. Ein vollständiger Nachweis enthält deshalb fünf Angaben je Server und PHP-Installation:
- Server, PHP-Zweig und Betriebsart, etwa PHP-FPM oder mod_php
- installierter Paketstand und Paketquelle
- Fundstelle im Changelog oder Verweis auf die offizielle Sicherheitsmeldung
- Zeitpunkt des Updates und Startzeit der laufenden PHP-Prozesse
- Name der prüfenden Person und Datum der Prüfung
Speichern Sie die Rohausgaben der Befehle als Textdatei neben dem Nachweis. Sie sind später leichter nachzuvollziehen als eine Zusammenfassung aus dem Gedächtnis.
Ein Nachweis beantwortet nur die Frage, ob die Lücke ab einem Zeitpunkt geschlossen war. Für die Zeit davor brauchen Sie die Logs ab dem 20. Oktober 2026 und gegebenenfalls eine Spurensuche. Den allgemeinen Ablauf der Versionsprüfung beschreibt die Seite PHP-Version und Patchstand richtig prüfen.
Wie hilft PHP SOS konkret?
- Wir durchsuchen die Changelogs aller PHP-Pakete Ihrer Server und gleichen sie mit den offiziellen Sicherheitsmeldungen ab.
- Wo Changelogs schweigen, klären wir den Stand mit Distribution, Panel-Anbieter oder Hoster.
- Wir kontrollieren, dass die laufenden Prozesse nach dem Update neu gestartet wurden.
- Mit dem PHP-Patch-Service erhalten Sie den Nachweis je Server in einer Form, die Sie an Dritte weitergeben können.
Häufige Fragen
Warum reicht die PHP-Version als Nachweis nicht?
Viele Distributionen übernehmen Sicherheitskorrekturen als Backport, ohne die PHP-Version zu ändern. Die Versionsnummer sagt dann nichts über den Patch. Der Changelog des installierten Pakets nennt dagegen die behobenen CVE-Nummern.
Was bedeutet es, wenn die CVE im Changelog fehlt?
Es kann heißen, dass die Korrektur fehlt. Es kann aber auch sein, dass der Paketbetreuer anders formuliert, etwa mit Bugnummer oder Upstream-Version. Dann gleichen Sie den Paketstand mit der offiziellen Sicherheitsmeldung ab oder fragen den Anbieter.
Wie lange sollte ich den Nachweis aufbewahren?
Solange er für interne Prüfungen, Versicherer oder mögliche Datenschutzfragen relevant sein kann. Legen Sie ihn zusammen mit den Logs ab dem 20. Oktober 2026 ab. Konkrete Fristen klären Sie mit Datenschutzbeauftragten oder Rechtsberatung.
Kann ich den Changelog auch ohne Internetzugang prüfen?
Ja. Debian und Ubuntu legen das Changelog jedes Pakets lokal unter /usr/share/doc ab, RPM-Systeme speichern es in der Paketdatenbank. Beides lässt sich ohne Netz lesen.