Geben Sie eine eigene oder zum Test freigegebene URL ein. Prüfen Sie PHP-Merkmale, Versionshinweise und Formularantworten, um die PHP2Shell-Exposition einzuschätzen und Maßnahmen abzuleiten.
2
Schwachstellen im PHP-Kern
9.2
CVSS-v4.0-Bewertung (kritisch)
4
Offiziell behobene Zweige von 8.2 bis 8.5
Überblick über die Schwachstellen
PHP2Shell bezeichnet die beiden Speichersicherheitslücken CVE-2026-109618 und CVE-2026-109619 im PHP-Kern, beide mit CVSS v4.0 9.2 bewertet. Sie können Remotecodeausführung ohne Anmeldung ermöglichen; die Auswirkungen hängen von Version, Bereitstellung und Angriffsweg ab.
Speicherbeschädigung bei der Behandlung von Speichermangel kann Remotecodeausführung ohne Anmeldung ermöglichen. PHP aktualisieren oder Hersteller-Patches einspielen.
Details lesenVeralteter globaler Anfragezustand kann von einer späteren Anfrage im selben Worker wiederverwendet werden und Speicherfehler sowie Remotecodeausführung verursachen.
Details lesenTatsächliche Web-Laufzeit, vollständige Paketversion und Herstellerhinweise prüfen und die betroffenen Worker nach dem Update neu starten. Vorläufige Maßnahmen ersetzen keine Patches.
Details lesenPHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed und andere PHP-Webumgebungen erfassen. PHP stuft mod_php als besonders riskant ein; Angriffe wurden bereits vor Ausführung des Anwendungscodes demonstriert. Einfache Seiten und sicherer Anwendungscode schließen eine Gefährdung nicht aus.
Ein Update von WordPress, Drupal, Framework oder Plugin aktualisiert nicht automatisch die verwendete PHP-Laufzeit. PHP-Version jedes Standorts, FPM-Pools, Container-Images, Serverknoten sowie eingebettetes PHP in Verwaltungsoberflächen oder Geräten prüfen. Offizielle korrigierte Versionen erschienen am 21. Oktober 2026.
Was der Prüfer untersucht
PHP-Merkmale in öffentlichen Antworten prüfen.
Versionsangaben sind Hinweise, kein Nachweis einer Behebung.
Statusunterschiede anhand von Kontrollanfragen einordnen.
Vollständige Paketversionen mit Herstellerhinweisen abgleichen.
Sicherstellen, dass alle Web-Worker aktualisiert und neu gestartet wurden.
Zuerst einen GET als Ausgangsbasis abrufen, danach für jede der drei Methoden ein URL-kodiertes und ein Multipart-Formular senden. Jede Antwort vor der nächsten Anfrage prüfen. Diese normalen Anfragen vergleichen Verhalten ohne Codeausführungs- oder Speichererschöpfungs-Payloads.
| Reihenfolge | Methode | Anfrageinhalt | Worauf zu achten ist |
|---|---|---|---|
| 01 | GET | Ohne Anfragekörper | Erreichbarkeit, Weiterleitungen, öffentliche PHP-Versionsangaben und Antwort-Header. |
| 02 | POST | application/x-www-form-urlencoded | Ein normales Textfeld als POST-Kontrollanfrage. |
| 03 | POST | multipart/form-data | Ein Textfeld zum Vergleich mit der POST-Kontrolle, ohne Dateiteile oder Upload-Fortschrittsfelder. |
| 04 | PUT | application/x-www-form-urlencoded | Ein normales Textfeld, um die PUT-Verarbeitung dieses Pfads zu beobachten. |
| 05 | PUT | multipart/form-data | Mit URL-kodiertem PUT auf Unterschiede durch den Inhaltstyp vergleichen. |
| 06 | PATCH | application/x-www-form-urlencoded | Ein normales Textfeld als PATCH-Kontrollanfrage. |
| 07 | PATCH | multipart/form-data | Mit der PATCH-Kontrolle vergleichen, statt vom POST-Verhalten auf alle Methoden zu schließen. |
PHP-Angaben in X-Powered-By oder Server sowie Sitzungscookies wie PHPSESSID sind nur Laufzeithinweise. Sie können verborgen, geändert oder angepasst sein. Ein Cookie beweist auch nicht, dass PHP den Anfragekörper verarbeitet hat.
Die Prüfungen erfassen nur die eingegebene URL und ihren Pfad. Andere Routen, CDN-Regeln und direkt erreichbare Ursprungsserver können abweichen. Ergebnisse der Startseite nicht auf die gesamte Website übertragen. Nur autorisierte, für Formularanfragen geeignete Pfade prüfen.
Ergebnisse richtig einordnen
Öffentliche Antworten liefern nur einen Teil der Belege. Versionsangaben können verborgen oder verändert sein, ältere Versionen können Backports enthalten. Die tatsächliche Laufzeit prüfen und fehlende Belege nicht als Sicherheit werten.
Häufige Fehlinterpretationen ansehenEine öffentliche Version ab dem Korrekturstand ihres Zweigs ist ein nützlicher Hinweis, kann aber vom Proxy verändert sein. Auf dem Host prüfen, ob jede Instanz den korrigierten Code geladen hat.
Versionen unter dem offiziellen Korrekturstand vorrangig prüfen und nach Distributions- oder LTS-Backports suchen. Bei unbekanntem Backport-Status Prüfbedarf dokumentieren, keine bestätigte Remotecodeausführung behaupten.
Eine erfolgreiche Kontrollanfrage bei Multipart-4xx kann auf Inhaltstypbeschränkungen hinweisen. Zweimal 405 kann lediglich eine nicht unterstützte Methode bedeuten. Statuscodes allein unterscheiden keine Ablehnung durch CDN, Webserver oder Anwendung.
Verborgene Versionen, Proxy-Caches, eigene Cookies, Verbindungsfehler und Zeitüberschreitungen begrenzen die Bewertung. Fehlende Belege oder eine nicht mögliche Bewertung dokumentieren, statt ein grünes Sicherheitsurteil anzuzeigen.
Prüfablauf
Adresse einer eigenen oder zum Test freigegebenen Website samt zu prüfendem Pfad angeben.
GET-Ausgangsbasis prüfen, dann URL-kodierte und Multipart-Antworten für POST, PUT und PATCH einzeln vergleichen.
Statuscodes und Versionshinweise einordnen, dann den Patch-Status anhand der tatsächlichen PHP-Laufzeit und Herstellerhinweise prüfen.
Prüfung auf dem Host
Externe Prüfungen liefern Hinweise; der Patch-Status muss jedoch auf dem Host, in Containern oder im Hosting-Panel bestätigt werden. Laufzeit, Paketquelle, Korrekturversion und Prozesszustand nach dem Update dokumentieren.
Die dem Standort zugewiesene PHP-Version, das Webserver-Modul oder den FPM-Pool prüfen. Parallele Versionen, Websites, Container und Lastverteilungsknoten einzeln erfassen. php -v zeigt nur die aktuelle CLI-Version, nicht zwingend die Web-Laufzeit. Dafür keine öffentliche phpinfo-Seite bereitstellen.
php -vDas verwendete Paket abfragen und die vollständige Version mit der Distributionsmeldung vergleichen. Ubuntu 24.04 enthält die Korrektur bereits in 8.3.6-0ubuntu0.24.04.13; PHP 8.3.6 allein lässt diesen Backport nicht erkennen. Passendes Beispiel wählen und den Paketnamen anpassen.
dpkg-query -W php8.3-fpm
rpm -q php-fpmEine korrigierte offizielle Version, eine spätere Sicherheitsversion desselben Zweigs oder einen bestätigten Hersteller-Backport verwenden. Gebündeltes PHP in Panels, Geräten und Containern über den jeweiligen Anbieter aktualisieren. PHP 8.1 und älter erhalten keinen regulären Upstream-Support; LTS-Korrekturen prüfen oder migrieren. PHP stellte außerdem minimale Quellcode-Backports für 7.4, 8.0 und 8.1 bereit.
Neustart von PHP-FPM, Apache oder anderen Workern sowie Austausch von Containern und Knoten bestätigen. Aktualisierte Dateien auf der Festplatte garantieren nicht den Austausch alter Prozesse. Auffällige Anfragen, Speichermangel und Worker-Abstürze helfen bei der Untersuchung; ihr Fehlen beweist keine Unbetroffenheit.
Das Skript sendet nacheinander einen GET sowie URL-kodierte und Multipart-Formulare mit POST, PUT und PATCH. Es enthält nur Textfelder, keine Dateien oder Upload-Fortschrittsfelder. Nur auf autorisierten, für Testformulare geeigneten Pfaden ausführen; auch normale Anfragen können Anwendungsaktionen auslösen.
#!/usr/bin/env bash
# PHP2Shell HTTP observations: 7 sequential requests, no exploit payload.
set -u
URL="${1:-https://example.com/}"
case "$URL" in
http://*|https://*) ;;
*) printf 'ERROR=HTTP(S)_URL_REQUIRED\n' >&2; exit 2 ;;
esac
if ! command -v curl >/dev/null 2>&1 || ! command -v awk >/dev/null 2>&1; then
printf 'ERROR=CURL_AND_AWK_REQUIRED\n' >&2
exit 127
fi
probe() {
printf '\n[%s/7] %s %s\n' "$1" "$2" "$3"
local method="$2"
shift 3
curl -q --globoff --proto '=http,https' --silent --show-error \
--connect-timeout 5 --max-time 15 --request "$method" \
--dump-header - --output /dev/null \
--write-out '\nHTTP_CODE=%{http_code} TOTAL_SECONDS=%{time_total}\n' \
"$@" --url "$URL" |
awk '{
sub(/\r$/, "")
line = tolower($0)
if ($0 ~ /^HTTP\// || line ~ /^(server|x-powered-by|content-type):/ || $0 ~ /^HTTP_CODE=/) {
print
} else if (line ~ /^set-cookie:[ \t]*phpsessid[ \t]*=/) {
print "PHPSESSID=present; value hidden"
}
}'
local curl_status="${PIPESTATUS[0]}"
if [ "$curl_status" -ne 0 ]; then
printf 'CURL_EXIT=%s\n' "$curl_status"
FAILED=1
fi
}
FAILED=0
probe 1 GET baseline
probe 2 POST urlencoded --data-raw 'php2shell_check=1'
probe 3 POST multipart --form-string 'php2shell_check=1'
probe 4 PUT urlencoded --data-raw 'php2shell_check=1'
probe 5 PUT multipart --form-string 'php2shell_check=1'
probe 6 PATCH urlencoded --data-raw 'php2shell_check=1'
probe 7 PATCH multipart --form-string 'php2shell_check=1'
exit "$FAILED"Bash unter Linux/macOS oder WSL beziehungsweise Git Bash unter Windows verwenden. Als php2shell-self-check.sh speichern und den folgenden Befehl mit einer autorisierten Test-URL ausführen. Das Bash-Skript nicht direkt in PowerShell einfügen.
bash php2shell-self-check.sh https://example.com/test.phpFür die Verbindung gelten 5 Sekunden, pro Anfrage insgesamt 15 Sekunden. Das Skript ignoriert persönliche curl-Einstellungen, prüft TLS und folgt weder Weiterleitungen noch führt es Wiederholungen aus. Bei 3xx die Berechtigung für die endgültige URL prüfen und dort erneut starten. PHPSESSID erscheint nur als Hinweis; Cookie-Werte und Antwortinhalte werden nicht ausgegeben.
HTTP_CODE ist der Antwortstatus, TOTAL_SECONDS die Gesamtdauer. CURL_EXIT ungleich null kennzeichnet einen Übertragungsfehler; die übrigen Prüfungen laufen weiter. Ein Skript-Exitcode ungleich null zeigt Eingabe-, Abhängigkeits- oder Übertragungsprobleme. HTTP 4xx/5xx werden normal erfasst; der Exitcode bewertet weder Schwachstellen noch Patch-Status.
Server oder X-Powered-By können fehlen oder veraltet sein. Prüfen Sie die tatsächlich für die Website zuständige PHP-Laufzeit: Die ersten offiziell korrigierten Versionen der jeweiligen Zweige sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Hersteller-Backports anhand der vollständigen Paketversion und des Sicherheitshinweises bestätigen.
Liefert bei derselben Methode urlencoded 2xx oder 3xx, multipart jedoch 403 oder 406, belegt das lediglich unterschiedliche Antworten. Weder eine WAF-Sperre noch eine Ablehnung vor PHP ist damit bestätigt.
Eine multipart-Antwort mit 2xx oder 3xx bedeutet nur, dass eine Erfolgs- oder Weiterleitungsantwort einging. Sie beweist weder, dass PHP den Inhalt erhalten und verarbeitet hat, noch ob die Schwachstelle vorliegt.
Durchgehend 405 beweist keine Behebung. Fehlende PHP-Merkmale beweisen nicht, dass PHP ungenutzt ist. Auch ein PHPSESSID-Cookie zeigt weder sicher eine multipart-Verarbeitung noch die antwortende Schicht an.
Laut PHP behebt nur ein Update das Problem vollständig. Die folgenden Einstellungen verringern bestimmte bekannte Angriffswege, machen eine ungepatchte Laufzeit aber nicht sicher. Vor Änderungen Anwendungsanforderungen und offizielle Hinweise prüfen.
Offizielle korrigierte Versionen
Versionen innerhalb jedes Zweigs vergleichen: Der Korrekturstand von 8.3 bestimmt nicht den Status von 8.4. Vorabversionen oder unbekannte Zweige nicht als behoben annehmen. Backports und eigene Builds anhand vollständiger Paketversionen, Build-Protokolle und Herstellerhinweise prüfen.
Laut BaoTa-Mitteilung vom 2026-10-21 sind einige PHP-Sicherheitsversionen im Panel verfügbar. Welche Versionen aktuell angeboten werden, zeigt der Software-Store Ihres BaoTa Panels.
BaoTa-Update-Mitteilung lesenSichern Sie vor dem Update Website, Datenbanken und relevante Konfigurationen und wählen Sie ein geeignetes Wartungsfenster.
Melden Sie sich im BaoTa Panel an, öffnen Sie Software-Store → Installiert und rufen Sie die Verwaltung der PHP-Version auf, die Ihre Website tatsächlich verwendet.
Prüfen Sie auf der PHP-Verwaltungsseite verfügbare Updates und installieren Sie nach Anleitung die oben genannte korrigierte Version desselben Zweigs oder eine spätere Sicherheitsversion dieses Zweigs.
Starten Sie danach den entsprechenden PHP-Dienst neu und bestätigen Sie, dass alle Worker neu geladen wurden. Prüfen Sie die tatsächlich verwendete PHP-Version sowie Seitenaufrufe, Uploads, Datenbankverbindungen und weitere Funktionen.
Prüfen Sie bei mehreren installierten PHP-Versionen jede noch verwendete Version. Wenn Sie eine weitere Version installieren, stellen Sie sicher, dass die Website auf die korrigierte PHP-Laufzeit umgestellt wurde.
Häufige Fragen
Versionshinweise, Statuscodes und Hersteller-Backports unterscheiden, um Ergebnisse nicht überzuinterpretieren.
PHP2Shell bezeichnet die beiden PHP-Kernlücken CVE-2026-109618 und CVE-2026-109619, die Remotecodeausführung ohne Anmeldung ermöglichen können. Alle ungepatchten PHP-Webumgebungen prüfen, auch bei sicherem Anwendungscode.
Nein. Authentifizierung, nicht unterstützte Methoden, Größenlimits oder Proxys können solche Codes erzeugen. Auch eine abgelehnte Multipart-Anfrage beschreibt nur den aktuellen Pfad und beweist weder ein korrigiertes PHP noch vollständigen Schutz.
Nicht zwingend. Die Versionsanzeige kann deaktiviert sein; CDN, Reverse-Proxy oder statische Startseite können das Backend verdecken. Fehlende Merkmale bedeuten unzureichende Informationen. Die tatsächliche Serverlaufzeit prüfen.
Offizielle Korrekturen gibt es in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Eine korrigierte oder spätere Sicherheitsversion des jeweiligen Zweigs nutzen. Ältere Versionen können Backports enthalten; vollständige Paketversion mit Herstellerhinweisen abgleichen. PHP 8.1 und älter haben keinen regulären Upstream-Support. Worker nach dem Update neu starten.
Methoden können unterschiedliche Routen und Filter durchlaufen. Seit PHP 8.4 können Anwendungen mit request_parse_body() Multipart für andere Methoden als POST verarbeiten. Das bedeutet keine automatische PUT- oder PATCH-Verarbeitung in jeder Anwendung. POST-Verhalten belegt keinen Schutz anderer Methoden oder Pfade.
PHP-Laufzeit und Patch-Status als unbestätigt dokumentieren. POST 200 zeigt nur eine Antwort, 405 eine Methodenablehnung auf irgendeiner Ebene. Statische Seiten, andere Laufzeiten und PHP mit verborgenen Merkmalen können dieses Muster erzeugen. Laufzeit auf dem Host prüfen, statt Sicherheit oder eine bestätigte Schwachstelle zu erklären.
Quellen zu Schwachstellen und Behebung wurden am 2026-10-22 geprüft. Externe Beobachtungen sind begrenzt; für operative Entscheidungen gelten aktuelle PHP- und Herstellerhinweise.
Öffentliche Antworten einzeln prüfen, Belege einordnen und Patches anhand der tatsächlichen Serverumgebung verifizieren.