PHP2Shell: Was jetzt zu tun ist.

das wichtigste in kürze

apt update
apt upgrade

Quellen: PHP-Advisory, Wiz, Sansec, Cloudflare, The Hacker News, Meow Apps, Amazon, BSI

update: neue erkenntnisse

Quellen: Datadog Security Labs, Cybersecurity News, ikow/php2shell-poc, SecurityWeek, watchTowr-FAQ, X-Post mit dem Screenshot, Amazon Threat Intelligence, BSI, RUS-CERT, daubois.dev, NBC News, Rescana, Tenable, heise, it-daily, Berliner Zeitung, Tagesspiegel (dpa)

was ist php2shell?

PHP ist die Programmiersprache hinter rund 70 Prozent aller Websites, darunter WordPress, WooCommerce, Shopware, Drupal, Joomla, TYPO3 und Nextcloud. „PHP2Shell“ ist der Sammelname für zwei CVE-Nummern, die zusammen vier Memory-Corruption-Bugs im PHP-Core abdecken. Der Name kommt vom Exploit-Skript „php2shell“, mit dem die Forschenden ihre Exploits demonstriert haben.

Der CVSS-Vektor lautet bei beiden AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H. Übersetzt: Attack Vector Network, keine Privileges und keine User Interaction nötig, volle Auswirkung auf Confidentiality, Integrity und Availability. Die „Attack Complexity: High“ heißt nach meiner Lesart, dass ein Angriff auf Build, Speicher und Timing abgestimmt werden muss. Das passt zum PHP-Advisory, laut dem die Zuverlässigkeit von Build, Extensions und Memory-Allocator abhängt. Das bremst Angreifer, schützt aber nicht: Funktionierende Exploits sind demonstriert.

Anfangs kursierte ein CVSS-Score von 10.0, unter anderem von watchTowr. Offiziell vergibt das PHP-Team 9.2. Und nicht verwechseln: „WP2Shell“ ist eine andere Lücke in WordPress selbst, die ein normales WordPress-Update behebt. PHP2Shell kann nur dein Hoster oder Server-Admin beheben.

Quellen: php2shell.com, Wiz, beide GitHub-Advisories des PHP-Teams, The Hacker News, Meow Apps

chronologie

Die Bug-Klasse ist seit über 20 Jahren bekannt und galt lange als praktisch nicht ausnutzbar. So kam es zum Emergency-Release. Alle Zeiten in UTC.

technischer hintergrund

Wer nur wissen will, was zu tun ist, springt weiter zu den Abschnitten für Website-Betreiber und Admins.

Das gemeinsame Grundproblem

PHP arbeitet mit sogenannten Workern: Ein Prozess beantwortet nacheinander viele Requests und räumt dazwischen den Speicher auf. Läuft ein Request in einen Fatal Error, typischerweise das Überschreiten von memory_limit oder einen Timeout, bricht PHP die laufende Operation per longjmp hart ab. Passiert das im falschen Moment, bleiben halb fertige Datenstrukturen oder Pointer auf bereits freigegebenen Speicher zurück, und der nächste Request behandelt diesen Speicher als gültig. Fachleute nennen das „Use-after-free“.

Entscheidend: Alle bekannten Auslöser stecken im Parsing von multipart/form-data, also Formularen und Datei-Uploads. PHP verarbeitet diese Daten, bevor der Code deiner Website läuft. Deshalb ist eine Seite auch dann angreifbar, wenn ihr eigener Code fehlerfrei ist.

Quellen: beide GitHub-Advisories des PHP-Teams, Wiz, Sansec

CVE-2026-109618: OOM-Corruption mitten in der Initialisierung

Laut PHP ist Speicher eines Requests manchmal schon erreichbar, bevor er fertig initialisiert ist. Schlägt genau dann irgendeine Allocation fehl, verlässt PHP den Vorgang per longjmp, und beim Request-Shutdown wird mit ungültigen Daten gearbeitet. Calif beschreibt ein Beispiel: Eine Hashtable erhöht ihren Zähler, bevor der neue Eintrag fertig ist. Kommt dazwischen der OOM, verarbeitet der Cleanup einen halb fertigen Eintrag.

Angreifer lösen den OOM gezielt aus, etwa mit Multipart-Requests ohne brauchbare Content-Length, die an der Größenprüfung vorbeikommen, mit beliebig vielen Headern pro Part, mit leeren File-Feldern, die nicht gegen das Upload-Limit zählen, und mit verschachtelten Array-Feldnamen, die den Aufwand vervielfachen.

Dazu kommt ein Memory Leak wie bei Heartbleed: Ein Stale Pointer auf die Session-ID kann einen abgebrochenen Request überleben. Ein späterer Request bekommt dann im PHPSESSID-Cookie Inhalte aus fremdem Speicher zurück, auch wenn die Website gar keine Sessions nutzt.

Zur Zuordnung: Wiz und Sansec rechnen das Memory Leak und den Bug im Session Upload Progress CVE-2026-109618 zu. Das PHP-Advisory führt den Session Upload Progress unter CVE-2026-109619. Ich halte mich bei den Beschreibungen an die offiziellen PHP-Texte.

Bestätigt ist laut PHP Remote Code Execution mit den Rechten des Webserver-Benutzers, ohne Login, getestet gegen Apache mit mod_php in der Default-Konfiguration. mod_php räumt auch nach einem fehlgeschlagenen Request-Startup auf und ist dadurch angreifbar, bevor irgendein Website-Code läuft. PHP-FPM beendet den Prozess in diesem Fall, ist laut Quellcode-Analyse aber nach einem normalen Startup trotzdem anfällig. Für FrankenPHP und LiteSpeed gilt das laut PHP vermutlich ähnlich.

Quellen: GHSA-w8hw-w9fx-j79w, Calif, Wiz, Sansec

CVE-2026-109619: Stale Global State aus dem vorherigen Request

Bestimmter globaler State, etwa zu Error-Handling, Sessions oder Extensions, überlebt den Request, der ihn erzeugt hat. Für einen Exploit braucht es zwei Requests an denselben Prozess: einen, der den State durch einen Fatal Error zurücklässt, und einen zweiten, der ihn benutzt, bevor er zurückgesetzt wird.

Mehrere Worker und regelmäßige Restarts der Prozesse senken die Erfolgsquote, beseitigen das Risiko aber nicht.

Quellen: GHSA-6wmf-4rv5-p3rp, Wiz, JFrog

Was das Update ändert

Ein OOM bricht PHP nicht mehr per longjmp mitten in einer Operation ab. Stattdessen gibt es ein Soft Limit, an dem PHP am nächsten sicheren Punkt stoppt, und ein Hard Limit, an dem sich der Prozess sofort mit _exit(137) beendet. Persistenter State wird beim Request-Shutdown zurückgesetzt. Eine Nebenwirkung: Wird das Hard Limit erreicht, laufen keine Shutdown-Funktionen mehr. Wer darüber Logging oder Cleanup erledigt, sollte das wissen.

Quellen: GHSA-w8hw-w9fx-j79w, JFrog, php2shell.com, Datadog

betroffene versionen

Wichtig bei Paketen aus Linux-Distributionen: Debian, Ubuntu und andere backporten Fixes oft, ohne die Versionsnummer zu ändern. php -v zeigt dann eine alte Nummer, obwohl das Paket sicher ist. Prüf in dem Fall den Changelog des Pakets.

Wichtig bei 7.4, 8.0 und 8.1: Das PHP-Team hat dafür keinen vollständigen Fix veröffentlicht, sondern laut Commit eine „Minimal mitigation for EOL version“. Sie deckt beide CVEs ab, schaltet aber Session Upload Progress fest ab, egal was in der php.ini steht. Sury nutzt diesen Patch, das habe ich im Quellpaket für 7.4 nachgesehen. Für künftige Lücken gibt es in diesen Zweigen keine Garantie, plan also den Umstieg auf 8.3 oder neuer.

Quellen: GitHub-Advisories des PHP-Teams, SOCRadar (Support-Daten), php.net, Calif, The Hacker News, Commit des Minimal-Patches, deb.sury.org #145

Server-Varianten (SAPIs)

Die Voraussetzungen sind in der Standardeinstellung erfüllt: Session Upload Progress ist per Default aktiv, und praktisch jede Website nimmt Formulardaten an.

Quellen: php.net, Calif, Upwind, JFrog

Betroffene Anwendungen

Weil die Lücke in PHP steckt, ist jede PHP-Anwendung betroffen. Vorgeführt wurden Angriffe ohne Login auf WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, Magento 2.4.9, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 und WHMCS. Das sind nur Beispiele. Shopware, WooCommerce, TYPO3, Contao und Eigenentwicklungen sind genauso betroffen.

Vergiss die versteckten Installationen nicht: Appliances und Admin-Oberflächen mit Embedded PHP, Windows-Programme mit mitgeliefertem PHP, Control-Panels, alte Testseiten und Subdomains. Laut einer Shodan-Auswertung laufen rund 884.000 öffentlich erreichbare Server mit PHP 8.1 oder älter, also ohne offizielles Update.

Quellen: Calif, Sansec, php2shell.com, NCSC-NL, SOCRadar (Zahlen von Mallory.ai), Vincent Schmalbach

stand bei hostern und anbietern

Momentaufnahme vom 21. Oktober 2026. Prüf immer die aktuelle Seite deines Anbieters.

Linux-Distributionen

Community-Patches

Auf GitHub gibt es Community-Repositories mit eigenen Patches für alte Versionen, etwa Anton-Barinov/php2shell-patches für PHP 5.6 bis 8.1. Nach eigener Angabe kombiniert es offizielle und Community-Backports und lässt Uploads samt Fortschrittsbalken funktionieren. Das PHP-Team steht nicht dahinter, und ich habe den Code nicht geprüft. Meine Empfehlung: nur als letzter Ausweg, wenn es weder Pakete der Distribution noch einen Anbieter gibt, und nur nach eigenem Code-Review. Auf GitHub kursieren zu PHP2Shell auch gefälschte Exploits mit Schadcode (JFrog), führ also nichts ungeprüft aus.

Hoster

Die meisten großen Hoster spielen Patches oder WAF-Regeln ein, darunter Cloudways, DreamHost, Kinsta, SiteGround, WP Engine, OVHcloud, Pantheon und Rocket.net. Bei GoDaddy-VPS musst du PHP selbst aktualisieren (Meow Apps). Bei Shared Hosting gilt: Frag nach, ob die sichere Version für jede deiner Domains aktiv ist. Ein Versionswechsel im Kundenmenü beweist das nicht (Vincent Schmalbach).

Google Cloud

Google Cloud selbst ist nicht verwundbar, PHP-Anwendungen der Kunden schon. App Engine Standard mit PHP 8.2 oder neuer wird automatisch aktualisiert, App Engine Flexible nicht. Cloud Run wird automatisch aktualisiert, wenn Automatic Base Image Updates aktiv sind, sonst musst du neu builden und neu deployen. Bei GKE und eigenen Container-Images ebenfalls neu builden und ausrollen. PHP 8.1 und älter bleiben verwundbar (Google Cloud, Bulletin GCP-2026-070).

Cloudflare und andere Schutzdienste

Cloudflare hat seit 21. Oktober, 03:02 UTC, WAF-Regeln gegen die bekannten Angriffsvektoren aktiv, auch im Free-Plan ohne eigenes Zutun. Bezahlkunden sollen prüfen, dass das Managed Ruleset auf Block statt nur auf Log steht. Angreifer haben ihre Requests bereits angepasst, um die Regeln zu umgehen (Cloudflare). Akamai, AWS, Fastly, Imperva, Microsoft und Vercel haben ebenfalls Schutzmaßnahmen veröffentlicht (Wiz). Eine WAF ersetzt das Update nicht: Ist dein Server zusätzlich direkt über seine IP-Adresse erreichbar, läuft der Angriff an ihr vorbei.

Docker

Ein neues Image nur zu pullen reicht nicht. Bau deine Images auf dem gepatchten Base-Image neu und erstell die Container neu (Meow Apps). FrankenPHP braucht eine neue FrankenPHP-Version, Laravel Vapor die gepatchte Runtime plus neues Deployment (Vincent Schmalbach).

Quellen: Meow Apps, Vincent Schmalbach, php.net, Google Cloud, Cloudflare, Wiz, Ubuntu, Debian Security Tracker, deb.sury.org #145, deb.sury.org #146, AlmaLinux, CloudLinux, NCSC-NL, ma.ttias.be, InMotion Hosting, Anton-Barinov/php2shell-patches, heise

wird die lücke schon ausgenutzt?

Ja, es gibt Angriffsversuche. Bestätigte erfolgreiche Einbrüche waren bis zum Abend des 21. Oktober nicht öffentlich dokumentiert.

Vorsicht vor gefälschten Exploits: JFrog berichtet von angeblichen Test-Exploits auf GitHub mit verstecktem Code. Wer „mal eben testen“ will, führt im Zweifel fremden Code auf dem eigenen Rechner aus. Seit dem 21. Oktober gibt es aber auch echte öffentliche PoCs, siehe Update.

Zum Vergleich: Bei der letzten großen PHP-Lücke, CVE-2024-4577 im Juni 2024, sah Akamai Angriffsversuche innerhalb von 24 Stunden nach der Veröffentlichung.

Quellen: Cloudflare, Sansec, The Hacker News, watchTowr, SOCRadar, Help Net Security, JFrog, Cybersecurity News, Amazon Threat Intelligence, Rescana

was website-betreiber jetzt tun sollten

Du hast eine WordPress-Seite, einen Shop oder eine andere PHP-Website und kümmerst dich nicht selbst um den Server? Dann gehst du so vor:

Ein Update von WordPress, Plugins oder Theme behebt PHP2Shell nicht. Das muss auf dem Server passieren.

Quellen: Meow Apps, php.net

was server-admins jetzt tun sollten

1. Bestandsaufnahme

Erfasse jede PHP-Installation, öffentlich erreichbare zuerst: Pakete der Distribution, mehrere PHP-Versionen nebeneinander, Docker-Images, Control-Panels, gebündelte PHP-Binaries, Staging- und Testsysteme und alte Subdomains. Das britische NCSC nennt diese Bestandsaufnahme als ersten Schritt. Die Schleife unten ist meine Ergänzung.

# Installierte PHP-Zweige (Debian/Ubuntu)
ls /etc/php

# Versionen aller PHP-Programme
for b in /usr/bin/php* /usr/sbin/php-fpm*; do [ -x "$b" ] && echo "$b: $($b -v 2>/dev/null | head -1)"; done

2. Logs sichern

Kopier vor dem Update die Logs von Webserver und PHP ab dem 20. Oktober 2026 weg. Updates und Log-Rotation können sie sonst löschen.

3. Aktualisieren

sudo apt update
apt-cache policy php8.3-fpm      # installiert und verfügbar vergleichen
apt-mark showhold                 # gesperrte Pakete blockieren Updates still
sudo apt upgrade

# Ist die Korrektur im Paket? Änderungsprotokoll prüfen
zcat /usr/share/doc/php8.3-fpm/changelog.Debian.gz | head -20

Aktualisier alle installierten PHP-Versionen, nicht nur die gerade genutzte. Update-Buttons in Control-Panels installieren nur, was das eingestellte Repository anbietet. Wer selbst kompiliert, findet die Quellen auf php.net und die Minimal-Patches für 7.4, 8.0 und 8.1 auf GitHub.

4. Alles neu starten

Ein installiertes Paket schützt erst, wenn die alten Prozesse beendet sind.

sudo systemctl restart php8.3-fpm    # je PHP-Version
sudo systemctl restart apache2       # bei mod_php

# Prozesse, die noch das alte Programm nutzen
ls -l /proc/*/exe 2>/dev/null | grep -i 'php.*deleted'

Auch Queue-Worker, Laravel Horizon, Octane und Scheduler neu starten. Leg zum Prüfen keine öffentliche phpinfo()-Seite an.

5. Nach dem Update aufräumen

Quellen: Vincent Schmalbach, UK NCSC, php2shell.com, php.net, GHSA-6wmf-4rv5-p3rp

plesk: so kommt das update wirklich an

Plesk ist bei kleinen Agenturen und Hostern weit verbreitet, und gerade hier gab es am 21. Oktober Verwirrung.

Meine Erfahrung: Auf meinem Plesk-Server unter Linux zeigte der Plesk-Updater keine Updates an. Erst diese zwei Befehle auf der Konsole haben die korrigierten PHP-Pakete installiert:

apt update
apt upgrade

Damit bin ich nicht allein. Im Plesk-Forum berichten mehrere Admins dasselbe: „In some cases, users won't see the update on their GUI.“ Andere sahen die Updates dagegen im Updater. Verlass dich also nicht auf die GUI, sondern prüf die installierte Version auf der Konsole.

Drei PHP-Baustellen auf einem Plesk-Server

Stand bei Plesk am 21. Oktober

Nach dem Update der Website-PHP-Versionen zeigten Ausgaben im Forum für sw-engine weiterhin PHP 8.4.24 oder 8.4.25. Das Panel war also zunächst noch nicht abgesichert, obwohl die Websites es schon waren. Den Plesk-Support-Artikel konnte ich nur über ein Suchmaschinen-Snippet lesen, prüf den aktuellen Stand deshalb direkt dort.

Schritt für Schritt unter Debian oder Ubuntu

Erst den Plesk-Installer anstoßen, dann die Repositories aktualisieren. Diese Reihenfolge hat im Forum mehreren Admins geholfen. Laut Plesk spielt das Plesk-Update außerdem fehlende GPG-Keys ein.

sudo plesk installer update
sudo apt update
sudo apt upgrade

# Meldet der Installer "BUSY: Update operation was locked"
sudo plesk installer stop
sudo plesk installer update

Erscheint bei apt update der Fehler NO_PUBKEY für die Plesk-PHP-Quellen, half im Forum, den GPG-Key von Plesk neu einzuspielen. Das ist ein Community-Workaround, kein offizieller Plesk-Weg:

sudo cp /etc/apt/keyrings/plesk.gpg /etc/apt/keyrings/plesk.gpg.bak
curl -fsSL https://autoinstall.plesk.com/plesk.gpg | gpg --dearmor | sudo tee /etc/apt/keyrings/plesk.gpg > /dev/null
sudo apt update
sudo apt upgrade

Danach die installierten Versionen prüfen. Erwartet werden 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 und neuer:

for p in /opt/plesk/php/*/bin/php; do echo "$p: $($p -v | head -1)"; done
apt policy plesk-php83-fpm

Dann die PHP-Dienste neu starten. Die Dienstnamen entsprechen dem Plesk-Standard, das ist meine Ergänzung:

sudo systemctl restart plesk-php83-fpm
sudo systemctl restart plesk-php84-fpm
sudo systemctl restart apache2

Quellen: Plesk-Forum, Seite 3, Plesk-Forum, Seite 4, Plesk-Support-Artikel, php.net, Plesk-Repository

workarounds, falls du nicht sofort aktualisieren kannst

Laut PHP gibt es keinen vollständigen Workaround über die Konfiguration. Alle folgenden Maßnahmen schließen nur einzelne Angriffsvektoren. Das britische NCSC rät: Wenn du weder aktualisieren noch die Mitigations schnell genug umsetzen kannst, erwäge, das System vom Netz zu nehmen. CERT-EU rät, betroffene Anwendungen bis zum Update vom öffentlichen Netz abzuschotten. Das BSI rät ebenso zur Trennung vom Internet, und laut RUS-CERT reichen die Mitigations nicht, um eine öffentlich erreichbare PHP-Anwendung zu betreiben.

Gegen CVE-2026-109618

; php.ini
memory_limit = -1

; PHP-FPM-Pool, von Anwendungen nicht überschreibbar
php_admin_value[memory_limit] = -1

; kleine Obergrenzen für Formulardaten
post_max_size = 8M         ; ohne Datei-Uploads
; post_max_size = 32M      ; mit Datei-Uploads
upload_max_filesize = 2M   ; muss unter post_max_size liegen

Achtung: Mit memory_limit = -1 kann ein einzelner Request den ganzen RAM belegen. PHP empfiehlt als Grenze ein Container- oder cgroup-Limit. Auf keinen Fall RLIMIT_AS oder RLIMIT_DATA verwenden, die lösen genau den verwundbaren Fall aus. Zusätzlich sollte der Webserver Body-Größe, Anzahl der Felder, Multipart-Parts und Header begrenzen, auch für Requests ohne Content-Length.

Gegen CVE-2026-109619

session.upload_progress.enabled = 0
fatal_error_backtraces = 0   ; nur PHP 8.5

; im PHP-FPM-Pool fest verankern
php_admin_flag[session.upload_progress.enabled] = off

Setz das in der php.ini, im FPM-Pool oder in der Server-Konfiguration und starte danach alle PHP-Prozesse neu. Verlass dich nicht auf ini_set() oder .user.ini, die greifen laut PHP zu spät. Entfern außerdem ungültige oder veraltete PHP-Einstellungen, die bei jedem Request Warnungen erzeugen. Bei PHP-FPM hilft pm.max_requests = 1, weil dann kein Prozess zwei Requests bedient. Das kostet aber deutlich Performance.

Bei Shared Hosting ohne Root-Zugang schlagen Vincent Schmalbach und das Tool php-fix eine .user.ini vor. PHP rät ausdrücklich davon ab, sich darauf zu verlassen. Meine Empfehlung: als Notbehelf besser als nichts, aber den Hoster zum Update drängen.

Die harte Variante: Multipart-Requests blocken

Alle bekannten Auslöser sind Requests mit dem Content-Type multipart/form-data. Wer sie am Webserver abweist, blockiert die bekannten Angriffsvektoren. Die Nebenwirkung: Datei-Uploads funktionieren nicht mehr, also etwa die WordPress-Mediathek, und je nach Plugin auch manche Kontaktformulare. Normale Seiten, Logins und APIs laufen weiter.

# nginx: /etc/nginx/conf.d/block-multipart.conf
map $http_content_type $block_multipart {
    default       0;
    ~*multipart   1;
}
# in jedem server-Block, der an PHP weitergibt
if ($block_multipart) { return 444; }

# Apache 2.4
<If "req('Content-Type') =~ /multipart/i">
    Require all denied
</If>

# Caddy und FrankenPHP
@multipart header_regexp Content-Type (?i)multipart
respond @multipart 403

# LiteSpeed (.htaccess, oberhalb des WordPress-Blocks)
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart [NC]
RewriteRule ^ - [F]

Testen, auch direkt gegen die IP-Adresse des Servers, und die Sperre nach dem Update wieder entfernen:

curl -sS -o /dev/null -w '%{http_code}\n' -X PUT -F test=1 https://deinedomain.de/index.php
curl -sS -o /dev/null -w '%{http_code}\n' -X PUT -F test=1 --resolve deinedomain.de:443:SERVER-IP https://deinedomain.de/index.php

Weitere Möglichkeiten: nicht benötigte Testseiten sofort abschalten, Tools wie phpMyAdmin auf die eigene IP-Adresse beschränken, im Notfall PHP stoppen und eine statische Wartungsseite ausliefern. Der Wartungsmodus von WordPress reicht dafür nicht.

Quellen: php.net, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, UK NCSC, SOCRadar, Vincent Schmalbach, Sansec, php-fix, BSI, RUS-CERT

was nicht schützt

Quellen: Vincent Schmalbach, Meow Apps, Sansec, php.net, The Hacker News, JFrog

woran du einen angriff erkennst

Hinweise auf Angriffsversuche

Laut Wiz finden sich im Application-Log kaum Spuren, weil alles darunter passiert. Diese Hinweise beweisen keinen Angriff, und ihr Fehlen beweist keine Sicherheit. Ein erster Blick in die Logs, meine Ergänzung, Pfade je nach System anpassen:

grep -E "Allowed memory size|SIGSEGV|exited on signal" /var/log/php*-fpm.log
grep -i "multipart" /var/log/nginx/access.log | awk '$9 ~ /^5/'

Hinweise auf einen erfolgreichen Einbruch

Prüf rückwirkend ab etwa 20. Oktober 2026, 15:00 UTC. Ab da kursierten die CVE-Nummern öffentlich.

Findest du etwas: Server isolieren, Logs sichern, neu aufsetzen statt flicken und alle Secrets rotieren, die der PHP-Benutzer lesen konnte, also Datenbank-Passwörter, API-Keys und App-Keys. Wegen des Memory Leaks kann das nach meiner Einschätzung auch ohne Code Execution sinnvoll sein, wenn Angriffsversuche sichtbar waren. Zum Prüfen gibt es Community-Tools wie php2shell-guard und php2shell-triage. Lies den Code, bevor du sie einsetzt.

Quellen: Wiz, php2shell.com, Upwind, Vincent Schmalbach, SOCRadar, PHP Foundation, Datadog, Amazon Threat Intelligence

die rolle der ki

PHP2Shell ist einer der ersten Fälle, in denen KI-Modelle entscheidend geholfen haben, eine seit Jahrzehnten bekannte, aber als zu aufwendig geltende Bug-Klasse in einen funktionierenden Exploit zu verwandeln. Laut Wiz lag der nötige Aufwand früher nahe an der Grenze dessen, was Menschen praktisch leisten können.

Meine Einschätzung: Die Zeit zwischen „theoretisch problematisch“ und „ausnutzbar“ schrumpft. Regelmäßige Updates werden damit noch wichtiger.

Quellen: Help Net Security, Wiz, Google Cloud, Calif, The Hacker News

auswirkungen weltweit

Viele Organisationen haben Dienste vorsorglich abgeschaltet, nicht wegen bestätigter Einbrüche.

Der Sicherheitsforscher Hal Pomeranz warnt vor dem langen Nachlauf: „So many embedded installations out there that will never be patched.“

Quellen: The Hacker News, Brussels Times, Global Banking & Finance Review, Wikimedia, ITmedia, Help Net Security, NBC News, heise, it-daily, Tagesspiegel (dpa)

häufige fragen

plesk installer update
apt update
apt upgrade

Quellen: php2shell.com, Meow Apps, The Hacker News, Cloudflare, Plesk-Forum, SOCRadar

fazit

PHP2Shell gehört zu den schwersten Lücken, die PHP je hatte: aus der Ferne, ohne Login, vor jedem Website-Code und in der Default-Konfiguration ausnutzbar. Der Patch ist da, er wirkt aber nur, wenn sie auf jedem PHP-Server eingespielt wird und alle PHP-Prozesse neu starten. Auf Plesk-Servern solltest du dich dabei nicht auf den Updater verlassen, sondern auf der Konsole nachprüfen.

Du bist unsicher, ob deine Website betroffen ist? Einen ersten Eindruck gibt der kostenlose Website-Check. Gern prüfe ich PHP-Version, Hosting und Spuren eines Angriffs für dich und kümmere mich mit deinem Hoster um das Update, schreib mir einfach. Mehr zu Pflege und Betrieb findest du unter Websites und Shops.

alle quellen

Alle Quellen abgerufen am 21. und 22. Oktober 2026.