1 Jede PHP-Installation auf dem Server finden

Viele Server betreiben mehr als ein PHP: das Systempaket, von einem Control Panel installierte Versionen (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), Container und Kommandozeilen-Builds, die von Cron verwendet werden. Jede Installation, die Webanfragen bedient, muss aktualisiert werden.

Führen Sie php -v aus, listen Sie php-fpm-Prozesse mit ps aux | grep php-fpm auf und prüfen Sie den PHP-Selektor Ihres Panels.

2 Auf eine behobene Version aktualisieren

Die behobenen Upstream-Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Distributionspakete können den Fix unter einer älteren Versionsnummer enthalten — prüfen Sie das Changelog auf CVE-2026-109618 und CVE-2026-109619.

PHP 8.1 und älter erhalten kein Release des PHP-Projekts. Für 7.4, 8.0 und 8.1 wurden minimale Quellcode-Backports für alle veröffentlicht, die selbst kompilieren; die dauerhafte Lösung ist jedoch der Wechsel auf einen unterstützten Zweig.

Debian / Ubuntu (Distributionspakete)

Installieren Sie das Sicherheitsupdate Ihrer Distribution und starten Sie PHP neu. Die Versionsnummer kann gleich bleiben; das Changelog des Pakets nennt die CVE.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

Spielen Sie die Hersteller-Errata für Ihren PHP-Modul-Stream ein und starten Sie anschließend neu.

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / offizielle php-Images

Ziehen Sie das Image mit dem behobenen Tag oder bauen Sie es neu und erstellen Sie die Container neu.

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel, Plesk, CWP, DirectAdmin

Verwenden Sie das Update-Werkzeug des Panels für jede installierte PHP-Version (EA-PHP, Plesk-PHP-Handler, alt-php, CustomBuild) und starten Sie anschließend PHP-FPM neu. Panels behalten alte Versionen oft für einzelne Websites installiert — aktualisieren oder entfernen Sie auch diese.

Shared oder Managed Hosting

In der Regel können Sie PHP nicht selbst aktualisieren. Bitten Sie Ihren Anbieter mit der Nachricht auf der Ergebniskarte um die genaue Version, das Patch-Datum und die Bestätigung, dass die Worker neu gestartet wurden.

Windows / IIS

Laden Sie den behobenen Build von windows.php.net herunter, ersetzen Sie das PHP-Verzeichnis und recyceln Sie die IIS-Anwendungspools.

3 Alle PHP-Prozesse neu starten

Die Installation eines Pakets ändert keinen Code, der bereits läuft. Starten Sie PHP-FPM, Apache (bei mod_php), LiteSpeed, FrankenPHP, Queue-Worker und Supervisor neu. Bei Containern bauen Sie das neue Image neu oder ziehen es — ein Neustart desselben Images installiert keinen Patch.

4 Überprüfen

Führen Sie php -v für jedes Binary aus und vergewissern Sie sich, dass die laufenden Prozesse den neuen Build verwenden (zum Beispiel sollte ls -l /proc/$(pgrep -o php-fpm)/exe nicht „deleted“ anzeigen). Führen Sie anschließend diese Prüfung erneut aus.

5 Wenn Sie heute nicht aktualisieren können

Wenden Sie die unten aufgeführten teilweisen Gegenmaßnahmen an und schränken Sie ein, wer die Website erreichen kann, bis Sie aktualisieren können. Sie verringern das Risiko, beseitigen es aber nicht.

6 Nach Anzeichen einer Kompromittierung suchen — und Geheimnisse wechseln

War eine verwundbare Website aus dem Internet erreichbar, prüfen Sie die Aktivitäten ab dem 20. Oktober 2026: Abstürze von PHP-Workern (SIGSEGV) im Fehlerlog von PHP-FPM oder Apache, neue oder geänderte PHP-Dateien im Web-Root, neue Cronjobs, neue Administratorkonten und unerwartete ausgehende Verbindungen.

Da CVE-2026-109619 den Speicher des PHP-Prozesses ohne jede Codeausführung offenlegen kann, ist ein sauberes Dateisystem kein Beweis dafür, dass nichts abgeflossen ist. Wechseln Sie bei exponierten Websites Datenbankpasswörter, API-Schlüssel sowie Zahlungs- und E-Mail-Zugangsdaten und machen Sie Benutzersitzungen ungültig.

7 Nach dem Update

Der Fix führt ein neues hartes Speicherlimit ein: Ein Prozess, der es erreicht, wird sofort beendet, und Shutdown-Handler werden nicht ausgeführt. Prüfen Sie, wie sich Ihre Anwendung bei Speicherknappheit verhält, überprüfen Sie memory_limit zusammen mit post_max_size und max_input_nesting_level, und machen Sie ein vor dem Patchen vorübergehend gesetztes memory_limit = -1 rückgängig. Das Verbergen der Version mit expose_php = Off ist eine optionale Härtung, kein Fix.

Teilweise Gegenmaßnahmen (von php.net und aus den Sicherheitshinweisen)

Diese schränken nur die bekannten Angriffswege ein. php.net stellt klar, dass ein Update die einzige sichere Wahl ist.

; php.ini / FPM pool (php_admin_value) — danach alle Worker neu starten
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M falls Uploads benötigt werden
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

Setzen Sie diese Werte in der php.ini, im PHP-FPM-Pool (php_admin_value) oder in der Serverkonfiguration — nicht mit ini_set() oder .user.ini — und starten Sie die Worker neu. Weitere Maßnahmen aus den Sicherheitshinweisen und vom Forschungsteam:

memory_limit = -1 blockiert einige Angriffswege, die auf PHPs eigenem Speicherlimit beruhen, überlässt die Speichererschöpfung aber dem Betriebssystem — verwenden Sie es nur zusammen mit einem cgroup v2-Limit memory.max. Verwenden Sie kein RLIMIT_AS oder RLIMIT_DATA; sie können dieselben verwundbaren Pfade auslösen.
Senken Sie max_input_nesting_level so weit, wie Ihre Formulare es zulassen.
Senken Sie pm.max_requests in PHP-FPM, damit Worker häufiger erneuert werden (kostet Leistung).
Limits für Anfragegröße, Feldanzahl und Verschachtelungstiefe auf Webserver- oder Proxy-Ebene; entfernen Sie ungültige oder veraltete INI-Einstellungen pro Anfrage.
SELinux- oder AppArmor-Richtlinien können einschränken, was ein kompromittierter Worker ausführen darf — sie verringern die Auswirkungen, verhindern aber keine Offenlegung von Speicher.

Quellen

Quelle: Sicherheitshinweis auf php.net, 21. Oktober 2026. Zuletzt geprüft am 2026-10-23.