PHP2Shell Lösung für eigene Infrastruktur: Patchen in VMs, Docker und Kubernetes

Ist eine selbst betriebene KI-Plattform von PHP2Shell betroffen?

Die gängigen Oberflächen für Unternehmens-KI basieren in der Regel nicht auf PHP: Open WebUI läuft auf Python, LibreChat und AnythingLLM auf Node.js. Die Plattform selbst ist daher meist nicht direkt verwundbar. In der Praxis steht sie aber selten allein. Auf denselben Hosts oder im selben Netzsegment laufen oft PHP-Anwendungen, etwa:

• Nextcloud als Dokumentenablage, aus der eine RAG-Wissensdatenbank gespeist wird
• Intranet, Wiki oder Ticketsystem auf Basis von PHP
• Monitoring- und Verwaltungsoberflächen wie phpMyAdmin oder Hosting-Panels
• Websites oder Portale, die über Schnittstellen auf die KI zugreifen

Eine kompromittierte PHP-Anwendung im selben Netz ist ein Sprungbrett zu Modellen, Dokumenten und API-Schlüsseln. Darum gehört PHP2Shell auch auf die Agenda von Teams, die „nur“ eine KI-Plattform betreiben.

Was passiert technisch bei PHP2Shell?

Das größte Risiko sieht das PHP-Team bei Apache mit mod_php: Dort löst eine einzige Anfrage den Angriff aus, bevor Anwendungscode läuft. Eine WAF vor der Anwendung oder Prüfungen im Framework greifen damit zu spät. Laut CERT-EU kursieren bereits erste Proof-of-Concepts, Cloudflare meldete erste Angriffe.

Wie finde ich alle PHP-Instanzen in meiner Infrastruktur?

Inventarisieren Sie vor dem Patchen. Übersehene Instanzen in Testumgebungen oder alten VMs sind das typische Einfallstor.

Auf Linux-Hosts

# Laufende PHP-Prozesse (FPM, mod_php via Apache, LiteSpeed, FrankenPHP)
ps -eo pid,user,comm,args | grep -Ei 'php|lsphp|frankenphp|apache2|httpd' | grep -v grep

# Lauschende Dienste mit PHP-Bezug
ss -ltnp | grep -Ei 'php|httpd|apache|lsws'

# Installierte Pakete
dpkg -l | grep -E '^ii\s+(libapache2-mod-)?php'   # Debian/Ubuntu
rpm -qa | grep -Ei '^php'                          # RHEL/AlmaLinux/Rocky

In Docker

# Alle laufenden Container mit Image
docker ps --format '{{.Names}}\t{{.Image}}'

# PHP-Version je Container (Container ohne PHP liefern einen Fehler)
for c in $(docker ps -q); do
  echo "$(docker inspect -f '{{.Name}}' "$c"): $(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null)"
done

In Kubernetes

# Alle Images im Cluster, nach PHP-Bezug filtern
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -Ei 'php|wordpress|nextcloud|drupal|magento|laravel'

Der Namensfilter findet nicht alles. Viele eigene Images basieren auf php:*, ohne es im Namen zu tragen. Prüfen Sie Dockerfiles in Ihren Repositories auf FROM php sowie auf Pakete wie php-fpm. Für Drittprodukte, die PHP intern nutzen, pflegt das niederländische NCSC eine Liste auf GitHub.

PHP2Shell Lösung: Patchen in VM, Docker und Kubernetes

1. Virtuelle Maschinen und Bare Metal

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade 'php*' 'libapache2-mod-php*'
# RHEL/AlmaLinux/Rocky
sudo dnf upgrade 'php*'

# Danach alle PHP-Prozesse neu starten
sudo systemctl restart 'php*-fpm.service'
sudo systemctl restart apache2   # bzw. httpd bei mod_php
sudo systemctl restart lsws      # LiteSpeed

Distributionen spielen den Fix oft als Backport ein, ohne die Upstream-Versionsnummer zu ändern. Nachweis über das Changelog:

apt changelog php8.3-fpm | grep -E 'CVE-2026-10961(8|9)'
rpm -q --changelog php-common | grep -E 'CVE-2026-10961(8|9)'

Wer das Repository rpms.remirepo.net nutzt: Laut PHP-Team gab es dort am Veröffentlichungstag keine Updates. Dann auf Distributionspakete wechseln oder selbst bauen.

2. Docker

Ein Neustart reicht nicht. Der Container läuft weiter mit dem PHP, das beim Bauen ins Image kam. Ziehen Sie das Basis-Image neu und bauen Sie alle abhängigen Images neu.

# Basis-Image prüfen
docker pull php:8.3-fpm
docker run --rm php:8.3-fpm php -r 'echo PHP_VERSION, PHP_EOL;'   # erwartet: 8.3.36

# Eigene Images ohne Cache neu bauen und ausrollen
docker compose build --pull --no-cache
docker compose up -d

Pinnen Sie Basis-Images idealerweise auf einen Digest und aktualisieren Sie diesen bewusst. So wissen Sie jederzeit, welche PHP-Version in Produktion läuft.

3. Kubernetes

# Neues Image-Tag setzen (Beispiel)
kubectl -n web set image deployment/portal php-fpm=registry.example.de/portal:2026-10-22-php8.3.36

# Oder bei unverändertem Tag mit imagePullPolicy: Always
kubectl -n web rollout restart deployment/portal
kubectl -n web rollout status deployment/portal

# Kontrolle im laufenden Pod
kubectl -n web exec deploy/portal -c php-fpm -- php -r 'echo PHP_VERSION;'

Vergessen Sie CronJobs, Jobs und StatefulSets nicht. Sie nutzen oft dieselben Images, werden aber nicht mit dem Deployment ausgerollt.

4. Veraltete PHP-Zweige

PHP 8.1 und älter bekommen kein offizielles Release. Das PHP-Team hat wegen der Schwere minimale Quellcode-Backports für 7.4, 8.0 und 8.1 veröffentlicht, einige Distributionen liefern eigene Backports. Für Produktivsysteme ist das eine Brücke, keine Lösung. PHP 8.2 endet am 31.12.2026.

Wie härte ich Webserver und PHP, bis alles gepatcht ist?

CERT-EU empfiehlt, internetfähige Anwendungen ohne Patch vom öffentlichen Netz zu trennen: hinter VPN, Zero-Trust-Proxy oder IP-Allowlist. Zusätzlich nennt das PHP-Projekt Härtungen, die einzelne bekannte Angriffswege blockieren. Sie machen ein System ausdrücklich nicht sicher.

PHP (php.ini oder FPM-Pool, nicht per ini_set() oder .user.ini)

; FPM-Pool, z. B. /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M         ; 32M, wenn Uploads nötig sind
php_admin_value[upload_max_filesize] = 6M   ; kleiner als post_max_size
; nur PHP 8.5:
php_admin_value[fatal_error_backtraces] = 0

Das PHP-Team nennt außerdem memory_limit=-1, nicht überschreibbar gesetzt, in Kombination mit einer cgroup- bzw. Container-Speichergrenze, die nur den betroffenen Worker beendet. RLIMIT_AS und RLIMIT_DATA sind dafür ungeeignet, weil sie genau den verwundbaren Fehlerpfad auslösen können. Diese Kombination sollte nur umsetzen, wer Speicherlimits im Container sauber kontrolliert.

Webserver und Proxy

Begrenzen Sie vor PHP Größe und Komplexität von Anfragen, auch ohne gültigen Content-Length-Header (Chunked Encoding):

# nginx
client_max_body_size        8m;
client_header_buffer_size   1k;
large_client_header_buffers 4 8k;

# Apache
LimitRequestBody      8388608
LimitRequestFields    50
LimitRequestFieldSize 8190

Die Werte sind Beispiele. Passen Sie sie an Ihre Anwendungen an und testen Sie Upload-Funktionen danach. Auf Proxy- oder WAF-Ebene können Sie zusätzlich die Zahl der Formularfelder, Multipart-Teile und die Verschachtelungstiefe begrenzen.

Woran erkenne ich, ob ein Server bereits kompromittiert ist?

• Dateisystem: Neue oder geänderte PHP-Dateien in Webroots und Upload-Ordnern seit dem 19.10.2026: find /var/www -type f -name '*.php' -newermt '2026-10-19'
• Logs: Auffällige große POST- und Multipart-Anfragen, Häufungen von HTTP 500 und PHP-Fatal-Errors (Out of Memory) im FPM- und Webserver-Log
• Prozesse und Netz: Shells oder unbekannte Binaries als Kindprozesse von php-fpm oder apache2, ausgehende Verbindungen von Webservern
• Persistenz: Neue Cronjobs, systemd-Units und SSH-Schlüssel
• Container: Abweichungen im laufenden Container gegenüber dem Image, z. B. mit docker diff <container>

Bei Verdacht: Host isolieren, Images und VMs aus sauberer Quelle neu aufsetzen statt reparieren, Secrets rotieren (Datenbank, API-Schlüssel für KI-Modelle, Tokens für SSO und Schnittstellen) und Meldepflichten nach DSGVO und, falls zutreffend, NIS2 prüfen.

Fazit: Eigene Infrastruktur heißt eigenes Patch-Management

Die PHP2Shell-Lösung ist ein Update, aber in gewachsenen Umgebungen steckt der Aufwand im Finden, Neubauen und Nachweisen. Wer seine Systeme kennt, Images reproduzierbar baut und PHP-Dienste vom Rest des Netzes trennt, ist in Stunden durch. Wer das nicht tut, sucht tagelang.

DSGPT betreibt KI-Plattformen in Deutschland, in der Private Cloud oder on-premise, inklusive Updates und Überwachung der darunterliegenden Infrastruktur. Wenn Sie Ihren Betrieb absichern oder eine KI-Plattform sicher aufsetzen möchten, sprechen Sie mit uns.

Quellen: PHP-Projekt, Security advisory und Releases vom 21.10.2026 (php.net), CERT-EU, Security Advisory 2026-018, GitHub Security Advisories GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp, NCSC-NL, Liste betroffener Drittsoftware, AlmaLinux (Backports und Paketversionen), it-daily.net: „Behörde warnt vor PHP-Beben“, 21.10.2026, heise online: „php2shell: Kritische Sicherheitslücken erlauben Codeeinschleusung in PHP“. Alle Quellen abgerufen am 22. Oktober 2026.

Zuletzt aktualisiert am 22. Oktober 2026