Kurz gesagt: Ob Ihr PHP-Paket unter Debian oder Ubuntu gegen PHP2Shell gepatcht ist, erkennen Sie am exakten Paketstand, nicht an der PHP-Version. Ubuntu hat am 21. Oktober 2026 korrigierte Pakete für alle unterstützten Releases veröffentlicht, ältere über Ubuntu Pro. Debian hat php8.2 in bookworm und php8.4 in trixie korrigiert. Vergleichen Sie den installierten Stand mit dpkg --compare-versions und starten Sie danach alle PHP-Dienste neu.
Die Frage hinter der Frage
„Ist mein PHP-Paket gepatcht?“ klingt nach einer Ja-oder-Nein-Frage. In der Praxis hängt die Antwort von drei Dingen ab: Aus welcher Quelle stammt das Paket, welcher Stand ist installiert und läuft dieser Stand auch? Dieser Beitrag beantwortet die ersten beiden Punkte für die offiziellen Pakete von Debian und Ubuntu. Wie Sie Version und laufende Prozesse allgemein prüfen, steht unter PHP-Version und Patchstand richtig prüfen.
Wir haben die Angaben in den offiziellen Sicherheitsmeldungen von Ubuntu und im Debian Security Tracker am 25. Oktober 2026 abgerufen. Beide CVEs, CVE-2026-109618 und CVE-2026-109619, sind dort mit denselben korrigierten Ständen aufgeführt.
Korrigierte Paketstände bei Ubuntu
Ubuntu hat die Korrekturen mit zwei Meldungen veröffentlicht. USN-8948-1 deckt die aktuellen Releases ab, USN-8948-2 die älteren, die nur noch über Ubuntu Pro Sicherheitsupdates erhalten. Bei 16.04 und 14.04 nennt Ubuntu zusätzlich das Legacy-Support-Angebot.
| Ubuntu-Release | Quellpaket | Korrigierter Stand |
|---|---|---|
| 26.10 | php8.5 | 8.5.9-0ubuntu2.1 |
| 26.04 LTS | php8.5 | 8.5.4-0ubuntu1.5 |
| 24.04 LTS | php8.3 | 8.3.6-0ubuntu0.24.04.13 |
| 22.04 LTS | php8.1 | 8.1.2-1ubuntu2.28 |
| 20.04 LTS (Ubuntu Pro) | php7.4 | 7.4.3-4ubuntu2.29+esm5 |
| 18.04 LTS (Ubuntu Pro) | php7.2 | 7.2.24-0ubuntu0.18.04.17+esm14 |
Auffällig ist, dass alle Stände die ursprüngliche PHP-Version behalten. Ubuntu 24.04 bleibt bei 8.3.6, obwohl die Korrektur aus 8.3.36 übernommen wurde. Warum das so ist und wie Sie damit umgehen, erklärt der Beitrag Warum php -v dieselbe Nummer zeigt. Betroffen sind jeweils unter anderem die Binärpakete für FPM, CLI, CGI und das Apache-Modul, etwa php8.3-fpm und libapache2-mod-php8.3.
Korrigierte Paketstände bei Debian
Debian geht hier einen anderen Weg und liefert die neuen Upstream-Versionen aus. Laut Security Tracker sieht der Stand so aus:
| Debian-Release | Quellpaket | Vorheriger Stand | Korrigierter Stand | Meldung |
|---|---|---|---|---|
| 12 bookworm | php8.2 | 8.2.32-1~deb12u1 | 8.2.35-1~deb12u1 | DLA-4848-1 |
| 13 trixie | php8.4 | 8.4.24-1~deb13u1 | 8.4.27-1~deb13u1 | DSA-6574-1 |
| forky, sid | php8.4 | 8.4.27-1 |
Die Meldung für bookworm erschien als DLA, also über Debian LTS. Für php8.2 in unstable führt der Tracker beim Abruf noch keinen korrigierten Stand. Wer Testsysteme auf unstable betreibt, sollte das im Blick behalten.
Ältere Debian-Releases tauchen in den beiden CVE-Einträgen beim Abruf nicht auf. Läuft ein Server noch auf einem solchen Release, etwa Debian 11 mit PHP 7.4, können Sie sich nicht auf ein Sicherheitsupdate aus dem offiziellen Archiv verlassen. Dann bleiben drei Wege: das Betriebssystem auf ein unterstütztes Release heben, ein kommerzielles Langzeitangebot nutzen, dessen Abdeckung für PHP2Shell Sie sich schriftlich bestätigen lassen, oder den Server bis zur Migration mit Übergangsmaßnahmen absichern und seine Erreichbarkeit einschränken. Auf Dauer ist nur der erste Weg tragfähig.
So vergleichen Sie den installierten Stand exakt
Ein Blick auf die Versionsnummer reicht nicht, weil Debian-Versionen nach eigenen Regeln sortiert werden. dpkg --compare-versions vergleicht korrekt. Die folgenden Befehle sind rein lesend; passen Sie Paketnamen und Zielstand an Ihr Release an.
# Installierter Stand und Herkunft des Pakets
apt policy php8.3-fpm
# Alle installierten PHP-Pakete mit Version
dpkg-query -W -f='${Package}\t${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null
# Exakter Vergleich mit dem korrigierten Stand (Beispiel Ubuntu 24.04)
v=$(dpkg-query -W -f='${Version}' php8.3-fpm)
dpkg --compare-versions "$v" ge 8.3.6-0ubuntu0.24.04.13 && echo "korrigiert: $v" || echo "PRÜFEN: $v"
Achten Sie in der Ausgabe von apt policy auf die Zeile mit der Paketquelle. Steht dort nicht das Sicherheitsarchiv Ihrer Distribution, sondern etwa packages.sury.org oder ein PPA, gelten die Tabellen oben nicht. Dann zählt der Stand dieser Drittquelle, den wir im Beitrag Das sury.org-Repository behandeln.
Zusätzlich lohnt der Blick in das mitgelieferte Changelog. Wie Sie dort die CVE-Nummern finden und als Nachweis festhalten, beschreibt der Beitrag CVE-Nummern im Paket-Changelog nachweisen.
Typische Fallen bei der Prüfung
Nur ein Paket geprüft: PHP besteht aus vielen Binärpaketen. Ist php8.3-cli aktuell, php8.3-fpm aber nicht, bleibt die Website offen. Prüfen Sie alle Pakete eines Zweigs, besonders FPM, CGI und das Apache-Modul.
Paket gehalten: Pakete, die per apt-mark hold festgehalten wurden, bleiben beim Update stehen. apt-mark showhold zeigt sie an.
Ubuntu Pro nicht aktiv: Auf 20.04 und älter kommen die Korrekturen nur, wenn Ubuntu Pro eingerichtet ist. Ohne Pro bleibt das System trotz Update-Lauf verwundbar.
Veralteter Spiegel: Holt der Server Pakete über einen internen Spiegel oder Proxy, sieht er neue Sicherheitsupdates erst, wenn dieser aktualisiert ist. Prüfen Sie im Zweifel, ob apt update die Sicherheitsquelle tatsächlich erreicht.
Neustart vergessen: Neue Pakete wirken erst nach dem Neustart aller Dienste, die PHP geladen haben. needrestart, falls installiert, zeigt Dienste mit veraltetem Code.
Ein korrigierter Paketstand belegt nur, dass die Lücke ab jetzt geschlossen ist. Ob der Server vorher angegriffen wurde, beantwortet er nicht. Sichern Sie die Logs ab dem 20. Oktober.
Wie hilft PHP SOS konkret?
- Wir ermitteln für jeden Server die Herkunft aller PHP-Pakete und vergleichen den Stand mit den offiziellen Meldungen.
- Wir spielen Updates ein, auch über Ubuntu Pro, und starten alle betroffenen Dienste neu.
- Mit dem PHP-Patch-Service erhalten Sie je Server einen Nachweis mit Paketstand, Changelog-Treffer und Neustartzeit.
- Auf Systemen mit Drittquellen oder Altversionen klären wir, welcher Weg zu einem belegbar korrigierten Stand führt.
Häufige Fragen
Welche Ubuntu-Version enthält den PHP2Shell-Fix?
Laut USN-8948-1 sind Ubuntu 22.04, 24.04, 26.04 und 26.10 mit regulären Updates versorgt. Für 14.04, 16.04, 18.04 und 20.04 liefert Ubuntu die Korrekturen laut USN-8948-2 über Ubuntu Pro aus.
Warum zeigt Ubuntu 24.04 weiter PHP 8.3.6 an?
Ubuntu übernimmt Sicherheitskorrekturen als Backport in die bestehende Version. Die Upstream-Nummer bleibt 8.3.6, nur der Paketstand ändert sich. Laut USN-8948-1 ist der korrigierte Stand 8.3.6-0ubuntu0.24.04.13.
Ist Debian 12 bookworm noch versorgt?
Ja. Laut Debian Security Tracker gibt es für php8.2 in bookworm den korrigierten Stand 8.2.35-1~deb12u1, angekündigt als DLA-4848-1 im Rahmen von Debian LTS.
Gilt das auch für PHP aus dem sury-Repository?
Nein. Pakete aus Drittquellen wie sury.org haben eigene Versionsstände und eigene Changelogs. Die Angaben von Debian und Ubuntu gelten nur für deren offizielle Pakete.
Reicht ein apt upgrade?
Es installiert die neuen Pakete, aber laufende PHP-FPM- oder Apache-Prozesse behalten den alten Code im Speicher. Erst ein Neustart aller Dienste, die PHP laden, macht den Patch wirksam.