PHP2Shell: Was jetzt schützt und warum ungepatchte Websites bleiben

Stand: 22. Oktober 2026. PHP2Shell betrifft die technische Grundlage zahlreicher Websites: Zwei kritische Sicherheitslücken können unter passenden Bedingungen die Ausführung fremden Codes ohne Anmeldung ermöglichen. Sicherheitsupdates liegen seit dem 21. Oktober vor. Die entscheidende Frage lautet deshalb inzwischen: Welche öffentlich erreichbaren Installationen laufen tatsächlich mit korrigiertem PHP? [1] [6]

Neue Lage: Angriffsversuche schon vor der Veröffentlichung

AWS berichtet aus der eigenen MadPot-Telemetrie von einem PHP2Shell-Angriffsversuch am 17. Oktober 2026, also vor der öffentlichen Bekanntgabe. Für weitere beobachtete Versuche blieb offen, ob ein Angriff auf reale Zielsysteme erfolgreich gewesen wäre. Das ist ein belegtes Warnsignal, aber keine weltweite Opferzählung. Die Untersuchung möglicherweise betroffener Systeme sollte deshalb nicht erst am Veröffentlichungstag beginnen. AWS: eigene Beobachtungen und Grenzen

Was hinter PHP2Shell steckt

Die Kennungen lauten CVE-2026-109618 und CVE-2026-109619. Beim ersten Fehler gerät die Speicherverwaltung nach Speichermangel in einen ungültigen Zustand. Beim zweiten bleiben interne Verweise auf bereits freigegebenen Speicher bestehen. Spätere Verarbeitung kann solche Zustände gefährlich weiterverwenden. Beide Probleme sitzen in PHP selbst. [3] [4]

„Alle Versionen ab PHP 5“ beschreibt die außergewöhnliche Reichweite, ersetzt aber keine Paketprüfung. Alte 5er- und 7er-Zweige gehören ebenso zur Prüfung wie PHP 8. cPanel führt auch ältere PHP-Pakete und konkrete korrigierte Anbieterrevisionen auf. Der Wechsel von PHP 7 auf irgendeine PHP-8-Version wäre daher kein ausreichender Nachweis. [7]

Besonders kritisch ist Apache mit mod_php: Ein bestätigter Angriffsweg greift bereits vor dem Anwendungscode. Auch PHP-FPM darf nicht als sicher gelten; die PHP Foundation berichtet dort ebenfalls bestätigte Codeausführung über anwendungsabhängige Wege. Ein WordPress-Login schützt folglich nicht zuverlässig vor einem Fehler in der darunterliegenden Laufzeit. [2]

Welche Updates schützen?

Die korrigierten offiziellen Veröffentlichungen sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Für die jeweilige Reihe gilt dieser oder ein neuerer korrigierter Stand. PHP 8.1 und ältere Reihen erhalten keine regulären Veröffentlichungen mehr vom PHP-Projekt. Für 7.4, 8.0 und 8.1 gibt es ausnahmsweise minimale Quellcode-Backports; Distributoren und LTS-Anbieter können eigene korrigierte Pakete liefern. [1]

Eine alte Basisversionsnummer beweist deshalb nicht automatisch einen fehlenden Patch. Entscheidend sind die vollständige Paketrevision und die Bestätigung für beide CVEs. Umgekehrt beweist „PHP 8“ keinen Schutz. [7]

Vom Paketupdate zum geschützten Betrieb

1. Bestand erfassen: Domains, PHP-Pools, Container, alte Testinstallationen und eingebettete Verwaltungsoberflächen gehören zur Inventur.
2. Korrektur belegen: Für jede Laufzeit sind Paketquelle, Revision und Behebung beider CVEs zu dokumentieren.
3. Laufende Instanzen erneuern: PHP-Worker müssen den neuen Stand laden. Eigene Container benötigen ein korrigiertes Image und ein erneutes Deployment. Ein Update des Hosts verändert kein bereits gebautes Containerimage. [8]
4. Webbetrieb kontrollieren: Die Kommandozeile kann eine andere PHP-Installation verwenden als die Website. Erst die Zuordnung der Domain zur tatsächlich laufenden Version samt Funktionsprüfung schließt die Kontrolle ab.

Falls ein Patch kurzfristig unmöglich bleibt, empfiehlt ENISA die Prüfung einer Isolation öffentlich erreichbarer Anwendungen. Eine statische Wartungsseite vor PHP kann dabei den Betrieb sichtbar unterbrechen, ohne weitere Anfragen an die gefährdete Laufzeit weiterzugeben. Ein Wartungsplugin innerhalb derselben PHP-Anwendung erreicht dieses Ziel nicht zuverlässig. [5]

Die offiziellen Konfigurationsmaßnahmen sind lediglich Übergangshilfen. Beispielsweise blockiert session.upload_progress.enabled=0 bestimmte bestätigte Session-Angriffswege, aber keine vollständige Klasse möglicher Varianten. Auch Änderungen an Speichergrenzen sind kein pauschaler Reparaturschalter. Unbegrenzter PHP-Speicher kann zusätzliche Verfügbarkeitsrisiken schaffen. Solche Eingriffe benötigen eine abgestimmte Begrenzung außerhalb von PHP und ersetzen den Patch nicht. [3] [4]

Was ohne Update passieren kann

Der Ausgangspunkt ist Codeausführung mit den Rechten des Webprozesses, nicht automatisch ein Root-Zugang. Daraus ergeben sich abhängig von Berechtigungen und erreichbaren Geheimnissen erhebliche Folgerisiken: ausgelesene Datenbankzugänge, gestohlene Kundendaten, veränderte Inhalte, eingeschleuste Schadsoftware oder missbrauchte Schnittstellenschlüssel. Weitere Angriffe auf interne Dienste sind möglich, sofern Netzwege und Rechte solche Zugriffe zulassen. [3]

Für einen Shop kann bereits eine veränderte Zahlungsseite schwerer wiegen als ein sichtbarer Ausfall. Dazu kommen Untersuchung, Wiederherstellung, Ausfallzeiten und Vertrauensverlust. Ein späterer Patch entfernt keine bereits eingerichtete Hintertür. Bei konkreten Einbruchsspuren gehören Isolation, Beweissicherung, Prüfung der Zugänge und Wiederherstellung aus einem vertrauenswürdigen Stand zur Reaktion.

Werden die Updates wirklich überall installiert?

Einschätzung: Ein schneller erster Rückgang der gefährdeten Installationen ist plausibel, ein vollständiger Abschluss innerhalb weniger Tage kaum. Zentral betreute Plattformen können viele Websites gleichzeitig korrigieren. Bei individuellen Servern hängt das Ergebnis an Zuständigkeiten, Paketverfügbarkeit, Kompatibilität und kontrollierten Neustarts. Google Cloud unterscheidet ausdrücklich zwischen automatisch aktualisierten Laufzeiten und Diensten mit notwendigem Redeployment. [8]

Besonders hartnäckig dürfte der Restbestand werden: aufgegebene Projekte, alte Agenturinstallationen, Container ohne Wartungsprozess und Anwendungen mit Abhängigkeit von abgekündigten PHP-Reihen. Verzögerungen sind dabei nicht automatisch Nachlässigkeit einzelner Administratoren. Fehlende Budgets, unklare Verantwortung und ungeprüfte Altsoftware können einen technisch einfachen Patch organisatorisch blockieren. Eine konkrete weltweite Updatequote wäre derzeit Spekulation.

Wie viele Websites bleiben bedroht?

W3Techs meldet am 22. Oktober PHP bei 69,3 Prozent der Websites mit bekannter serverseitiger Programmiersprache. Innerhalb des erkannten PHP-Bestands entfallen 26,9 Prozent auf PHP 7 und 7,7 Prozent auf PHP 5: zusammen 34,6 Prozent. Das beschreibt Verbreitung und Altbestand, keine gemessene Zahl ungepatchter Websites. [9]

Eine belastbare absolute Restzahl lässt sich daraus nicht berechnen. Anbieter-Backports, unterschiedliche Konfigurationen, verdeckte Versionsangaben und mehrere Websites pro Server verhindern die direkte Gleichsetzung. Auch einzelne Webseiten, Domains und Server sind unterschiedliche Zähleinheiten.

Als reine Rechenillustration: Von einer Million tatsächlich betroffener Installationen blieben bei 95 Prozent erfolgreich abgeschlossenen Updates noch 50.000 ungepatcht. Das ist keine Messung und keine Prognose. Die Rechnung zeigt lediglich, warum selbst eine hohe Updatequote bei großer Verbreitung einen erheblichen Restbestand zulässt. Für die konkrete Website zählt der nachgewiesene Patchstand wesentlich mehr als jede globale Prozentzahl.

Linux-Praxis: zuerst die tatsächlich verwendete Installation erfassen

Die folgenden Paketbeispiele gelten für Debian-/Ubuntu-Systeme mit APT und bereits eingerichteten, vertrauenswürdigen Paketquellen. Die jeweilige PHP-Reihe muss dort schon installiert sein. RPM-Systeme, Hosting-Panels und selbst gebaute Container benötigen den passenden Anbieterablauf. Eine willkürlich ergänzte Fremdquelle wäre keine belastbare Reparaturstrategie.

Vor dem Eingriff gehören eine wiederherstellbare Sicherung, die Zuordnung von Domains zu PHP-Pools und ein kurzer Funktionstestplan zum Ablauf. Paketinstallationen können Dienste bereits während der Installation neu starten. Ein Wartungsfenster muss daher vor dem Installationsbefehl beginnen. Die Bestandsaufnahme zeigt CLI und Dienste, ersetzt aber noch nicht die Kontrolle des Webhandlers:

cat /etc/os-release
command -v php
php -v
php --ini
dpkg-query -W -f='${binary:Package}\t${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null
systemctl list-units --type=service --all | grep -E 'php.*fpm|apache2|nginx'
ps -eo pid,lstart,comm | grep -E 'php|apache2'

Eine Domain kann PHP 8.4 über FPM verwenden, während php in der Shell auf 8.5 zeigt. Weitere Kopien können in Containern, Hosting-Verzeichnissen und alten Testdiensten liegen. Ein Prüfnachweis benötigt pro Installation Paketquelle, vollständige Revision, Dienst beziehungsweise Container und die zugehörigen Websites.

PHP 8.4 über APT aktualisieren

Dieser Ablauf aktualisiert ausschließlich bereits installierte Pakete der Reihe 8.4 einschließlich vorhandener Erweiterungen und eines eventuell installierten Apache-Moduls. Die Simulation verändert keine Pakete. Der Kandidat muss mindestens PHP 8.4.27 oder einen vom Anbieter für beide CVEs bestätigten Backport enthalten. Für Debian 13 ist 8.4.27-1~deb13u1 als korrigiert dokumentiert. APT-Dokumentation · Debian: CVE-2026-109618 · Debian: CVE-2026-109619

set -euo pipefail
branch=8.4
sudo apt-get update
mapfile -t php_packages < <(
  dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' \
    "php${branch}-*" "libapache2-mod-php${branch}" 2>/dev/null |
  awk '$1 == "ii" { print $2 }'
)
test "${#php_packages[@]}" -gt 0
apt-cache policy "${php_packages[@]}"
sudo apt-get -s install --only-upgrade "${php_packages[@]}"

Erst nach Prüfung des Plans folgt die Installation. Unerwartete Entfernungen, Reihenwechsel oder weiterhin verwundbare Kandidaten sind Abbruchgründe. Der folgende Block gehört in dieselbe Bash-Sitzung wie der vorangehende und setzt einen vorhandenen FPM-Dienst voraus:

sudo apt-get install --only-upgrade "${php_packages[@]}"
sudo /usr/sbin/php-fpm8.4 -t
sudo systemctl restart php8.4-fpm
systemctl is-active php8.4-fpm
/usr/bin/php8.4 -v
/usr/sbin/php-fpm8.4 -v

PHP 8.5 über APT aktualisieren

Für eine bestehende 8.5-Installation gilt derselbe Ablauf mit einem korrigierten Kandidaten ab 8.5.12 oder bestätigtem Anbieter-Backport. Ein Debian-13-Standardrepository stellt nicht allein deshalb PHP 8.5 bereit, weil eine neuere PHP-Reihe existiert. Falls kein passender Kandidat aus der bereits freigegebenen Quelle verfügbar ist, endet dieser Ablauf vor der Installation.

set -euo pipefail
branch=8.5
sudo apt-get update
mapfile -t php_packages < <(
  dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' \
    "php${branch}-*" "libapache2-mod-php${branch}" 2>/dev/null |
  awk '$1 == "ii" { print $2 }'
)
test "${#php_packages[@]}" -gt 0
apt-cache policy "${php_packages[@]}"
sudo apt-get -s install --only-upgrade "${php_packages[@]}"

Auch hier gilt: Fortsetzung erst nach Prüfung, in derselben Bash-Sitzung und ausschließlich für einen vorhandenen FPM-Dienst.

sudo apt-get install --only-upgrade "${php_packages[@]}"
sudo /usr/sbin/php-fpm8.5 -t
sudo systemctl restart php8.5-fpm
systemctl is-active php8.5-fpm
/usr/bin/php8.5 -v
/usr/sbin/php-fpm8.5 -v

Bei Apache mit mod_php muss stattdessen das Apache-Modul tatsächlich aktualisiert und Apache nach erfolgreicher Konfigurationsprüfung geordnet neu gestartet werden. Für Debian lautet die Prüfung sudo apache2ctl configtest. Ein reines FPM-Setup benötigt wegen eines PHP-Paketupdates keinen pauschalen nginx-Neustart. Eigene FPM-Master, dauerhaft laufende CLI-Dienste und Container müssen gesondert berücksichtigt werden. Ein Neustart kann laufende Anfragen unterbrechen; in redundanten Umgebungen erfolgt die Umstellung nacheinander.

Warum „PHP aktualisiert“ noch nicht „PHP aktiv korrigiert“ bedeutet

Linux kann einen laufenden Prozess weiter mit einer alten, bereits ersetzten Programmdatei bedienen. Ein neu gestartetes php -v meldet dann den korrigierten Stand, während ein alter Worker unverändert weiterläuft. Die folgende rein lesende Kontrolle findet PHP-Prozesse mit gelöschter ausführbarer Datei:

sudo bash <<'BASH'
for link in /proc/[0-9]*/exe; do
  target=$(readlink "$link" 2>/dev/null) || continue
  case "$target" in
    *php*"(deleted)"*)
      pid=${link#/proc/}
      pid=${pid%/exe}
      printf 'PID %s: %s\n' "$pid" "$target"
      ;;
  esac
done
BASH

Ein Treffer ist ein Anlass zur Versions- und Dienstprüfung, kein Einbruchsnachweis. Umgekehrt beweist eine leere Ausgabe noch keine vollständige Absicherung: geladene Apache-Module, Bibliotheken und separat eingebaute Laufzeiten benötigen eigene Kontrollen. Entscheidend sind die aktiven Worker, nicht nur Paketlisten. Abschließend gehören Login, Upload, Formular, Queue und zeitgesteuerte Aufgaben in eine anwendungsspezifische Funktionsprobe. Öffentliche phpinfo()-Seiten sind dafür ungeeignet; eine geschützte interne Diagnose oder die Zuordnung des aktiven Prozesses genügt.

PHP 7.4: ein Sicherheits-Backport statt unveränderter 7.4.33

PHP 7.4 bleibt abgekündigt. Der bevorzugte Weg ist die Migration auf eine unterstützte Reihe oder ein belegter LTS-Patch des bisherigen Anbieters. Für eine unvermeidbare Übergangsphase hat das PHP-Projekt einen minimalen Quellcode-Backport für beide PHP2Shell-Kennungen veröffentlicht. Das ist keine Wiederaufnahme des allgemeinen Supports und keine Zusage zur Behebung anderer Lücken.

Der am 22. Oktober geprüfte Sicherheits-Commit lautet 712e60f9edfd03f0960fc4fc3c2c375f42b90aa2. Der folgende Ablauf bindet den Quellstand ausdrücklich an diesen Commit. Ein bloßer Neubau des unveränderten Releases 7.4.33 enthält diese Änderung nicht. PHP: konkreter Sicherheits-Commit

Das Beispiel ist ein minimales CLI-/FPM-Build in einer separaten, kompatiblen Debian-/Ubuntu-Buildumgebung mit vorhandenem Git und CA-Zertifikaten. Alle Blöcke werden in derselben Bash-Sitzung ausgeführt. Der Build ist keine hier auf einem Produktionsserver durchgeführte oder vollständig abgenommene Installation. Alte PHP-Quellen und aktuelle Systembibliotheken sind nicht beliebig kombinierbar.

set -euo pipefail
workdir=$(mktemp -d "$HOME/php74-php2shell.XXXXXX")
cd "$workdir"
git init php-src
cd php-src
git remote add origin https://github.com/php/php-src.git
commit=712e60f9edfd03f0960fc4fc3c2c375f42b90aa2
git fetch --depth=1 origin "$commit"
git checkout --detach FETCH_HEAD
test "$(git rev-parse HEAD)" = "$commit"
git show -s --format='%H%n%s%n%b' HEAD

Die Mindestwerkzeuge und das isolierte Installationsziel folgen unten. --disable-all hält den Beispielumfang klein; das Ergebnis enthält insbesondere nicht automatisch alle für WordPress oder andere Anwendungen nötigen Erweiterungen. Die vorgesehenen Benutzer- und Gruppennamen www-data müssen in der Zielumgebung existieren. PHP: Unix-Installation · PHP: FPM-Buildoptionen

sudo apt-get update
sudo apt-get install --no-install-recommends \
  build-essential autoconf bison re2c pkg-config \
  libxml2-dev libsqlite3-dev

./buildconf --force
prefix=/opt/php74-php2shell-712e60f9
test ! -e "$prefix"
./configure \
  --prefix="$prefix" \
  --with-config-file-path="$prefix/etc" \
  --with-config-file-scan-dir="$prefix/etc/conf.d" \
  --disable-all --enable-cli --enable-fpm --enable-session \
  --with-fpm-user=www-data --with-fpm-group=www-data \
  --without-pear
make -j2
NO_INTERACTION=1 REPORT_EXIT_STATUS=1 make test

Fehlgeschlagene oder unerklärlich übersprungene relevante Tests benötigen eine Untersuchung. Erst nach akzeptiertem Testlauf folgt die Installation in den neuen Prefix; /usr/bin/php und bestehende Distributionspakete werden dabei nicht ersetzt:

sudo make install
sudo install -d -m 0755 "$prefix/etc/conf.d"
sudo install -m 0644 php.ini-production "$prefix/etc/php.ini"
"$prefix/bin/php" -n -v
"$prefix/bin/php" --ini
"$prefix/sbin/php-fpm" -v
git rev-parse HEAD

Die Ausgabe kann weiterhin eine 7.4-Versionsnummer tragen. Der Sicherheitsnachweis besteht hier aus dem geprüften Quellcommit, Buildprotokoll und dem tatsächlich verwendeten Artefakt. Für den Produktivbetrieb fehlen noch die benötigten Erweiterungen und deren Tests: beispielsweise Datenbanktreiber, mbstring, XML, cURL oder ZIP. Passende Entwicklungsbibliotheken, ABI und phpize/php-config müssen zu genau diesem Build gehören.

Danach benötigen FPM-Konfiguration, Poolbenutzer und Dateirechte eine eigene Prüfung. Ein separater Socket und ein eigener Dienst verhindern eine versehentliche Vermischung mit der bisherigen Laufzeit. Erst nach erfolgreichem Konfigurationstest mit dem neuen php-fpm -t -y /pfad/zur/php-fpm.conf folgt die gezielte Umstellung des Webhandlers auf diesen Pool. Ein erfolgreicher CLI-Aufruf allein verändert keine Website. Bei gescheitertem Rollout darf der Rückweg nicht kommentarlos wieder auf die öffentlich erreichbare verwundbare Laufzeit führen; Isolation bleibt dann die Zwischenlösung.

Angriffsspuren: mehrere Signale zusammen betrachten

Datadog hat die Fehler im Labor reproduziert. Erfolgreiche Codeausführung muss weder einen Worker-Absturz noch einen auffälligen HTTP-Status erzeugen. Ein HTTP 200 ist daher kein Entwarnungssignal. Verdächtige Formularanfragen, Speicherfehler und unerwartete Kindprozesse gewinnen erst im zeitlichen Zusammenhang Aussagekraft. Ein einzelner Speichermangelfehler beweist noch keinen Angriff. Datadog Security Labs: eigene Analyse

Für eine Untersuchung sind Webserver-/Proxylogs, PHP-Fehler, Prozessereignisse und unerwartete Dateiänderungen zusammenzuführen. Vorhandene Belege sollten vor Bereinigung gesichert werden. Pauschales Mitschneiden vollständiger Formularinhalte würde zusätzliche Passwörter und personenbezogene Daten in Logs bringen; Metadaten und kontrollierte Forensik sind vorzuziehen. Eine WAF kann Anfragen begrenzen, behebt aber den PHP-Fehler nicht. Der Abschluss braucht zwei getrennte Aussagen: korrigierte Laufzeit aktiv und möglicher früherer Zugriff untersucht.

PHP2Shell in den Logs erkennen: Verdacht ist noch kein Nachweis

Ein universeller Logeintrag „PHP2Shell erkannt“ existiert nicht. Die Auswertung muss zwischen auffälliger Anfrage, technischem Fehler und bestätigter fremder Codeausführung unterscheiden. Aussagekräftig ist eine zeitlich passende Kette: ungewöhnliche Anfrage am Proxy, Fehler oder Prozessereignis beim zuständigen PHP-Worker und eine nicht durch den normalen Betrieb erklärte Folgehandlung. Fehlende Einträge können ebenso durch ausgeschaltetes Logging, Rotation oder eine zu kurze Aufbewahrung entstehen.

Erste Log-Abfragen unter Linux

Die folgenden Befehle lesen vorhandene Daten. Dienstnamen, Dateipfade und Zeitraum müssen zur Installation passen. Die Zeitangabe gilt in der lokalen Systemzeitzone; für den Abgleich mit anderen Systemen sind Zeitversatz und synchronisierte Uhren zu berücksichtigen. Das Journal enthält PHP-Fehler nur, wenn der jeweilige Dienst solche Meldungen tatsächlich dorthin schreibt. systemd: journalctl

sudo journalctl --since '2026-10-17 00:00:00' \
  -u php8.4-fpm -u php8.5-fpm -u apache2 -u nginx \
  --no-pager -o short-iso |
grep -Ei 'Allowed memory size.*exhausted|Out of memory|segfault|SIGSEGV|child .*exited on signal'

Eine fehlende Ausgabe bedeutet lediglich „kein Treffer in diesen Quellen mit diesem Suchmuster“. Separate FPM-Fehlerdateien, Containerlogs und virtuelle Hosts mit eigenen Protokollen benötigen zusätzliche Abfragen. Auch bereits rotierte Dateien gehören zum Untersuchungszeitraum.

Für übliche Apache-/nginx-Access-Logs mit einer protokollierten HTTP-Anfrage liefert die folgende Abfrage die letzten hundert passenden POST-Zeilen der eingelesenen Dateien. Das ist eine erste Sichtung, kein vollständiger Scanner und wegen der Dateireihenfolge keine garantierte zeitliche Sortierung:

sudo zgrep -hE '"POST [^"]+ HTTP/[0-9.]+"' \
  /var/log/nginx/access.log* /var/log/apache2/access.log* |
tail -n 100

Falls ein genannter Logpfad nicht existiert oder ein anderes Format verwendet wird, ist die Dateiauswahl anzupassen. Standard-Access-Logs enthalten normalerweise keinen vollständigen Request-Body. Die häufig vorhandene Bytezahl beschreibt zudem meist die Antwortgröße, nicht die Größe des Uploads. Ein Suchlauf nach PHP_SESSION_UPLOAD_PROGRESS in gewöhnlichen Access-Logs kann deshalb leer bleiben, obwohl ein entsprechendes Formularfeld gesendet wurde. Fehlende Bodydaten lassen sich nachträglich nicht rekonstruieren. Apache: Bedeutung und Konfiguration der Logs

Eine Momentaufnahme der Prozessbeziehungen kann ergänzend helfen:

ps -eo pid,ppid,lstart,user,comm --forest

Diese Liste zeigt ausschließlich aktuell laufende Prozesse. Bereits beendete Befehle erscheinen nur in zuvor aktivierter Prozessüberwachung, etwa Audit- oder EDR-Telemetrie. Ein heute eingeschaltetes Monitoring liefert keine rückwirkende Ausführungshistorie.

Logging gezielt verbessern, ohne Formularinhalte zu sammeln

Ein zusätzliches nginx-Protokoll kann Request-ID, Zeitpunkt, Methode, Pfad, Status, Anfragegröße und Laufzeit zusammenführen. Der folgende Vorschlag gehört in den http-Kontext. Das Format ergänzt die Untersuchung künftig; bereits fehlende Daten bleiben fehlend. nginx: log_format und access_log

log_format php2shell escape=json
  '{"time":"$time_iso8601","request_id":"$request_id",'
  '"client":"$remote_addr","method":"$request_method","uri":"$uri",'
  '"status":"$status","request_bytes":"$request_length",'
  '"response_bytes":"$body_bytes_sent","duration":"$request_time",'
  '"upstream_status":"$upstream_status"}';

Im ausgewählten server-Kontext aktiviert die nächste Direktive dieses Format. Bestehende Logs und ihre Vererbung sind dabei zu prüfen; die neue Direktive darf die bisher benötigte Protokollierung nicht unbemerkt verdrängen.

access_log /var/log/nginx/php2shell-access.log php2shell;

Vor einem geordneten Reload steht ein erfolgreicher nginx -t-Test. request_bytes enthält die gesamte empfangene Anfrage einschließlich Headern und ist weder allein die Dateigröße noch der daraus entstehende PHP-Speicherbedarf. Das Format protokolliert keinen Querystring, keine Cookies, keinen Authorization-Header und keinen Body. IP-Adressen und Pfade können trotzdem personenbezogen sein; Zugriff, Aufbewahrung und Rotation gehören zur Einrichtung. Hinter einem Proxy ist die Clientadresse nur bei korrekt konfigurierter Vertrauenskette verlässlich. OWASP: sichere Protokollierung

Schutz während eines noch offenen Updates

Priorität hat die korrigierte Laufzeit. Zusätzliche Kontrollen begrenzen die Erreichbarkeit und mögliche Folgen, ersetzen aber keinen Patch. Bei einer exponierten, kurzfristig nicht aktualisierbaren Anwendung ist eine Isolation vor PHP die klarste Zwischenlösung: statische Wartungsseite, VPN oder vorgeschaltete Zugriffsbeschränkung. Der direkte Origin-Zugriff muss dieselben Grenzen einhalten; ein geschützter CDN-Weg bei offen erreichbarem Backend reicht nicht.

• Anfragen begrenzen: Größen-, Upload- und Ratenlimits am Reverse Proxy an den tatsächlichen Bedarf anpassen. Auch legitime Importe und große Dateien benötigen eine geprüfte Regel. Eine kleine Anfrage kann intern mehr Speicher beanspruchen; ein Größenlimit ist deshalb kein vollständiger Schutz.
• WAF als Zusatzschicht: Passende Herstellerregeln aktivieren und ihre tatsächliche Durchsetzung prüfen. Regeln im Beobachtungsmodus blockieren nichts; ein HTTP 403 belegt nur die Ablehnung dieser Anfrage.
• Rechte begrenzen: Eigene Poolkonten, minimale Dateirechte, eingeschränkte Datenbankkonten und begrenzte Netzwerkzugriffe verkleinern mögliche Folgeschäden. Eine übernommene Anwendung kann weiterhin alle legitim verfügbaren Geheimnisse missbrauchen.
• Offizielle Übergangsmaßnahmen: Frühes Abschalten des Session-Upload-Fortschritts blockiert bestimmte Pfade, aber nicht beide Fehler vollständig. Eine pauschale Umstellung auf unbegrenzten PHP-Speicher ohne passende äußere Begrenzung kann zusätzliche Ausfälle verursachen.

Bei konkreten Einbruchsspuren: Patch und Vorfall getrennt behandeln

Eine verdächtige Datei einfach zu löschen und anschließend PHP zu aktualisieren reicht nicht für einen belastbaren Abschluss. Zuerst ist die betroffene Instanz so zu isolieren, dass weitere Zugriffe verhindert werden. Parallel gehören relevante Logs, Zeitangaben und verfügbare Prozessdaten gesichert. Eine unüberlegte Bereinigung kann wertvolle Belege vernichten.

Anschließend folgen die Prüfung erreichbarer Daten und Nachbarsysteme, die Erneuerung möglicherweise offengelegter Zugangsdaten aus einer vertrauenswürdigen Umgebung und gegebenenfalls der Neuaufbau aus geprüften Quellen. Ein Backup muss zeitlich und inhaltlich vor einer möglichen Kompromittierung liegen. Die Rückkehr in den öffentlichen Betrieb setzt eine korrigierte aktive Laufzeit, geprüfte Anwendung und fortgesetzte Beobachtung voraus. „Patch installiert“ und „Vorfall aufgeklärt“ bleiben zwei unterschiedliche Nachweise.

Quellen

1. PHP: Security advisory, 21 October 2026
2. PHP Foundation: security release and background
3. PHP: CVE-2026-109618
4. PHP: CVE-2026-109619
5. ENISA: joint statement
6. NHS England: PHP2Shell
7. cPanel: corrected package revisions
8. Google Cloud: runtime updates and redeployment
9. W3Techs: PHP usage, 22 October 2026

Zusätzliche Primärquellen und Dokumentation

• PHP: pinned PHP 7.4 security backport
• PHP: Unix installation
• PHP: FPM compilation options
• APT: apt-get options and simulation
• Debian: CVE-2026-109618
• Debian: CVE-2026-109619
• AWS: MadPot observations before disclosure
• Datadog Security Labs: reproduction, detection and remediation

Weiterführende Analysen und Berichterstattung

• Brandefense
• SOCRadar
• Abstract Security
• Tanium
• SecurityWeek

Der zusätzlich genannte Beitrag von Prophet Security war bei der Recherche nicht abrufbar und wurde nicht als Beleg verwendet.

Dokumentation zur Log-Auswertung

• nginx
• Apache HTTP Server
• systemd journalctl
• OWASP Logging Cheat Sheet