Zum Inhalt springen

PHP2Shell WordPress, Docker, Coolify und Homeserver jetzt prüfen und absichern

Inhaltsverzeichnis

PHP2Shell: WordPress, Docker, Coolify und Homeserver jetzt prüfen und absichern

Seit dem 21. Oktober 2026 gibt es eine ungewöhnlich ernste Sicherheitswarnung für PHP-Systeme. Unter dem Namen PHP2Shell werden die beiden kritischen Sicherheitslücken CVE-2026-109618 und CVE-2026-109619 zusammengefasst.

Das Problem betrifft nicht nur selbst programmierte PHP-Anwendungen. Auch Systeme wie WordPress, Nextcloud, Joomla oder Drupal können betroffen sein, weil die Schwachstellen im PHP-Kern selbst liegen.

Gerade für Betreiber von WordPress-Webseiten, Docker-Servern, Coolify-Installationen, Homelabs und Homeservern ist das wichtig. Ein automatischer Docker-Container, eine schicke Verwaltungsoberfläche oder ein aktuelles WordPress-Plugin schützt nicht davor, wenn darunter weiterhin eine verwundbare PHP-Version läuft.

Die gute Nachricht: Es gibt Sicherheitsupdates.

Die schlechte Nachricht: Man muss sie tatsächlich installieren. Docker und WordPress entwickeln bisher leider noch keine Fähigkeit, Sicherheitsupdates allein durch gutes Zureden einzuspielen.

Kurzfassung: Was Du jetzt tun solltest

Wenn auf Deinem Server PHP eingesetzt wird:

  1. Prüfe die tatsächlich verwendete PHP-Version.
  2. Aktualisiere PHP beziehungsweise das verwendete Container-Image.
  3. Starte PHP-FPM, Apache oder den betreffenden Container anschließend neu.
  4. Kontrolliere danach erneut die PHP-Version.
  5. Prüfe Webserver- und PHP-Logs auf Auffälligkeiten.
  6. Kontrolliere bei Docker und Coolify, ob wirklich ein neues Image verwendet wird.
  7. Prüfe insbesondere WordPress-, Nextcloud-, Joomla- und Drupal-Container.
  8. Gehe bei bereits auffälligen Systemen nicht davon aus, dass ein nachträgliches Update eine mögliche Kompromittierung beseitigt.

Als korrigierte PHP-Versionen gelten:

PHP-ZweigKorrigierte Version
PHP 8.58.5.12 oder neuer
PHP 8.48.4.27 oder neuer
PHP 8.38.3.36 oder neuer
PHP 8.28.2.35 oder neuer

PHP 8.1 und ältere Zweige werden vom PHP-Projekt nicht mehr regulär mit entsprechenden Sicherheitsupdates versorgt. Bei Distributionen mit verlängertem Support können allerdings zurückportierte Sicherheitskorrekturen vorhanden sein.

Deshalb gilt insbesondere bei Debian, Ubuntu, Red Hat und ähnlichen Distributionen:

Nicht ausschließlich auf die angezeigte PHP-Upstream-Versionsnummer verlassen. Prüfe auch das Security Advisory beziehungsweise Changelog Deiner Distribution.

Was ist PHP2Shell?

PHP2Shell ist die gebräuchliche Bezeichnung für zwei Sicherheitslücken im Kern von PHP:

  • CVE-2026-109618
  • CVE-2026-109619

Beide Sicherheitslücken wurden mit einem CVSS-v4.0-Wert von 9,2 bewertet.

Unter bestimmten Voraussetzungen können Angreifer die Fehler aus der Ferne ausnutzen, ohne sich vorher am betroffenen System anmelden zu müssen.

Das mögliche Ergebnis ist eine Remote Code Execution, kurz RCE.

Remote Code Execution bedeutet, dass fremder Programmcode auf dem betroffenen Server ausgeführt werden kann. Bei erfolgreicher Ausnutzung ist damit nicht nur eine einzelne Webseite gefährdet.

Abhängig von den Rechten des PHP-Prozesses können beispielsweise:

  • Dateien gelesen oder verändert werden,
  • Zugangsdaten und Secrets ausgelesen werden,
  • Webseiten manipuliert werden,
  • weitere Schadprogramme installiert werden,
  • Webshells hinterlegt werden,
  • Datenbanken angegriffen werden,
  • andere Dienste des Servers erreichbar werden.

Wie weit ein erfolgreicher Angriff kommt, hängt anschließend stark von der Konfiguration und den Berechtigungen des Servers ab.

CVE-2026-109618 und CVE-2026-109619 erklärt

Die Schwachstellen befinden sich nicht in WordPress oder einem bestimmten Plugin.

Sie liegen im PHP-Core selbst.

Bei CVE-2026-109618 können Fehler beim Umgang mit Speicher und insbesondere Out-of-Memory-Situationen dazu führen, dass PHP intern mit nur teilweise initialisierten Daten weiterarbeitet beziehungsweise diese bei der Bereinigung falsch behandelt.

Bei CVE-2026-109619 kann interner Zustand eines vorherigen Requests bestehen bleiben, obwohl der dazugehörige Speicher bereits freigegeben wurde. Ein späterer Request desselben PHP-Workers kann diesen veralteten Zustand verwenden.

Das sind sogenannte Memory-Safety-Probleme.

Genau deshalb ist PHP2Shell so ungewöhnlich gefährlich: Die Schwachstelle befindet sich eine Ebene unterhalb vieler Anwendungen.

Es ist deshalb keine Voraussetzung, dass eine bestimmte WordPress-Version oder ein bestimmtes Plugin installiert ist.

Ist WordPress von PHP2Shell betroffen?

WordPress kann betroffen sein.

Die Ursache liegt allerdings nicht in WordPress selbst.

WordPress wird in PHP ausgeführt. Läuft WordPress auf einer verwundbaren PHP-Version, muss die verwendete PHP-Runtime aktualisiert werden.

Ein Update von:

  • WordPress Core,
  • Themes,
  • Plugins,

behebt PHP2Shell nicht, wenn darunter weiterhin eine verwundbare PHP-Version läuft.

Das ist besonders bei Managed Hosting und fertigen Docker-Containern wichtig.

Im WordPress-Backend kannst Du beispielsweise unter:

Werkzeuge → Website-Zustand → Bericht → Server

nachsehen, welche PHP-Version WordPress meldet.

Bei vollständigem Zugriff auf den Server sollte die Version zusätzlich direkt überprüft werden.

Beispielsweise:

php -v

oder:

php -r 'echo PHP_VERSION, PHP_EOL;'

Dabei gibt es allerdings einen wichtigen Haken.

php -v kann die falsche PHP-Version anzeigen

Ein Server kann mehrere PHP-Versionen gleichzeitig installiert haben.

Der Befehl:

php -v

zeigt normalerweise die PHP-Version der Kommandozeile.

Apache oder Nginx können trotzdem eine andere PHP-Version über PHP-FPM verwenden.

Bei Docker wird die Sache noch interessanter, weil das PHP innerhalb des Containers überhaupt nichts mit dem PHP des Docker-Hosts zu tun haben muss.

Deshalb muss immer die PHP-Version überprüft werden, die tatsächlich die Webseite verarbeitet.

WordPress in Docker: PHP2Shell richtig prüfen

Das offizielle WordPress-Docker-Image wird in verschiedenen Varianten angeboten, darunter:

  • Apache + PHP
  • PHP-FPM
  • PHP-FPM auf Alpine Linux

Beispielsweise existieren Tags wie:

wordpress:php8.3-apache
wordpress:php8.4-apache
wordpress:php8.5-fpm
wordpress:php8.5-fpm-alpine

Wenn WordPress in Docker läuft, bringt Dir ein:

php -v

auf dem Docker-Host wenig.

Du musst PHP innerhalb des Containers überprüfen.

Zuerst die laufenden Container anzeigen:

docker ps

Dann beispielsweise:

docker exec -it CONTAINERNAME php -v

oder:

docker exec CONTAINERNAME php -r 'echo PHP_VERSION, PHP_EOL;'

Ersetze CONTAINERNAME durch den Namen Deines WordPress-Containers.

Beispiel:

docker exec wordpress php -v

Wenn dort beispielsweise eine verwundbare PHP-Version angezeigt wird, reicht ein Neustart des Containers nicht.

Warum docker restart kein Sicherheitsupdate installiert

Das wird regelmäßig verwechselt.

docker restart wordpress

startet lediglich denselben Container mit demselben Image neu.

Dadurch wird kein aktualisiertes Image aus Docker Hub geladen.

Bei Docker Compose solltest Du normalerweise zuerst ein neues Image herunterladen:

docker compose pull

und anschließend die Container anhand dieses Images neu erstellen:

docker compose up -d

Falls Du nur einen bestimmten Dienst aktualisieren möchtest, kann beispielsweise verwendet werden:

docker compose pull wordpress
docker compose up -d wordpress

Danach erneut kontrollieren:

docker exec wordpress php -v

Nur weil das Update ohne Fehlermeldung durchgelaufen ist, solltest Du nicht automatisch davon ausgehen, dass PHP wirklich aktualisiert wurde.

Prüfen ist schneller als später herauszufinden, dass ein seit drei Jahren festgepinntes Image erstaunlicherweise seit drei Jahren festgepinnt war.

Docker-Tags: latest ist nicht automatisch aktuell

Docker-Tags führen regelmäßig zu Missverständnissen.

Ein Tag wie:

wordpress:latest

ist lediglich eine Referenz auf ein Image.

Wenn dieses Image im Registry aktualisiert wird, läuft Dein bereits gestarteter Container nicht plötzlich mit dem neuen Image weiter.

Das neue Image muss heruntergeladen und ein neuer Container daraus erstellt werden.

Gleiches gilt beispielsweise für:

wordpress:php8.4-apache

Ein neuer Build kann weiterhin denselben Tag besitzen.

Das bedeutet:

docker compose pull
docker compose up -d

ist bei veränderlichen Tags wichtig.

Docker-Digest: sicher reproduzierbar, aber Updates passieren nicht automatisch

Noch eindeutiger ist ein festgelegter Image-Digest:

image@sha256:...

Ein SHA-256-Digest identifiziert ein konkretes Image.

Das hat einen großen Vorteil:

Du weißt exakt, welches Image eingesetzt wird.

Ein später verändertes latest kann Deine Produktion nicht überraschend verändern.

Der Nachteil ist für Sicherheitsupdates ebenso offensichtlich:

Ein festgepinntes Image bleibt absichtlich festgepinnt.

Wird eine PHP-Sicherheitslücke bekannt und Dein Image enthält eine verwundbare PHP-Version, musst Du den Digest bewusst auf ein korrigiertes Image aktualisieren.

PHP2Shell und Coolify

Coolify vereinfacht das Bereitstellen von:

  • Docker-Images,
  • Docker-Compose-Anwendungen,
  • Dockerfiles,
  • Git-Projekten,
  • selbst gebauten Anwendungen.

Das ändert nichts an der darunterliegenden Sicherheitslage.

Am Ende läuft eine Anwendung in einem Docker-Image.

Deshalb gilt auch bei Coolify:

Entscheidend ist die PHP-Version innerhalb des tatsächlich laufenden Containers.

Coolify mit Docker-Image und mutablem Tag

Wenn beispielsweise ein Image mit:

wordpress:latest

oder:

wordpress:php8.4-apache

eingetragen wurde, handelt es sich um einen veränderlichen Tag.

Bei einem Redeploy kann Coolify das aktuell im Registry veröffentlichte Image dieses Tags herunterladen und daraus einen neuen Container erstellen.

Anschließend muss trotzdem kontrolliert werden, welche PHP-Version tatsächlich läuft.

Coolify mit SHA-256-Digest

Wurde das Image dagegen anhand eines festen SHA-256-Digests eingebunden, zeigt dieser weiterhin exakt auf das zuvor ausgewählte Image.

Ein Redeploy macht daraus nicht automatisch eine gepatchte Version.

In diesem Fall muss zunächst ein neuer Image-Digest ausgewählt werden.

Docker Compose in Coolify

Bei Docker-Compose-Anwendungen verwendet Coolify die Compose-Definition und lässt Docker die benötigten Images erstellen oder laden und anschließend den Stack abgleichen.

Wichtig ist deshalb auch hier:

  • Image aktualisieren,
  • Container neu erstellen lassen,
  • Anwendung testen,
  • PHP-Version im neuen Container prüfen.

Coolify unterstützt für verschiedene Deployment-Arten Rolling Updates. Bei klassischen Docker-Compose-Anwendungen kommt dagegen der Compose-eigene Aktualisierungsmechanismus zum Einsatz.

Health Checks aktivieren

Ein weiterer sinnvoller Schutz sind Health Checks.

Ein Sicherheitsupdate bringt wenig Freude, wenn anschließend der neue Container mit einem Konfigurationsfehler startet und die Anwendung nicht funktioniert.

Bei unterstützten Coolify-Deployments kann ein Health Check dafür sorgen, dass ein neuer Container zunächst seine Funktionsfähigkeit beweisen muss, bevor der bisherige ersetzt wird.

Health Checks verhindern PHP2Shell nicht.

Sie machen Sicherheitsupdates aber wesentlich kontrollierbarer.

Nextcloud und PHP2Shell

Nextcloud ist für PHP2Shell relevant.

Nextcloud basiert auf PHP.

Auch hier gibt es verschiedene offizielle Container-Varianten.

Unter anderem:

  • Apache
  • PHP-FPM
  • PHP-FPM auf Alpine Linux

Bei der Apache-Variante befinden sich Nextcloud, PHP und Apache zusammen im entsprechenden Container.

Bei einer FPM-Variante befindet sich PHP-FPM im Nextcloud-Container und wird typischerweise über einen separaten Webserver oder Reverse Proxy angesprochen.

Die verwendete PHP-Version kannst Du beispielsweise so prüfen:

docker ps

anschließend:

docker exec NEXTCLOUD_CONTAINER php -v

Beispiel:

docker exec nextcloud php -v

Auch hier gilt:

Nur Nextcloud selbst innerhalb der Weboberfläche zu aktualisieren reicht für eine PHP-Core-Sicherheitslücke nicht aus.

Wenn PHP Bestandteil des Container-Images ist, benötigst Du ein aktualisiertes Image.

Was ist mit Nextcloud AIO?

Bei Nextcloud All-in-One, kurz AIO, werden mehrere Container gemeinsam verwaltet.

In solchen Installationen sollte nicht eigenmächtig irgendein einzelner interner Container mit einem beliebigen Image ersetzt werden.

Verwende den von Nextcloud vorgesehenen Update-Prozess für AIO und kontrolliere danach den laufenden PHP-Container.

Der grundsätzliche Unterschied ist wichtig:

Bei einer selbst erstellten Compose-Installation verwaltest Du die Images selbst.

Bei einer Appliance-ähnlichen Container-Lösung solltest Du dem vorgesehenen Updatepfad des Herstellers folgen.

Ist Paperless-ngx von PHP2Shell betroffen?

Hier muss sauber unterschieden werden.

Paperless-ngx selbst ist keine PHP-Anwendung.

Paperless-ngx basiert auf Python und Django.

Die PHP2Shell-Schwachstellen CVE-2026-109618 und CVE-2026-109619 betreffen Paperless-ngx deshalb nicht direkt.

Das bedeutet allerdings nicht, dass ein Homeserver mit Paperless automatisch nichts zu tun hat.

Auf demselben Docker-Host können gleichzeitig beispielsweise laufen:

paperless-ngx
Nextcloud
WordPress
Vaultwarden
Immich
Home Assistant
MariaDB
Redis
Traefik
Nginx Proxy Manager

Von PHP2Shell betroffen ist nicht automatisch der ganze Server, sondern zunächst Software, die eine verwundbare PHP-Runtime verwendet.

Genau deshalb ist eine Inventarisierung der Container sinnvoll.

Welche Homeserver-Anwendungen sollte ich prüfen?

Eine grobe Orientierung:

AnwendungPHP2Shell grundsätzlich relevant?Warum?
WordPressJaPHP-Anwendung
NextcloudJaPHP-Anwendung
JoomlaJaPHP-Anwendung
DrupalJaPHP-Anwendung
MediaWikiJaPHP-Anwendung
phpMyAdminJaPHP-Anwendung
MatomoJaPHP-Anwendung
FreshRSSJaPHP-Anwendung
Paperless-ngxNein, nicht direktPython/Django
Home AssistantNein, nicht direktPython
ImmichNein, nicht direktkein PHP
VaultwardenNein, nicht direktRust

Diese Tabelle sagt lediglich aus, ob PHP2Shell für die eigentliche Anwendung technisch relevant ist.

Sie sagt nichts darüber aus, ob die jeweilige Software frei von anderen Sicherheitslücken ist.

Alle Container nach PHP durchsuchen

Auf einem größeren Homeserver kann es sinnvoll sein, zunächst einen Überblick über die laufenden Container zu bekommen:

docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}"

Danach können verdächtige beziehungsweise bekannte PHP-Anwendungen einzeln geprüft werden.

Bei einem Container, von dem Du nicht weißt, ob PHP enthalten ist:

docker exec CONTAINER sh -c 'php -v 2>/dev/null || echo "PHP nicht gefunden"'

Das funktioniert allerdings nur, wenn der Container eine Shell enthält.

Minimalistische Container können ohne sh ausgeliefert werden.

Ein fehlgeschlagener Befehl beweist deshalb nicht, dass kein PHP vorhanden ist.

Image überprüfen statt nur den Container

Du solltest außerdem dokumentieren, aus welchem Image ein Container entstanden ist.

Beispielsweise:

docker inspect CONTAINERNAME

Kompakter:

docker inspect --format='{{.Config.Image}}' CONTAINERNAME

Damit siehst Du beispielsweise:

wordpress:php8.3-apache

Anschließend kannst Du prüfen, ob dafür inzwischen ein neues Image verfügbar ist.

Sind automatische Container-Updates sinnvoll?

Werkzeuge wie:

  • Watchtower,
  • Renovate,
  • Dependabot,
  • CI/CD-Pipelines,
  • Coolify-Automatisierungen,

können beim Aktualisieren beziehungsweise Erkennen neuer Images helfen.

Vollautomatische Updates haben allerdings Vor- und Nachteile.

Vorteile

Sicherheitsupdates kommen schneller an

Gerade bei kritischen Sicherheitsproblemen kann eine kurze Zeit bis zum Patch entscheidend sein.

Weniger vergessene Systeme

In einem Homelab mit 30 oder 50 Containern verliert man irgendwann den Überblick.

Menschen sind erstaunlich gut darin, einen alten Container jahrelang laufen zu lassen, solange die Webseite noch antwortet.

Reproduzierbare Deployments

Mit Compose-Dateien, Versionskontrolle und automatischen Builds kann nachvollzogen werden, was wann eingesetzt wurde.

Nachteile

Ein Update kann die Anwendung beschädigen

Neue Images können:

  • Breaking Changes enthalten,
  • Datenbankmigrationen verlangen,
  • Konfigurationen verändern,
  • Plugins inkompatibel machen.

latest kann Überraschungen bringen

Wer ausschließlich latest verwendet, delegiert die Entscheidung über den konkreten Softwarestand an den Image-Herausgeber.

Automatische Updates ersetzen keine Tests

Ein Container, der läuft, ist nicht automatisch ein Container, dessen Anwendung funktioniert.

Ein sinnvoller Mittelweg für Homeserver

Für öffentlich erreichbare Anwendungen ist ein kontrollierter Updateprozess sinnvoll:

  1. Version beziehungsweise Image dokumentieren.
  2. Backup erstellen.
  3. Neues Image herunterladen.
  4. Changelog lesen.
  5. Container aktualisieren.
  6. Health Check beziehungsweise Funktionstest durchführen.
  7. PHP-Version prüfen.
  8. Logs kontrollieren.
  9. Altes Image erst danach entfernen.

Bei besonders wichtigen Diensten sollte außerdem getestet werden, ob das Backup tatsächlich wiederhergestellt werden kann.

Ein Backup, das noch nie wiederhergestellt wurde, ist eher eine Hoffnung mit Dateiendung als eine Backupstrategie.

PHP2Shell auf einem normalen Linux-Server prüfen

Bei einer klassischen Installation ohne Docker:

php -v

Zusätzlich kannst Du nach PHP-FPM-Diensten suchen:

systemctl list-units --type=service | grep php

Je nach Distribution können beispielsweise Dienste wie diese existieren:

php8.2-fpm.service
php8.3-fpm.service
php8.4-fpm.service
php8.5-fpm.service

Bei einem laufenden PHP-FPM kannst Du beispielsweise prüfen:

php-fpm8.4 -v

Der genaue Befehlsname unterscheidet sich zwischen Distributionen.

Debian und Ubuntu

Auf Debian- beziehungsweise Ubuntu-basierten Systemen zunächst:

sudo apt update
sudo apt upgrade

Anschließend überprüfen, welche PHP-Pakete installiert sind:

dpkg -l | grep php

Bei PHP-FPM anschließend den betreffenden Dienst neu starten, beispielsweise:

sudo systemctl restart php8.4-fpm

Wenn Apache mit PHP-Modul verwendet wird:

sudo systemctl restart apache2

Danach die Version und den Zustand erneut überprüfen.

Bei von Debian oder Ubuntu zurückportierten Security-Patches kann die Versionsnummer von der offiziellen PHP-Upstream-Version abweichen.

Deshalb zusätzlich die Security-Advisories des Distributors beachten.

Fedora, RHEL und verwandte Systeme

Auf Fedora:

sudo dnf upgrade

Auf aktuellen Systemen kann je nach DNF-Version ebenfalls verwendet werden:

sudo dnf update

Anschließend die installierte PHP-Version kontrollieren:

php -v

und gegebenenfalls PHP-FPM neu starten:

sudo systemctl restart php-fpm

Bei RHEL, AlmaLinux, Rocky Linux und anderen Enterprise-Distributionen können Security-Fixes zurückportiert werden.

Auch hier ist deshalb das jeweilige Security Advisory maßgeblich.

PHP2Shell und Reverse Proxies

Viele Homelabs setzen heute einen Reverse Proxy ein, beispielsweise:

  • Traefik,
  • Nginx,
  • Caddy,
  • Nginx Proxy Manager,
  • HAProxy,
  • Cloudflare.

Ein Reverse Proxy kann die Angriffsfläche verkleinern und bestimmte Angriffe filtern.

Er ersetzt das PHP-Sicherheitsupdate aber nicht.

Eine Web Application Firewall kann bekannte Angriffsmuster blockieren. Sie kann damit eine sinnvolle zusätzliche Verteidigung darstellen.

PHP selbst erklärt allerdings ausdrücklich, dass es keine vollständige Mitigation gibt, die das Update ersetzt.

Deshalb gilt:

WAF zusätzlich zum Patch, nicht statt des Patches.

Warum Netzwerksegmentierung bei Homelabs wichtig ist

Ein WordPress-Container sollte im Idealfall nicht uneingeschränkten Zugriff auf jedes andere Gerät im Heimnetz besitzen.

Das Prinzip lautet:

So wenig Zugriff wie nötig.

Beispielsweise benötigt ein öffentlich erreichbares WordPress normalerweise keinen direkten Zugriff auf:

  • Home Assistant,
  • NAS-Management,
  • Proxmox-Webinterface,
  • Routeradministration,
  • private SMB-Freigaben,
  • Überwachungskameras.

Containerisierung ist nur dann eine brauchbare Sicherheitsgrenze, wenn Berechtigungen und Netzwerke sinnvoll konfiguriert wurden.

Docker Socket nicht unnötig in Container einbinden

Besonders gefährlich sind Container mit Zugriff auf:

/var/run/docker.sock

Ein Container mit weitreichendem Zugriff auf den Docker Socket kann abhängig von der Konfiguration praktisch Kontrolle über den Docker-Host erlangen.

Deshalb:

  • Docker Socket nur einbinden, wenn zwingend erforderlich,
  • möglichst Proxy beziehungsweise eingeschränkte APIs verwenden,
  • öffentlich erreichbaren Anwendungen keinen Docker-Socket-Zugriff geben.

Ein kompromittierter WordPress-Container ist unangenehm.

Ein kompromittierter WordPress-Container mit vollständigem Docker-Socket-Zugriff ist eine Einladung, gleich den Rest des Servers mit einzusammeln.

Container möglichst nicht privilegiert betreiben

Vermeide nach Möglichkeit:

privileged: true

Prüfe außerdem:

  • Linux Capabilities,
  • Host-Mounts,
  • Netzwerkzugriff,
  • Benutzerrechte,
  • Secrets,
  • beschreibbare Verzeichnisse.

Je weniger Möglichkeiten ein kompromittierter Container besitzt, desto schwieriger ist der Sprung auf andere Systeme.

Read-only Container können zusätzlichen Schutz bieten

Wo die Anwendung es erlaubt, kann ein Container-Dateisystem teilweise schreibgeschützt betrieben werden.

Das offizielle WordPress-Docker-Image dokumentiert beispielsweise Möglichkeiten, einen angepassten Container mit einem read-only-Dateisystem zu betreiben und nur notwendige Bereiche beschreibbar einzubinden.

Das verhindert PHP2Shell nicht.

Es kann aber den Schaden begrenzen, wenn ein Angreifer versucht, dauerhaft Dateien im Container abzulegen.

Persistente WordPress-Inhalte wie Uploads benötigen selbstverständlich weiterhin Schreibzugriff.

Nach PHP2Shell-Angriffen suchen

Ein PHP-Update schützt vor einer erneuten Ausnutzung der bekannten Schwachstellen.

Es beantwortet aber nicht die Frage:

Wurde mein Server vorher bereits angegriffen?

Bei öffentlich erreichbaren verwundbaren Systemen solltest Du deshalb zumindest grundlegende Kontrollen durchführen.

Webserver-Logs prüfen

Je nach Server beispielsweise:

/var/log/apache2/
/var/log/nginx/

Bei Docker:

docker logs CONTAINERNAME

Bei Compose:

docker compose logs

Achte auf:

  • ungewöhnlich viele HTTP-500-Fehler,
  • verdächtige POST-Anfragen,
  • ungewöhnliche multipart/form-data-Requests,
  • wiederholte PHP-Abstürze,
  • Out-of-Memory-Fehler,
  • unerwartete Worker-Neustarts.

Ein einzelner HTTP-500-Fehler beweist selbstverständlich keinen Angriff.

Es geht um ungewöhnliche Muster und zeitliche Zusammenhänge.

WordPress-Dateien kontrollieren

Bei WordPress sollte außerdem kontrolliert werden, ob unerwartete PHP-Dateien vorhanden sind.

Interessant sind insbesondere:

wp-content/uploads/
wp-content/plugins/
wp-content/themes/

Im Upload-Verzeichnis sollten normalerweise keine frei ausführbaren unbekannten PHP-Dateien herumliegen.

Prüfe außerdem Dateiänderungszeiten und unbekannte Dateien.

Mit WP-CLI lassen sich beispielsweise Checksummen des WordPress-Cores kontrollieren:

wp core verify-checksums

Dadurch werden nicht alle Plugins und Themes überprüft, aber Manipulationen am WordPress-Core können erkannt werden.

Prozesse im PHP-Container prüfen

Interessant können ebenfalls ungewöhnliche Child-Prozesse sein.

Beispielsweise:

docker top CONTAINERNAME

oder innerhalb eines geeigneten Containers:

ps aux

PHP beziehungsweise der Webserver sollte nicht ohne nachvollziehbaren Grund Programme wie Shells oder Downloadwerkzeuge starten.

Auffälligkeiten könnten beispielsweise Prozesse wie:

sh
bash
curl
wget
nc
python
perl

sein, wenn diese durch den Webserverprozess gestartet wurden und dafür kein legitimer Grund existiert.

Das bloße Vorhandensein dieser Programme ist kein Beweis für einen Angriff.

Cronjobs kontrollieren

Auf klassischen Linux-Systemen:

crontab -l

zusätzlich beispielsweise:

sudo ls -la /etc/cron.*

Bei Docker sollte außerdem kontrolliert werden, ob neue:

  • Container,
  • Images,
  • Volumes,
  • Netzwerke,

aufgetaucht sind.

Zum Beispiel:

docker ps -a
docker images
docker volume ls
docker network ls

Was tun bei konkretem Kompromittierungsverdacht?

Wenn Hinweise auf eine erfolgreiche Ausnutzung vorhanden sind, solltest Du nicht einfach ein PHP-Update installieren und anschließend so tun, als sei damit alles erledigt.

Sinnvoll ist dann:

  1. System möglichst vom öffentlichen Netz isolieren.
  2. Logs und relevante Daten sichern.
  3. Keine Spuren unnötig verändern.
  4. Unbekannte Prozesse und Dateien untersuchen.
  5. Zugangsdaten und Secrets als möglicherweise kompromittiert betrachten.
  6. API-Schlüssel, Datenbankpasswörter und Tokens ersetzen.
  7. Bei Bedarf aus einem nachweislich sauberen Backup neu aufsetzen.
  8. Erst danach wieder öffentlich freigeben.

Besonders beachten:

  • WordPress-Salts,
  • Datenbankkennwörter,
  • SSH-Schlüssel,
  • Cloudflare-Tokens,
  • SMTP-Zugangsdaten,
  • API-Keys,
  • Docker Registry Credentials,
  • Coolify-Secrets.

PHP2Shell und Shared Hosting

Nicht jeder hat Root-Zugriff auf seinen Server.

Bei Shared Hosting solltest Du im Kundenmenü nachsehen, welche PHP-Version für die jeweilige Domain aktiviert ist.

Wenn dort beispielsweise auswählbar sind:

PHP 8.2
PHP 8.3
PHP 8.4
PHP 8.5

reicht die Hauptversion alleine noch nicht aus.

Entscheidend ist die tatsächlich installierte Patchversion beziehungsweise ob der Hoster den Sicherheitsfix zurückportiert hat.

Im Zweifel sollte der Hostinganbieter konkret gefragt werden:

Ist meine für die Domain eingesetzte PHP-Version gegen CVE-2026-109618 und CVE-2026-109619 gepatcht?

Das ist deutlich sinnvoller als lediglich zu fragen, ob „PHP aktuell“ sei.

Vorsicht mit phpinfo()

Eine häufige Möglichkeit zur PHP-Prüfung ist eine Datei wie:

<?php
phpinfo();

Sie zeigt sehr viele Informationen über die laufende PHP-Umgebung.

Das kann zur Diagnose nützlich sein.

Eine öffentlich erreichbare phpinfo()-Datei sollte anschließend allerdings sofort wieder entfernt werden, weil sie Angreifern wertvolle Informationen über die Serverkonfiguration liefern kann.

Wenn SSH-Zugriff oder das Hosting-Panel dieselbe Information liefern, ist das vorzuziehen.

Weiterführende technische Informationen zu PHP2Shell

Wer PHP2Shell technisch genauer verstehen möchte, findet auf IRC-Coding.de ausführliche Artikel zu den beiden CVEs, den betroffenen PHP-Versionen und den notwendigen Sicherheitsupdates.

Deutsch

Ausführliche technische Erklärung:

PHP2Shell: PHP-Sicherheitslücke CVE-2026-109618 und CVE-2026-109619

English

For English-speaking administrators and developers:

PHP2Shell: Critical PHP Vulnerability CVE-2026-109618 and CVE-2026-109619

Español

Para administradores y desarrolladores que buscan información sobre la vulnerabilidad crítica PHP2Shell, CVE-2026-109618, CVE-2026-109619, seguridad PHP, Remote Code Execution y actualizaciones de PHP:

PHP2Shell: vulnerabilidad crítica de PHP CVE-2026-109618 y CVE-2026-109619

Русский

Для администраторов и разработчиков, которым нужна техническая информация о PHP2Shell, критических уязвимостях CVE-2026-109618, CVE-2026-109619, безопасности PHP и удалённом выполнении кода:

PHP2Shell: критическая уязвимость PHP CVE-2026-109618 и CVE-2026-109619

PHP2Shell, künstliche Intelligenz und moderne Sicherheitsforschung

PHP2Shell ist auch aus einem anderen Grund interessant.

Moderne KI-Systeme spielten bei der Untersuchung der Schwachstellen und bei der Bewältigung sehr komplexer Exploit- und Debugging-Aufgaben eine Rolle.

Die Schwachstellen wurden nicht durch moderne KI oder Vibe Coding verursacht. Die zugrunde liegenden Fehler existierten bereits lange im PHP-Code.

KI verändert allerdings die Geschwindigkeit, mit der:

  • Quellcode untersucht,
  • komplexe Fehler verstanden,
  • Exploits analysiert,
  • Varianten getestet,
  • Patches überprüft

werden können.

Das gilt für Sicherheitsforscher und Verteidiger genauso wie potenziell für Angreifer.

Auf BotServ.de beschäftigen wir uns deshalb ausführlicher mit der Rolle künstlicher Intelligenz bei PHP2Shell und moderner Cybersecurity.

Deutsch

Mehr zu PHP2Shell, KI, Cybersecurity, AI Coding und Sicherheitsrisiken durch automatisierte Codeanalyse:

PHP2Shell: CVE-2026-109618, CVE-2026-109619 und die Rolle der KI

English

For readers interested in PHP2Shell, AI security, artificial intelligence, cybersecurity, PHP Remote Code Execution and AI-assisted vulnerability research:

PHP2Shell: Critical PHP vulnerability and the role of AI

Español

Para lectores interesados en PHP2Shell, inteligencia artificial, ciberseguridad, vulnerabilidades PHP, seguridad del código generado por IA y Remote Code Execution:

PHP2Shell: vulnerabilidad crítica de PHP y el papel de la inteligencia artificial

Русский

Для читателей, интересующихся темами PHP2Shell, искусственный интеллект, кибербезопасность, уязвимости PHP, безопасность ИИ и удалённое выполнение кода:

PHP2Shell: критическая уязвимость PHP и роль искусственного интеллекта

PHP2Shell Checkliste für WordPress und Homeserver

WordPress ohne Docker

  • PHP-Version prüfen
  • Hosting-Security-Advisory prüfen
  • PHP aktualisieren
  • PHP-FPM beziehungsweise Apache neu starten
  • WordPress-Core aktualisieren
  • Plugins aktualisieren
  • Themes aktualisieren
  • Logs kontrollieren
  • WordPress-Dateien kontrollieren

WordPress mit Docker

  • laufendes Image identifizieren
  • PHP innerhalb des Containers prüfen
  • neues Image pullen
  • Container neu erstellen
  • neue PHP-Version kontrollieren
  • Logs kontrollieren
  • Volumes und WordPress-Dateien prüfen

Coolify

  • eingesetztes Image beziehungsweise Buildverfahren prüfen
  • Tag oder Digest kontrollieren
  • neues Image beziehungsweise neuen Build verwenden
  • Redeploy durchführen
  • Health Check kontrollieren
  • PHP innerhalb des neuen Containers prüfen
  • Deployment-Logs kontrollieren

Nextcloud

  • verwendeten Nextcloud-Container identifizieren
  • PHP-Version innerhalb des Containers kontrollieren
  • offiziellen Updatepfad verwenden
  • aktuelles Image einsetzen
  • Container neu erstellen
  • PHP-Version erneut prüfen

Paperless-ngx

  • PHP2Shell betrifft Paperless-ngx selbst nicht direkt
  • trotzdem Host auf weitere PHP-basierte Container prüfen

Häufige Fragen zu PHP2Shell

Was ist PHP2Shell?

PHP2Shell ist die Bezeichnung für zwei kritische PHP-Sicherheitslücken, CVE-2026-109618 und CVE-2026-109619. Unter bestimmten Bedingungen können sie unauthentifizierte Remote Code Execution ermöglichen.

Wie gefährlich ist PHP2Shell?

Beide Schwachstellen wurden mit CVSS 9,2 bewertet. Erfolgreiche Remote Code Execution kann einem Angreifer die Ausführung eigenen Codes im Kontext des PHP-Prozesses ermöglichen.

Ist WordPress betroffen?

WordPress kann betroffen sein, wenn es mit einer verwundbaren PHP-Version betrieben wird. Der Fehler befindet sich nicht im WordPress-Core.

Reicht ein WordPress-Update?

Nein. PHP muss selbst gepatcht werden.

Welche PHP-Versionen sind gegen PHP2Shell korrigiert?

Die vom PHP-Projekt veröffentlichten korrigierten Versionen sind:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

oder jeweils neuere Versionen.

Bei Linux-Distributionen können entsprechende Fixes zurückportiert worden sein.

Ist Nextcloud betroffen?

Nextcloud basiert auf PHP und kann deshalb auf einer verwundbaren PHP-Runtime betroffen sein.

Ist Paperless-ngx betroffen?

Paperless-ngx selbst basiert auf Python/Django und ist deshalb nicht direkt von den PHP2Shell-Schwachstellen betroffen.

Schützt Docker vor PHP2Shell?

Nein.

Docker isoliert Prozesse, beseitigt aber keine Schwachstellen in der Software innerhalb eines Containers.

Die Containerisierung kann den möglichen Schaden begrenzen, wenn Berechtigungen und Netzwerke korrekt konfiguriert sind.

Muss ich meinen Docker-Host aktualisieren?

Für PHP2Shell muss zunächst das PHP innerhalb des betroffenen Containers aktualisiert werden.

Unabhängig davon sollte selbstverständlich auch der Docker-Host regelmäßig Sicherheitsupdates erhalten.

Reicht docker restart?

Nein.

Ein Restart startet dasselbe Image erneut.

Du benötigst ein aktualisiertes Image und musst daraus einen neuen Container erstellen.

Reicht docker compose pull?

Noch nicht.

docker compose pull lädt das neue Image.

Anschließend muss der laufende Container mit dem neuen Image ersetzt werden, beispielsweise über:

docker compose up -d

Ist latest automatisch aktuell?

Nein.

latest ist nur ein Docker-Tag.

Ein bereits laufender Container aktualisiert sich nicht automatisch, wenn das Image hinter diesem Tag verändert wird.

Bin ich mit Cloudflare geschützt?

Eine Web Application Firewall kann Angriffe abwehren oder erschweren.

Sie ersetzt das PHP-Sicherheitsupdate nicht.

Muss ich nach dem PHP-Update noch etwas tun?

Ja.

Kontrolliere mindestens:

  • tatsächlich laufende PHP-Version,
  • PHP- beziehungsweise Webserver-Neustart,
  • Webserverlogs,
  • PHP-Logs,
  • unbekannte Dateien,
  • ungewöhnliche Prozesse.

Bei konkretem Kompromittierungsverdacht sind weitergehende Incident-Response-Maßnahmen erforderlich.

Fazit

PHP2Shell ist keine WordPress-Sicherheitslücke und auch kein Docker-Problem.

Das macht die Situation allerdings nicht harmloser.

Die beiden Schwachstellen befinden sich im PHP-Core. Deshalb können sehr unterschiedliche Anwendungen betroffen sein, solange sie auf einer verwundbaren PHP-Runtime laufen.

Für klassische Webseitenbetreiber bedeutet das:

PHP aktualisieren.

Für WordPress-Betreiber bedeutet es:

Nicht nur WordPress aktualisieren, sondern die darunterliegende PHP-Version kontrollieren.

Für Docker-Betreiber bedeutet es:

Nicht den Container neu starten, sondern ein korrigiertes Image beziehen und den Container daraus neu erstellen.

Für Coolify-Betreiber bedeutet es:

Image-Tag oder Digest, Deployment und tatsächlich laufende PHP-Version kontrollieren.

Für Homelab-Betreiber bedeutet es:

Inventarisieren, welche Container überhaupt PHP verwenden.

WordPress und Nextcloud gehören beispielsweise dazu. Paperless-ngx dagegen nicht.

Und unabhängig vom eingesetzten System gilt ein letzter wichtiger Punkt:

Ein heute installiertes Sicherheitsupdate beweist nicht, dass ein gestern verwundbarer öffentlich erreichbarer Server nicht bereits angegriffen wurde.

Wer ein betroffenes System öffentlich betrieben hat, sollte deshalb nicht nur patchen, sondern auch Logs, Dateien und Prozesse kontrollieren.

Schlagwörter: