PHP-Patchstand: Welche PHP-Version ist gepatcht? Stand für PHP 8.2 bis 8.6 und je Paketquelle

Stand: November 2026, Security-Release vom 21.10.2026 released, CVE-2026-115560 offen

Diese Seite fasst den aktuellen Patchstand für die unterstützten PHP-Zweige zusammen und wird bei jedem PHP-Sicherheitsrelease aktualisiert. Sie beantwortet zwei Fragen: Welche Version schließt welche Lücke? Und woran erkennen Sie auf Ihrem Server, ob der Fix tatsächlich angekommen ist?

Zeitplan der Sicherheitsupdates

Patchstand je PHP-Zweig

PHP2Shell: CVE-2026-109618 und CVE-2026-109619 (released)

Die beiden Lücken ermöglichen laut php.net unter Umständen Codeausführung ohne Anmeldung. CVE-2026-109618 betrifft die Behandlung von Speicherfehlern während der Request-Verarbeitung, CVE-2026-109619 veralteten internen Zustand in langlebigen Workern. Betroffen sind alle PHP-Installationen, die Web-Requests verarbeiten. Laut watchTowr-FAQ wurde CVE-2026-109618 am 26.10.2026 in den KEV-Katalog der US-Behörde CISA aufgenommen, der aktiv ausgenutzte Schwachstellen listet. Die technischen Hintergründe und die Übergangsmaßnahmen stehen im Beitrag zum PHP-Sicherheitsupdate vom 21. Oktober.

Windows-Builds: Brotli, CVE-2026-111497 (released)

Am 26.10.2026 hat das PHP-Projekt neue Windows-Builds 8.5.12-1, 8.4.27-1, 8.3.36-1 und 8.2.35-1 bereitgestellt. Sie enthalten eine aktualisierte Brotli-Bibliothek gegen CVE-2026-111497. Der PHP-Quellcode ist unverändert, die Versionsnummer bleibt deshalb gleich, nur das Suffix ändert sich. Für Linux-Installationen ist dieser Build nicht relevant.

Session Upload Progress: CVE-2026-115560 (angekündigt, Fix offen)

php.net kündigt das vollständige Advisory zu CVE-2026-115560 für das nächste Release an. Bis dahin empfiehlt das PHP-Projekt, session.upload_progress.enabled auf 0 zu setzen. Das gilt auch für Installationen, die gegen PHP2Shell bereits gepatcht sind. Die Einstellung muss in der php.ini, im FPM-Pool oder in der Server-Konfiguration stehen, damit sie vor dem Parsen des Requests greift.

; /etc/php/8.4/fpm/pool.d/www.conf
; Empfehlung von php.net bis zum nächsten regulären Release
php_admin_flag[session.upload_progress.enabled] = off

Warum die Versionsnummer nicht reicht

Auf vielen Systemen zeigt php -v nach dem Patch dieselbe Versionsnummer wie vorher. Das liegt an Backports. Distributionen und Paketquellen übernehmen den Fix in ihre bestehende Version und erhöhen nur die Paketrevision. Das betrifft vor allem drei Fälle: EOL-Zweige auf packages.sury.org, Red Hat Enterprise Linux und den Extended Support mancher Hoster. Bei RHEL bleibt die Version nach RHSA-2026:87080 beispielsweise bei 7.4.33.

Verlässlich sind deshalb zwei Merkmale: die Paketrevision oder das Build-Datum ab dem 21.10.2026 und ein Neustart aller PHP-Prozesse nach dem Update.

# Build-Datum der laufenden CLI-Binary
php -i | grep -i "build date"

# Installierte Paketrevision (Debian/Ubuntu)
dpkg -l 'php8.*-fpm' | grep ^ii

# Woher kommt das Paket: Debian-Security oder sury?
apt-cache policy php8.4-fpm

# Startzeit der FPM-Master: muss nach dem Paket-Update liegen
ps -eo pid,lstart,cmd | grep '[p]hp-fpm: master'

# RHEL: Changelog des Pakets auf die CVE prüfen
rpm -q --changelog php | grep -E 'CVE-2026-10961(8|9)'

Verfügbarkeit nach Paketquelle

Hinweis zu sury und Debian-Paketen

Ist packages.sury.org neben den Debian-Quellen eingebunden, kann ein apt upgrade ein Debian-Paket wie php8.4 auf den sury-Build umstellen. Das ist kein Fehler, verändert aber die Herkunft Ihrer Pakete. Wer bewusst bei Debian bleiben will, legt die Priorität per Pinning fest:

# /etc/apt/preferences.d/php-debian
# Debian-Pakete für php8.4 bevorzugen, sury nur für fehlende Zweige
Package: php8.4*
Pin: origin packages.sury.org
Pin-Priority: 100

Hinweis zu Docker

Tags wie php:8.4-fpm zeigen nach einem Rebuild auf ein neues Image, ein bereits gezogenes lokales Image bleibt aber alt. Prüfen Sie deshalb den Digest und nicht nur den Tag:

# Digest des lokal vorhandenen Images
docker image inspect --format '{{index .RepoDigests 0}}' php:8.4-fpm

# Aktueller Digest in der Registry
docker buildx imagetools inspect php:8.4-fpm | grep Digest

# Unterscheiden sich beide: neu ziehen, neu bauen, neu deployen
docker compose build --pull --no-cache app
docker compose up -d app

In CI-Pipelines und Build-Images gilt dasselbe. Wer Basis-Images per Digest pinnt, muss den Digest aktiv anheben.

Beim Hoster

Bei Shared- und Managed-Webhosting patcht der Anbieter die PHP-Laufzeit. Hetzner, IONOS, mittwald und Raidboxes haben das für PHP2Shell öffentlich bestätigt. Wer PHP auf einem VPS, einem Root-Server oder im eigenen Container betreibt, ist selbst zuständig. Anwendungscode, Composer-Abhängigkeiten und Plugins bleiben in jedem Fall bei Ihnen. Die Details und Quellen je Anbieter stehen im Artikel PHP-Sicherheitsupdate beim Hoster.

::

Was sich seit dem letzten Update geändert hat

1. Erstveröffentlichung der Patchstand-Seite am 03.11.2026.
2. Aufgenommen: Security-Release vom 21.10.2026 mit Verfügbarkeit je Paketquelle.
3. Aufgenommen: Windows-Builds vom 26.10.2026 mit Brotli-Fix (CVE-2026-111497).
4. Aufgenommen: KEV-Eintrag für CVE-2026-109618 laut watchTowr-FAQ.
5. Offen: CVE-2026-115560, Advisory mit dem nächsten Release angekündigt.

Einordnung für bestehende Projekte

Für Symfony- und Shopware-Projekte reicht ein gepatchter Server allein nicht, wenn der Code in Containern oder auf mehreren Umgebungen läuft. Prüfen Sie die PHP-Version in Staging, Produktion, CI und in allen Build-Images. Steht in der composer.json eine Plattformversion unter config.platform.php, ändert ein Patch-Release daran nichts, solange Sie innerhalb desselben Zweigs bleiben.

Projekte auf PHP 8.2 sind für PHP2Shell abgedeckt, verlieren aber zum Jahresende den Security-Support. Welche Frist für Ihr Projekt tatsächlich zählt, beschreibt der Artikel zu PHP 8.2 End of Life und Symfony 6.4. Mit PHP 8.6 erscheint am 19.11.2026 der nächste Zweig, die Neuerungen fasst der Sammelartikel zu PHP 8.6 zusammen.

Wer bei solchen Releases nicht jedes Mal selbst nachziehen will, legt Zuständigkeit und Takt im Wartungsvertrag mit festem Patch-Takt fest. Für akute Fälle gibt es die Notfall-Lösung. Diese Seite aktualisiere ich am Tag jedes PHP-Sicherheitsrelease, als Nächstes mit dem Advisory zu CVE-2026-115560.

::cta-follow::