Aktuelle Lage: PHP2Shell. Zwei kritische PHP-Lücken (CVSS 9.2) erlauben Schadcode ohne Anmeldung. Patches seit 21.10.2026.Was jetzt zu tun ist →

cPanel und WHM: PHP absichern

cPanel verwaltet PHP über EasyApache 4 mit eigenen Paketen je Version. So prüfen Sie den Stand, starten alle Prozesse neu und setzen Übergangswerte richtig.

Stand 5 Min. LesezeitServer & Hosting

Kurz gesagt: Ein cPanel PHP-Update nach PHP2Shell umfasst drei Schritte: alle ea-php- und gegebenenfalls alt-php-Pakete auf einen behobenen Stand bringen, PHP-FPM und Apache vollständig neu starten und den Paketstand dokumentieren. Kunden auf dem Server können die wichtigsten Übergangswerte nicht selbst setzen, das muss der WHM-Administrator tun.

Ausgangslage auf cPanel-Servern

PHP2Shell umfasst die Lücken CVE-2026-109618 und CVE-2026-109619 in PHP selbst. Beide erlauben die Ausführung von Schadcode ohne Anmeldung und sind mit CVSS v4.0 9.2 bewertet. Betroffen sind PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP-Projekt hat am 21.10.2026 die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht.

cPanel bringt PHP nicht als einzelnes Paket mit, sondern über EasyApache 4 mit je einem Paketsatz pro Version, etwa ea-php83 oder ea-php84. Dazu kommen auf manchen Servern die Pakete des Betriebssystems und auf CloudLinux die alt-php-Versionen. Jede Quelle hat einen eigenen Stand. Ein vollständiges Bild entsteht erst, wenn Sie alle drei prüfen.

cPanel PHP-Update: Bestand und Zuordnung prüfen

Beginnen Sie mit einer Bestandsaufnahme. Die folgenden Befehle lesen nur und verändern nichts. Pfade und Paketnamen sind Beispiele und können je nach Installation abweichen.

# Installierte PHP-Versionen laut WHM-API
whmapi1 php_get_installed_versions

# Version je ea-php-Installation
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$p"; "$p" -v | head -1; done

# Paketstand (RPM-basierte Systeme, Beispiel)
rpm -qa | grep -E '^ea-php[0-9]+-php-(cli|fpm|common)' | sort

Im MultiPHP Manager sehen Sie, welche Domain welche Version nutzt und ob PHP-FPM aktiviert ist. Halten Sie Versionen fest, die installiert, aber keiner Domain zugewiesen sind. Auch sie gehören aktualisiert oder entfernt.

Backports richtig einordnen

Wie bei anderen Anbietern gilt: Die angezeigte Versionsnummer ist nicht der einzige Maßstab. Wird ein Fix als Backport ausgeliefert, kann die Nummer unverändert bleiben. Prüfen Sie daher zusätzlich das Änderungsprotokoll des Pakets und die Hinweise des Anbieters.

# Änderungsprotokoll eines Pakets nach CVE-Nummern durchsuchen (Beispiel)
rpm -q --changelog ea-php84-php-cli | grep -iE 'CVE-2026-1096(18|19)'

Findet sich kein Eintrag, heißt das nicht automatisch, dass der Fix fehlt. Es heißt aber, dass Sie eine schriftliche Bestätigung brauchen, bevor Sie den Server als gepatcht einstufen. Wie Sie Versionen richtig lesen, beschreibt PHP-Version und Patchstand prüfen.

Update, Neustart und Kontrolle

Das Update spielen Sie in WHM über die Systemaktualisierung oder per Paketverwaltung ein. Danach starten Sie alle PHP-Prozesse neu. Neue Dateien allein reichen nicht, solange alte Prozesse im Speicher laufen.

# PHP-FPM-Dienste aller Versionen neu starten (cPanel-Skript)
/scripts/restartsrv_apache_php_fpm

# Apache vollständig neu starten
/scripts/restartsrv_httpd

# Startzeit der PHP-Prozesse kontrollieren
ps -eo pid,lstart,cmd | grep -E 'php-fpm|lsphp|php-cgi' | grep -v grep

Jeder PHP-Prozess sollte eine Startzeit nach dem Update haben. Ist das nicht so, beenden Sie ihn gezielt über den zugehörigen Dienst. Bei mehreren Servern lohnt ein kurzes Protokoll je Maschine, das Sie später als Nachweis verwenden können.

Wichtig

Ein CMS-Update über cPanel-Werkzeuge wie WP Toolkit schließt die PHP-Lücke nicht. Es ist sinnvoll, ersetzt aber weder das PHP-Update noch den Neustart.

Übergangswerte zentral setzen

Ist eine Version noch nicht behoben, empfiehlt php.net Übergangsmaßnahmen, die keinen vollständigen Schutz bieten. Auf cPanel setzen Sie diese im MultiPHP INI Editor im Modus für Administratoren oder direkt in der php.ini der jeweiligen ea-php-Version. Werte in .user.ini der Kundenkonten genügen für session.upload_progress.enabled nicht.

; serverweite php.ini der betroffenen Version (Beispiel)
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 24M

Ohne Upload-Funktion nennt php.net post_max_size = 8M. Auf PHP 8.5 kommt fatal_error_backtraces=0 hinzu. Danach starten Sie alle Worker erneut. Eine Speichergrenze setzen Sie über cgroups, etwa mit den Limits von CloudLinux, nicht über RLIMIT_AS oder RLIMIT_DATA. Weitere Details stehen unter Sofortmaßnahmen ohne Patch.

Verantwortung zwischen Serverbetreiber und Konteninhabern

Auf einem cPanel-Server mit vielen Konten trägt der WHM-Administrator die Verantwortung für PHP, Dienste und serverweite Konfiguration. Die Inhaber einzelner Konten sind für ihre Anwendungen, Plugins und Zugangsdaten zuständig. Informieren Sie die Konteninhaber, wann und wie gepatcht wurde, und empfehlen Sie ihnen, ihre Anwendungen auf Auffälligkeiten zu prüfen. Wie die Lage aus Kundensicht aussieht, beschreibt Shared Hosting.

Bewahren Sie die Logs ab dem 20.10.2026 auf. Ein Patch entfernt keine Schadsoftware, die vorher eingeschleust wurde.

Für den Nachweis genügt ein schlichtes Protokoll je Server: Datum und Uhrzeit des Updates, Liste der ea-php- und alt-php-Pakete mit Version vorher und nachher, die Prozessliste mit Startzeiten nach dem Neustart und gegebenenfalls die Bestätigung des Paketlieferanten zu Backports. Legen Sie das Protokoll außerhalb des Servers ab. Es dient später als Beleg gegenüber Kunden, Versicherern oder Prüfern und erleichtert die nächste Notfallaktualisierung, weil die Schritte bereits beschrieben sind. Betreiben Sie mehrere cPanel-Server, lohnt es sich, die Lesebefehle von dieser Seite in ein kleines Skript zu fassen, das auf allen Maschinen gleich läuft und die Ergebnisse sammelt. So erkennen Sie Abweichungen zwischen Servern, etwa eine vergessene PHP-Version, auf einen Blick.

Wie hilft PHP SOS konkret?

  • Wir inventarisieren ea-php-, alt-php- und Systempakete und ordnen alle Konten ihrer PHP-Version zu.
  • Über unseren PHP-Patch-Service aktualisieren wir, starten alle Dienste neu und belegen den Stand mit Paketlisten und Prozesszeiten.
  • Wo nötig, setzen wir Übergangswerte serverweit und nicht überschreibbar.
  • Wir prüfen die Konten auf typische Spuren einer Kompromittierung und leiten bei Befund die Malware-Entfernung ein.
  • Anschließend reduzieren wir die Zahl der PHP-Versionen und härten die Konfiguration.

Häufige Fragen

Wo sehe ich in WHM, welche Domain welche PHP-Version nutzt?

Im MultiPHP Manager von WHM sehen Sie für jede Domain die zugewiesene Version und ob PHP-FPM aktiv ist. Für eine vollständige Liste eignet sich zusätzlich die Abfrage per Kommandozeile. Notieren Sie auch Versionen, die keiner Domain zugeordnet sind.

Darf ein cPanel-Kunde die Übergangswerte selbst in .user.ini setzen?

Für session.upload_progress.enabled nennt php.net ausdrücklich, dass .user.ini und ini_set() nicht genügen. Der Wert gehört in die php.ini, den FPM-Pool oder die Serverkonfiguration. Das kann nur der Serveradministrator.

Reicht ein graceful Restart von Apache?

Bei PHP-FPM müssen die FPM-Dienste selbst neu starten, ein Apache-Reload erneuert sie nicht. Bei Apache-basierten PHP-Handlern ist ein vollständiger Neustart der sichere Weg. Prüfen Sie anschließend die Startzeit aller PHP-Prozesse.

Was ist mit CloudLinux und alt-php?

Auf CloudLinux-Servern laufen Websites teils mit eigenen alt-php-Paketen statt mit ea-php. Diese haben einen eigenen Paketstand und müssen gesondert geprüft und aktualisiert werden.

Quellen

Sofort-Kontakt

Jede Stunde zählt. Schreiben Sie uns jetzt.

Schildern Sie kurz System, PHP-Version und Beobachtung. Wir melden uns, klären die Lage und arbeiten remote, bis der Vorfall abgeschlossen und dokumentiert ist.

Sofort-Hilfe