PHP-Sicherheitsupdate prüfen: So weisen Sie nach, dass die Lücke geschlossen ist

Stand: 24. Oktober 2026. Die Versionsangaben beziehen sich auf die PHP2Shell-Lücken CVE-2026-109618 und CVE-2026-109619. Das Vorgehen gilt für jedes künftige PHP-Sicherheitsupdate.

Nach dem PHP-Sicherheitsupdate vom 21. Oktober 2026 stellen viele Unternehmen dieselbe Frage: Das Update ist eingespielt, aber wie lässt sich belegen, dass die Lücke wirklich geschlossen ist? Oft kommt die Frage nicht aus der IT, sondern von der Geschäftsführung, von Kunden oder aus einem Audit. Ein "Wir haben aktualisiert" reicht dann nicht.

Dieser Beitrag zeigt, wie Sie das Update Schritt für Schritt überprüfen und einen Nachweis erstellen, den auch Nicht-Techniker nachvollziehen können. Was hinter den Lücken steckt, welche Workarounds helfen und woran Sie einen Angriff erkennen, beschreiben wir im Beitrag PHP2Shell: Was Unternehmen jetzt tun sollten.

Kann man die Lücke nicht einfach testen?

Die naheliegende Idee ist, den Angriff gegen den eigenen Server auszuprobieren. Davon raten wir ab. Die bekannten Angriffe brauchen teils mehrere tausend Anfragen und zielen auf Speicherfehler. Gegen ein Produktivsystem riskieren Sie Abstürze und verfälschte Logs, und ein fehlgeschlagener Versuch beweist nicht, dass das System sicher ist, nur dass dieser eine Weg nicht funktioniert hat.

Auch externe Scanner helfen nur begrenzt. Sie lesen meist die PHP-Version aus, die der Server in seinen Antworten mitschickt. Bei Distributionen mit Backports melden sie dann gepatchte Systeme als verwundbar, und bei expose_php = 0 sehen sie gar nichts.

Ein belastbarer Nachweis entsteht deshalb nicht durch einen Test, sondern durch eine lückenlose Kette von Belegen: Welches Paket ist installiert, ist es laut Hersteller gepatcht, läuft der Prozess bereits mit dem neuen Code und ist es die PHP-Installation, die Ihre Website tatsächlich ausliefert.

Warum die Versionsnummer allein in die Irre führt

Das PHP-Projekt hat die Lücken in den Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 geschlossen. Diese Nummern gelten aber nur, wenn Sie PHP direkt vom PHP-Projekt beziehen, zum Beispiel über die offiziellen Docker-Images oder selbst kompiliert.

Linux-Distributionen gehen unterschiedlich vor:

• Ubuntu bleibt bei seiner PHP-Version und spielt nur die Korrektur zurück (Backport). Erkennbar ist der Patch ausschließlich am Paketzusatz nach dem Bindestrich.
• Debian hat diesmal auf die neuen offiziellen Versionen aktualisiert. Hier stimmt der Vergleich mit der Upstream-Version.
• Red Hat Enterprise Linux und Ableger wie AlmaLinux oder Rocky Linux arbeiten ebenfalls mit Backports. Maßgeblich ist der Paket-Changelog.
• Fremdpaketquellen wie die verbreiteten Pakete von Ondřej Surý (sury.org) liefern in der Regel die offiziellen Versionsnummern.

Diese Paketversionen sind laut Hersteller gepatcht (Stand 24. Oktober 2026):

Bei Ubuntu gilt: Der Paketzusatz muss mindestens dem Wert in der Tabelle entsprechen. 8.3.6-0ubuntu0.24.04.12 ist verwundbar, 8.3.6-0ubuntu0.24.04.13 ist gepatcht. Für Red Hat und seine Ableger empfiehlt Red Hat bis zum Update die Übergangsmaßnahmen aus dem Bulletin RHSB-2026-013. Für Debian 11 (bullseye) und andere Systeme prüfen Sie den aktuellen Stand im Debian Security Tracker beziehungsweise bei Ihrem Hersteller.

Schritt 1: Installierte Pakete und Patch-Stand prüfen

Zuerst klären Sie, welche PHP-Pakete installiert sind und ob der Hersteller sie als gepatcht führt.

Ubuntu und Debian

# Alle installierten PHP-Pakete mit vollständiger Paketversion
dpkg -l 'php*' 'libapache2-mod-php*' | grep '^ii'

# Enthält der Paket-Changelog die CVE-Nummer? (Ubuntu nennt CVEs dort immer)
zgrep -l 'CVE-2026-109619' /usr/share/doc/php8*/changelog.Debian.gz

# Ubuntu: offizielle Auskunft, ob das System für diese CVE gepatcht ist
sudo pro fix CVE-2026-109619

Vergleichen Sie die Versionen in der dritten Spalte mit der Tabelle oben. Wichtig sind vor allem die Pakete, die Webanfragen verarbeiten: php8.x-fpm, libapache2-mod-php8.x und php8.x-cgi. Der Befehl pro fix funktioniert auch ohne Ubuntu-Pro-Abonnement. Auf schlanken Server- oder Container-Images fehlen manchmal die Changelog-Dateien. Dann hilft apt changelog php8.3-fpm | grep CVE-2026-109619, das den Changelog aus dem Internet lädt.

Red Hat, AlmaLinux und Rocky Linux

# Installierte PHP-Pakete
rpm -qa 'php*'

# Taucht die CVE im Changelog des Pakets auf?
rpm -q --changelog php-fpm | grep CVE-2026-109619

Alpine und Docker

# Alpine
apk list -I 'php*'

# Docker: Version im laufenden Container prüfen, nicht nur im Image
docker exec <container> php -v

Bei Containern ist ein neues Image nur die halbe Miete. Jeder Container muss mit dem neuen Image neu gestartet werden, auch Worker, Queue-Prozesse und Images in Ihrer CI-Pipeline.

Schritt 2: Läuft der Prozess schon mit dem neuen Code?

Ein Paket-Update ersetzt die Dateien auf der Festplatte. Ein bereits laufender PHP-FPM- oder Apache-Prozess nutzt aber weiter den alten Code im Arbeitsspeicher, bis er neu gestartet wird. Genau hier entstehen die meisten Lücken im Nachweis: Das Paket ist aktuell, der Dienst nicht.

# Dienste neu starten (Namen an Ihre Version anpassen)
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

# Wann wurde das PHP-Paket aktualisiert?
grep -E ' (upgrade|install) .*php' /var/log/dpkg.log | tail -5

# Seit wann läuft der PHP-FPM-Master-Prozess?
ps -o lstart=,cmd= -p "$(pgrep -o -f 'php-fpm: master')"

# Nutzt der Prozess noch ersetzte (gelöschte) PHP-Dateien? Keine Ausgabe = gut
sudo grep -E '(php|\.so).*\(deleted\)' /proc/"$(pgrep -o -f 'php-fpm: master')"/maps

Die Startzeit des Prozesses muss nach dem Zeitpunkt des Updates liegen. Findet der letzte Befehl Einträge mit (deleted), läuft der Prozess noch mit den alten Dateien und muss neu gestartet werden. Bei Apache mit mod_php prüfen Sie entsprechend den Apache-Prozess (pgrep -o apache2 oder pgrep -o httpd). Auf Ubuntu-Servern ist häufig das Werkzeug needrestart vorinstalliert, das mit sudo needrestart -r l alle Dienste auflistet, die noch einen Neustart brauchen.

Schritt 3: Die PHP-Version prüfen, die Ihre Website wirklich nutzt

Auf vielen Servern sind mehrere PHP-Versionen installiert. php -v auf der Kommandozeile zeigt die Version der CLI, Ihre Website läuft aber über PHP-FPM oder mod_php, oft in einer anderen Version und mit einer anderen php.ini. Prüfen Sie deshalb auch, was der Webserver tatsächlich ausführt.

Geben Sie dafür nicht öffentlich phpinfo() aus. Die Seite verrät Pfade, Module und Einstellungen und wird von Angreifern gezielt gesucht. Besser ist ein kleines Prüfskript, das nur die nötigen Angaben liefert:

<?php
// Nur für die Prüfung. Datei sofort danach wieder löschen.
header('Content-Type: application/json');
header('Cache-Control: no-store');

// Build-Datum aus phpinfo() lesen, ohne phpinfo() auszugeben
ob_start();
phpinfo(INFO_GENERAL);
$info = strip_tags((string) ob_get_clean());
preg_match('/Build Date\s*(?:=>\s*)?([A-Z][a-z]{2}\s+\d{1,2}\s+\d{4}(?:\s+[\d:]+)?)/', $info, $match);

echo json_encode([
    'version'         => PHP_VERSION,
    'sapi'            => PHP_SAPI,
    'build_date'      => $match[1] ?? null,
    'php_ini'         => php_ini_loaded_file(),
    'upload_progress' => ini_get('session.upload_progress.enabled'),
], JSON_PRETTY_PRINT | JSON_THROW_ON_ERROR);

So gehen Sie vor:

1. Speichern Sie das Skript im Webverzeichnis unter einem langen, zufälligen Namen, zum Beispiel check-7f3a9c2e5b1d4f8a.php.
2. Rufen Sie es im Browser oder mit curl auf und sichern Sie die Ausgabe für Ihre Dokumentation.
3. Löschen Sie die Datei sofort danach.

Was die Angaben bedeuten:

• version: Der Versionszweig muss zu dem gepatchten Paket aus Schritt 1 passen. Bei Distributionen mit Backports steht hier nicht immer die vollständige Paketversion, deshalb zählt die Kombination mit Schritt 1 und 2.
• sapi: Zeigt die Betriebsart, etwa fpm-fcgi oder apache2handler. Damit wissen Sie, welcher Dienst neu gestartet werden musste.
• build_date: Das Datum, an dem das laufende PHP gebaut wurde. Liegt es nach dem 20. Oktober 2026, läuft ein nach Bekanntwerden der Lücken gebautes PHP. Das ist ein starkes Indiz, ersetzt aber nicht den Abgleich der Paketversion. Ist phpinfo() per disable_functions gesperrt, bleibt das Feld leer.
• upload_progress: Sollte vorerst 0 oder leer sein. Am 23. Oktober 2026 hat das PHP-Projekt eine verwandte Lücke gemeldet (CVE-2026-115560), die erst mit dem nächsten Update geschlossen wird. Bis dahin empfiehlt es, session.upload_progress.enabled = 0 zu setzen.

Bei Shared Hosting ohne Serverzugang ist dieses Skript oft der einzige Weg, selbst etwas zu prüfen. Lassen Sie sich zusätzlich vom Hoster schriftlich bestätigen, dass die gepatchten Pakete eingespielt und die PHP-Dienste neu gestartet wurden.

Schritt 4: Den Nachweis dokumentieren

Für Geschäftsführung, Kunden oder Auditoren fassen Sie die Belege pro System in einer kurzen Übersicht zusammen. Bewährt haben sich diese Angaben:

Die vorletzte Zeile ist bei PHP2Shell besonders wichtig: Die Lücken wurden schon vor der Veröffentlichung ausgenutzt. Ein Update schließt die Tür, entfernt aber keinen Angreifer, der bereits auf dem System ist. Worauf Sie dabei achten sollten, steht im Abschnitt Woran erkennen Sie, ob Ihr Server bereits angegriffen wurde? unseres Beitrags zu PHP2Shell.

Für den Kunden selbst reicht meist eine Zusammenfassung in zwei, drei Sätzen, zum Beispiel: "Alle Systeme, die PHP ausführen, wurden am 22. Oktober 2026 mit den Sicherheitsupdates der jeweiligen Hersteller aktualisiert und neu gestartet. Die wirksame Version wurde auf jedem System geprüft und dokumentiert. Hinweise auf eine Kompromittierung wurden nicht gefunden." Die Übersicht pro System halten Sie für Rückfragen bereit.

Typische Fehler bei der Prüfung

• Nur php -v geprüft: Die Kommandozeile sagt nichts darüber, welches PHP Ihre Website ausführt.
• Versionsnummer mit php.net verglichen: Bei Ubuntu und Red Hat führt das zu Fehlalarmen, weil gepatchte Pakete eine ältere Nummer tragen.
• Kein Neustart: Das Paket ist aktuell, der Prozess im Speicher nicht.
• Mehrere PHP-Versionen vergessen: Ein alter FPM-Pool, ein zweiter virtueller Host oder ein vergessener Container läuft weiter mit der verwundbaren Version. Nicht genutzte PHP-Versionen sollten Sie deinstallieren.
• phpinfo() öffentlich liegen gelassen: Die Prüfdatei bleibt im Webverzeichnis und verrät Angreifern Details über Ihr System.
• Nur gepatcht, nicht auf Angriffe geprüft: Bei Lücken, die vor dem Patch ausgenutzt wurden, ist das Update allein keine Entwarnung.

Wie wird der nächste Sicherheitsfall einfacher?

Der Aufwand für einen Nachweis hängt vor allem davon ab, wie gut Ihre Systeme vorher dokumentiert sind. Wer weiß, wo welche PHP-Version läuft, ist in einer Stunde fertig. Wer erst suchen muss, braucht Tage. Drei Maßnahmen helfen dauerhaft:

• Inventar führen: eine Liste aller Systeme mit Betriebssystem, PHP-Version, Betriebsart und Verantwortlichen.
• Sicherheitsmeldungen abonnieren: die Mailinglisten oder Feeds Ihrer Distribution (Ubuntu USN, Debian DSA) und die Ankündigungen auf php.net.
• Prüfung automatisieren: Paketstände und Neustartbedarf regelmäßig auslesen und überwachen, statt sie im Ernstfall manuell zusammenzutragen. Mehr dazu im Beitrag Kontinuierliche IT-Sicherheitsüberwachung.

Wie Sie PHP grundsätzlich für den Produktivbetrieb härten, lesen Sie unter PHP-Sicherheitseinstellungen für die Produktivumgebung. Was eine umfassendere Prüfung Ihrer Systeme kostet, zeigt der Beitrag IT-Sicherheitsprüfung: Kosten und Umfang. Welche Prozesse Unternehmen nach PHP2Shell grundsätzlich ändern sollten, von der Patch-SLA bis zum Budget für die Behebung, beschreibt der Beitrag Sicherheitslücken werden schneller gefunden als behoben.

Häufige Fragen

Fazit

Ob ein PHP-Sicherheitsupdate wirkt, lässt sich nicht an einer einzelnen Versionsnummer ablesen. Belastbar ist die Kette aus installiertem Paket, Sicherheitsmeldung des Herstellers, Neustart der Dienste und Prüfung im Webserver selbst. Wer diese vier Punkte pro System dokumentiert, kann Geschäftsführung und Kunden in wenigen Sätzen zeigen, dass die Lücke geschlossen ist, und ist beim nächsten Sicherheitsfall deutlich schneller.

Sie möchten die Prüfung nicht selbst übernehmen? Schreiben Sie uns oder buchen Sie ein kostenloses Erstgespräch. Für die übrigen Schritte rund um PHP2Shell gibt es unsere PHP2Shell-Checkliste als PDF.

Quellen (Stand 24. Oktober 2026): Release-Ankündigungen auf php.net, Ubuntu USN-8948-1, Debian Security Tracker, Red Hat RHSB-2026-013, Security Advisory CVE-2026-109618, Security Advisory CVE-2026-109619.