PHP2Shell und Coolify: PHP-Sicherheitslücken jetzt richtig schließen

Stand: 21. Oktober 2026, 15:44 Uhr MESZ. Der ursprünglich für 16:00 Uhr deutscher Zeit angekündigte PHP-Sicherheitsrelease ist inzwischen auf php.net veröffentlicht. Für Coolify muss zusätzlich geprüft werden, ob das angebotene Image bereits die reparierte PHP-Laufzeit enthält.

Wer Coolify betreibt, sollte jetzt zwei Dinge getrennt aktualisieren: die Coolify-Instanz selbst und jede darüber bereitgestellte PHP-Anwendung. Ein grünes Update-Symbol im Dashboard beweist noch nicht, dass alle Anwendungen eine reparierte PHP-Version verwenden.

Was zu den beiden PHP-Sicherheitslücken feststeht

Die beiden unter „PHP2Shell“ diskutierten Schwachstellen heißen CVE-2026-109618 und CVE-2026-109619. Sie werden als kritisch mit CVSS v4.0 9,2 eingestuft. Das PHP-Team fordert zum sofortigen Update auf. Die offizielle PHP-Sicherheitsmeldung nennt Web-Runtimes wie PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.

CVE-2026-109618 betrifft die Behandlung von Speichererschöpfung. Beim Abbruch eines Requests können unvollständig initialisierte interne Daten zurückbleiben und anschließend verarbeitet werden. Das offizielle Advisory beschreibt daraus entstehende Möglichkeiten zur Ausführung fremden Codes. PHP-Advisory zu CVE-2026-109618

CVE-2026-109619 betrifft veraltete interne Zustände zwischen Requests. Ein PHP-Worker kann auf Speicher zugreifen, den ein früherer Request bereits freigegeben hat. Das Advisory dokumentiert auch bestätigte Angriffspfade für PHP-FPM. FPM ist deshalb keine pauschale Entwarnung. PHP-Advisory zu CVE-2026-109619

Ein Login oder ein Update des Anwendungscodes beseitigt diese Fehler in der PHP-Laufzeit nicht.

Diese PHP-Versionen enthalten die Sicherheitskorrekturen

Für die aktuell unterstützten PHP-Zweige nennt PHP folgende erste reparierte Versionen:

• PHP 8.2: 8.2.35
• PHP 8.3: 8.3.36
• PHP 8.4: 8.4.27
• PHP 8.5: 8.5.12

Diese Zuordnung gilt jeweils innerhalb des genannten Versionszweigs. Die offiziellen PHP-Advisories führen die betroffenen Vorgängerversionen und die korrigierten Releases auf.

Bei Distributionspaketen kann ein Hersteller den Fix zurückportieren, ohne die Upstream-Versionsnummer entsprechend anzuheben. Dann ist dessen Sicherheitsmeldung einschließlich der korrigierten Paketversion maßgeblich.

PHP 8.1 und ältere Zweige liegen außerhalb des regulären PHP-Projektsupports. PHP stellt für diesen Vorfall ausnahmsweise minimale Quellcode-Backports für 7.4, 8.0 und 8.1 bereit. Das ersetzt keinen regulär unterstützten Versionszweig. Klären Sie einen nachweislich reparierten Hersteller-Build oder die Migration auf eine unterstützte Version. PHP-Sicherheitsmeldung

Warum Coolify ebenfalls geprüft werden muss

Coolify verwendet selbst PHP. Das Produktions-Dockerfile von Coolify v4.4.6 baut auf einem PHP-8.4-Image auf. Die konkrete PHP-Patchversion im tatsächlich gestarteten Container muss deshalb geprüft werden.

Zum oben angegebenen Recherche-Stand führen die offiziellen Coolify-Releases und die Versionsdatei des Coolify-CDN noch 4.4.6 als stabile Version. Ein neuer, nachweislich für diese PHP-Lücken korrigierter Coolify-Release ist zu diesem Zeitpunkt noch nicht bestätigt. 4.4.6 wird in diesem Guide ausdrücklich nicht als Sicherheitsfix empfohlen.

Für eine betroffene selbst gehostete Instanz benötigen Sie ein erneuertes Coolify-Image mit repariertem PHP. Parallel müssen Sie Ihre eigenen PHP-Anwendungen aktualisieren. Laut Coolify-Update-Dokumentation aktualisiert ein Instanzupdate weder die verwalteten Anwendungen noch deren Server oder Datenbanken.

Schritt 1: PHP-Container und laufende Versionen erfassen

Die folgenden Befehle sind für eine Bash-Shell auf dem Linux-Dockerhost gedacht. Führen Sie die Inventur auf jedem Anwendungsserver aus. Der Host, auf dem Coolify läuft, muss nicht zugleich der einzige Anwendungsserver sein.

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}' docker exec coolify php -v docker inspect \ --format 'image={{.Config.Image}} image_id={{.Image}} started={{.State.StartedAt}}' \ coolify

Wiederholen Sie die Prüfung für jede PHP-Anwendung. Ersetzen Sie den Beispielnamen durch den Namen aus der Containerliste:

APP_CONTAINER='name-aus-docker-ps' docker exec "$APP_CONTAINER" php -v docker exec "$APP_CONTAINER" php --ini docker inspect \ --format 'image={{.Config.Image}} image_id={{.Image}}' \ "$APP_CONTAINER"

Wichtig: php -v und php --ini prüfen den aufgerufenen Kommandozeilenprozess. Sie beweisen nicht automatisch, dass der Webserver dieselbe PHP-Version oder Konfiguration nutzt. PHP kann je nach SAPI unterschiedliche Konfigurationsdateien laden. PHP-Dokumentation zur Konfiguration

Bei einem FPM-Image können Sie zusätzlich das FPM-Binary prüfen:

docker exec "$APP_CONTAINER" php-fpm -v docker exec "$APP_CONTAINER" php-fpm -i

Der Binärname kann je nach Image abweichen, beispielsweise php-fpm8.4 oder php-fpm84. Bei Apache/mod_php, FrankenPHP oder LiteSpeed prüfen Sie stattdessen die tatsächlich eingesetzte Web-Runtime. Die Ausgabe von php-fpm -i kann sensible Konfigurationsangaben enthalten und gehört nicht ungeprüft in öffentliche Tickets.

Schritt 2: Eine ungepatchte Coolify-Instanz vorübergehend isolieren

Wenn noch kein bestätigtes repariertes Coolify-Image bereitsteht, empfiehlt die Coolify-Sicherheitsanleitung zu diesem Vorfall, die öffentlich erreichbare selbst gehostete Instanz zu stoppen oder wirksam zu isolieren.

Für die Standardinstallation lautet der gezielte Stopp:

docker stop coolify

Dadurch sind Dashboard, API, Webhook-Deployments und Coolifys Hintergrundaufgaben vorübergehend nicht verfügbar. Bereits gestartete Anwendungen, Datenbanken und der Proxy laufen weiter. Stoppen Sie dafür nicht den gesamten Docker-Dienst oder den Proxy.

Dieser Schritt schützt die eigenen PHP-Anwendungen nicht mit. Auch diese brauchen ihre reparierte Laufzeit oder eine separate Isolation. Ist ein kurzfristiger Patch nicht möglich, empfiehlt CERT-EU, öffentlich erreichbare Anwendungen vorübergehend vom öffentlichen Netz zu trennen.

Ein versteckter Dashboard-Link oder eine andere Portnummer ist keine Zugriffsbeschränkung. Prüfen Sie bei einer Isolation auch direkte Portfreigaben und alternative Zugangswege.

Schritt 3: Coolify mit einem bestätigten Sicherheitsimage aktualisieren

Erstellen Sie vor dem Update eine aktuelle Instanzsicherung. Prüfen Sie anschließend die Release Notes und die enthaltene PHP-Version. Die Zielversion muss den PHP-Fix tatsächlich enthalten.

Ist das Dashboard noch erreichbar und abgesichert, führt der dokumentierte Weg über Settings → Updates → Check now und anschließend das angebotene Update. „Check now“ prüft zunächst nur, ob ein Release verfügbar ist. Coolify aktualisieren

Wurde Coolify gestoppt, erfolgt das Update direkt per SSH. Starten Sie dafür nicht erst wieder das alte öffentlich erreichbare Image. Laden Sie das offizielle Skript zunächst zur Prüfung herunter:

curl -fsSL https://cdn.coollabs.io/coolify/upgrade.sh \ -o /tmp/coolify-upgrade.sh less /tmp/coolify-upgrade.sh

Erst wenn der Hersteller eine reparierte Coolify-Version bestätigt hat, tragen Sie diese als Zielversion ein. Ersetzen Sie den Platzhalter; unverändert führt dieses Beispiel kein Update aus:

COOLIFY_PATCH_VERSION='BESTAETIGTE_FIX_VERSION_EINTRAGEN' if [ -n "$COOLIFY_PATCH_VERSION" ] && \ [ "$COOLIFY_PATCH_VERSION" != 'BESTAETIGTE_FIX_VERSION_EINTRAGEN' ]; then sudo bash /tmp/coolify-upgrade.sh "$COOLIFY_PATCH_VERSION" else printf 'Abgebrochen: zuerst die bestätigte Zielversion eintragen.\n' >&2 fi

Der Versionsparameter ist in der offiziellen Anleitung zum Wechsel der Coolify-Version dokumentiert. Verwenden Sie hier einen bestätigten Sicherheitsrelease. Das Upgrade-Skript startet Coolify wieder. Solange Coolify gestoppt ist, dürfen Sie nicht auf dessen automatische Updates vertrauen.

Prüfen Sie danach mindestens Dashboard, angezeigte Coolify-Version und PHP im gestarteten Container erneut.

Schritt 4: Die eigenen PHP-Anwendungen neu bauen und ausrollen

Aktualisieren Sie die PHP-Basis jeder betroffenen Anwendung. Dazu gehören auch Worker, Scheduler, Vorschauumgebungen und weitere Replikate, wenn sie eine eigene PHP-Laufzeit verwenden.

Bei einem eigenen Dockerfile: Wählen Sie in jeder relevanten Build- und Laufzeitstufe ein bestätigtes repariertes PHP-Image. PHP-Quellreleases, Distributionspakete und Dockerimages werden nicht zwingend gleichzeitig veröffentlicht.

Aktueller Image-Stand: Bei der Prüfung um 15:43 Uhr MESZ war das offizielle Docker-Hub-Tag php:8.4.27-fpm noch nicht verfügbar. Die Definition der offiziellen PHP-Images führte noch 8.4.26 und einen Release Candidate. Verwenden Sie keinen RC als hier bestätigten Produktionsfix.

Das folgende FROM ist deshalb ein Zielbeispiel für die Zeit nach Veröffentlichung und Prüfung des stabilen Images, kein zum genannten Stand garantiert abrufbares Image:

FROM php:8.4.27-fpm

Übernehmen Sie nicht blind eine andere Image-Familie. Ein bestehendes Alpine-, Apache-, FrankenPHP- oder serversideup/php-Setup braucht eine dazu passende reparierte Variante. Auch fest gepinnte Digests müssen gezielt ersetzt werden.

Lösen Sie danach in Coolify ein neues Deployment aus. Falls die Option verfügbar ist, verwenden Sie Force deploy (without cache). Prüfen Sie die Build-Logs und die PHP-Version im neuen Container. Die Coolify-Dokumentation weist darauf hin, dass eigene Compose-Buildbefehle ihre Cache-Flags selbst steuern.

Ein Build ohne Cache lädt nicht automatisch ein frisches Basisimage. Dafür ist zusätzlich --pull erforderlich. Ein weiterhin auf ein altes Image oder einen alten Digest festgelegtes Dockerfile bleibt auch mit diesen Flags auf diesem Stand. Docker: aktuelle Basisimages und saubere Builds

Bei Nixpacks oder einem anderen Buildpack: Prüfen Sie zusätzlich Builder, Paketquelle und tatsächlich aufgelöste PHP-Version. Bei Nixpacks kann der Paketstand an ein bestimmtes Nixpkgs-Archiv gebunden sein. Ein unveränderter Buildplan kann deshalb erneut altes PHP installieren. Nixpacks-Konfiguration

Schritt 5: Befehle für eigenständig verwaltete Compose-Projekte

Die folgenden Beispiele gelten für Projekte, deren Compose-Datei Sie selbst verwalten. Führen Sie sie nicht blind in Coolifys generierten Konfigurationsverzeichnissen aus. Dort sollten Änderungen an Quellkonfiguration und Images über den vorgesehenen Coolify-Deploymentweg erfolgen.

Ersetzen Sie php durch den Servicenamen Ihrer Compose-Datei und arbeiten Sie im richtigen Projektverzeichnis.

Anwendung wird aus einem Dockerfile gebaut

Aktualisieren Sie zuerst das Dockerfile auf das reparierte Basisimage. Danach:

docker compose build --pull --no-cache php docker compose up -d --no-deps --force-recreate php docker compose exec php php -v

Der Compose-Buildbefehl kann mit --pull das Basisimage prüfen und mit --no-cache den Build-Cache umgehen.

Anwendung verwendet ein fertiges Image

Ändern Sie zuerst die Image-Referenz auf einen nachweislich reparierten Tag oder Digest. Danach:

docker compose pull php docker compose up -d --no-deps --force-recreate php docker compose exec php php -v

Pull allein tauscht keinen laufenden Container aus. Erst das Neuerstellen übernimmt das neue Image. Siehe Compose pull und Compose up.

Prüfen und erneuern Sie zusätzlich eigene Worker- und Scheduler-Services. --no-deps aktualisiert diese nicht automatisch.

Schritt 6: Nachweisen, dass wirklich die reparierte Laufzeit läuft

Kontrollieren Sie nach dem Deployment nicht nur die Erfolgsmeldung, sondern den gestarteten Container:

docker exec "$APP_CONTAINER" php -v docker inspect \ --format 'image={{.Config.Image}} image_id={{.Image}} started={{.State.StartedAt}}' \ "$APP_CONTAINER" docker logs --since 10m --tail 100 "$APP_CONTAINER"

Falls Coolify beim Deployment einen neuen Containernamen vergeben hat, ermitteln Sie ihn vorher erneut mit docker ps und setzen APP_CONTAINER neu.

Gleichen Sie die Version beziehungsweise den dokumentierten Hersteller-Backport ab. Prüfen Sie die Web-Runtime und sämtliche Replikate. Testen Sie anschließend Login, Uploads, wichtige Geschäftsabläufe und Hintergrundjobs. Kontrollieren Sie Fehler- und Startprotokolle.

Ein Host-Update mit apt upgrade ändert kein PHP in unverändert laufenden Dockerimages. Auch docker restart verwendet weiterhin das bisherige Containerimage. Ein Composer-Update aktualisiert PHP-Abhängigkeiten der Anwendung, nicht das PHP-Binary.

Warum Konfigurationstricks das Update nicht ersetzen

Die PHP-Advisories beschreiben Teilmaßnahmen, aber keine vollständige Ersatzlösung für das Update. Insbesondere schützt session.upload_progress.enabled = 0 nicht gegen sämtliche Varianten.

Für bestätigte Session-Angriffspfade muss diese Einstellung vor dem Request-Parsing wirksam sein; alle Worker müssen neu starten. Das PHP-Team warnt ausdrücklich davor, sich dafür auf ini_set() oder auf FPM-.user.ini zu verlassen. Advisory zu veralteten globalen Zuständen

Auch eine WAF-Regel oder eine geänderte Speichergrenze ist kein Nachweis, dass die ungepatchte Runtime sicher ist. Konzentrieren Sie die Wiederfreigabe auf ein repariertes Image und die Prüfung der tatsächlich laufenden Prozesse.

Bei Anzeichen einer bereits erfolgten Kompromittierung reicht Patchen allein nicht aus: Die betroffenen Systeme und dort verfügbaren Zugangsdaten müssen zusätzlich im Rahmen einer Vorfallsanalyse behandelt werden.

Unterstützung bei PHP- und Coolify-Updates

OnLouis unterstützt Sie bei der Bestandsaufnahme, beim Update Ihrer Laufzeiten und beim erneuten Deployment Ihrer Anwendungen. Als Coolify Agentur und Laravel Agentur begleiten wir auch bestehende Projekte und stimmen Wartungsfenster und Funktionsprüfungen mit Ihnen ab.

Coolify- und PHP-Projekt besprechen