Skip to main content
Google Bewertungen

PHP2Shell-Sicherheitslücke: prüfen, patchen, Spuren finden

Die PHP2Shell-Sicherheitslücke steckt in PHP selbst. Zwei kritische Fehler, CVE-2026-109618 und CVE-2026-109619, erlauben Angreifern ohne Login, Code auf dem Webserver auszuführen. Seit dem 21. Oktober 2026 gibt es Fix-Versionen, und wir prüfen Ihren Server, spielen den Patch ein und suchen nach Spuren eines Angriffs.

Termin vereinbaren Bin ich betroffen?

30 Minuten · unverbindlich · Sie sprechen mit einem Entwickler

Proaktives Monitoring
Einmaliger PHP2Shell-Sicherheitscheck
Patch-Management
Integritätsprüfung

Laufende Lage: PHP2Shell entwickelt sich weiter, wir beobachten die Situation fortlaufend. Alle Angaben auf dieser Seite entsprechen dem Stand vom 21. Oktober 2026, abends.

01

Was am 20. und 21. Oktober 2026 passiert ist

Am Vormittag des 20. Oktober 2026 kündigte ein anonymer Beitrag zwei kritische PHP-Lücken mit ihren CVE-Nummern an, ohne technische Details. Der Beitrag verschwand, Screenshots davon nicht.

PHP zog das für den 22. Oktober geplante Release vor und veröffentlichte die Fixes am 21. Oktober 2026. Den Namen PHP2Shell haben die Forscher vergeben, PHP selbst spricht nur von den CVEs.

PunktStand 21.10.2026
LückenCVE-2026-109618 "RCE via OOM corruption" und CVE-2026-109619 "RCE via stale global state"
BewertungPHP als vergebende Stelle (CNA): CVSS 4.0 mit 9.2, "Critical". NVD: CVSS 3.1 mit 9.8, "Critical". Red Hat: CVSS 3.1 mit 8.1, "Important". Die im Leak genannte 10.0 stammt nicht von PHP.
BetroffenPHP 8.5 vor 8.5.12, 8.4 vor 8.4.27, 8.3 vor 8.3.36, 8.2 vor 8.2.35. Dazu 8.1, 8.0 und 7.4, die kein offizielles Release erhalten. Laut Forschern sind auch 5.4 bis 7.3 betroffen, ohne Fix.
Fix-Versionen8.5.12, 8.4.27, 8.3.36 und 8.2.35, veröffentlicht am 21.10.2026. Für 8.1, 8.0 und 7.4 gibt es nur Backports im Quellcode.
Betroffene SAPIsAlle Installationen, die Web-Requests bedienen: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht PHP bei mod_php. Die CLI nennt keine Quelle als betroffen.
Voraussetzung für AngreiferNetzwerkzugriff auf die Website. Kein Login, keine Mitwirkung eines Nutzers.
FolgeCodeausführung mit den Rechten des Web-Users, zum Beispiel www-data. Bei CVE-2026-109619 zusätzlich das Auslesen von Speicherinhalten.

Nicht verwechseln: wp2shell ist eine andere Lücke im WordPress-Core vom Juli 2026. Die Primärquellen zur PHP2Shell-Sicherheitslücke:

02

Was hinter der PHP-Sicherheitslücke steckt

Was ist eine PHP-Shell?

Eine PHP-Shell, auch Webshell genannt, ist ein Skript auf einem öffentlich erreichbaren Webserver, über das Angreifer Befehle auf dem System ausführen. Meist ist es eine unauffällige .php-Datei in Upload-, Cache- oder Plugin-Ordnern. Der Code ist oft mehrfach kodiert, damit er bei einer Sichtprüfung nicht auffällt.

MITRE ATT&CK führt Webshells als eigene Technik (T1505.003), weil Angreifer sie für dauerhaften Zugang nutzen. Für PHP2Shell dokumentiert bis zum 21.10.2026 keine Quelle einen konkreten Webshell-Fund. Die Codeausführung, die beide Lücken ermöglichen, ist aber genau der Schritt, mit dem so eine Datei auf den Server kommt.

Ablauf des Angriffs: Ein Request mit multipart/form-data erreicht einen PHP-Worker. Beim Einlesen läuft der Speicher über, oder ein fataler Fehler hinterlässt einen veralteten Zustand für den nächsten Request im selben Worker. Beides führt zu Codeausführung und damit zu einer Shell mit den Rechten des Webservers.REQUESTPOST ohne Loginmultipart/form-dataPHP-WORKERFPM, mod_php, CGIparst den Body, bevorIhr Code startetCVE-2026-109618Speicher läuft überhalbfertige Daten gelten beimAufräumen als gültigCVE-2026-109619Zustand bleibt stehender nächste Request im selbenWorker nutzt freien SpeicherERGEBNISShell alswww-data

So funktioniert PHP2Shell

CVE-2026-109618 betrifft den Moment, in dem PHP der Speicher ausgeht. PHP bricht den Request dann hart ab. Manchmal ist interner Speicher zu diesem Zeitpunkt erst halb vorbereitet, und das Aufräumen am Ende liest diese halbfertigen Daten als gültig. Daraus entsteht Speicherkorruption bis hin zur Codeausführung.

CVE-2026-109619 nutzt aus, dass ein PHP-Worker viele Requests nacheinander bearbeitet. Nach einem fatalen Fehler zeigt ein globaler Zustand noch auf Speicher, der schon freigegeben ist. Der nächste Request im selben Worker greift darauf zu.

Laut dem offiziellen PHP-Advisory gehört der Pfad über Session Upload Progress zu dieser Lücke. Einige Forscher ordnen ihn anders zu, maßgeblich ist die Zuordnung von PHP.

Warum Multipart-Requests der Schlüssel sind

Alle bekannten Auslöser sind Requests mit einem multipart/form-data-Body, also dem Format, in dem Formulare Dateien hochladen. PHP verarbeitet diesen Body, bevor eine einzige Zeile Ihrer Anwendung läuft. Ihr Anwendungscode muss deshalb keinen Fehler enthalten, damit die Website angreifbar ist. Ein Update von WordPress, Shop oder Plugins schließt die Lücke nicht.

Einfach ist der Angriff nicht. Die CVSS-Vektoren von PHP stufen die Komplexität als hoch ein, die Zuverlässigkeit hängt von Build, Extensions und Speicherlayout ab. Wiz hat die Angriffe gegen WordPress, Drupal und Joomla in deren Docker-Images mit dem Tag :latest demonstriert. Sansec zeigt im Labor weitere Systeme, darunter Magento, Nextcloud, Laravel und Symfony.

Das Speicher-Leak über die Session

CVE-2026-109619 erlaubt neben der Codeausführung auch das Auslesen von Speicher. Darin können Passwörter, Tokens, API-Keys und private TLS-Schlüssel liegen. Ein Teil davon kommt laut Wiz im PHPSESSID-Cookie der Antwort zurück, und das auch dann, wenn die Anwendung gar keine Session startet. Bei konkretem Verdacht tauschen Sie Zugangsdaten deshalb aus.

Wer betroffen ist und wer handeln muss

Wer den Patch gegen die PHP2Shell-Sicherheitslücke einspielt, hängt vom Betriebsmodell ab. Websites, die vollständig ohne PHP ausgeliefert werden, sind nicht betroffen. Für Shared Hosting zeigt eine Übersicht, was die großen Hoster gemeldet haben.

BetriebsmodellWer patchtWas Sie tun
Shared HostingIhr HosterWas Sie tunFragen Sie nach, welche PHP-Version mit Fix für Ihr Paket läuft und ob die Worker neu gestartet wurden. Prüfen Sie Ihre Zugänge zu CMS, FTP und Datenbank.
Managed ServerIhr DienstleisterWas Sie tunLassen Sie sich Paketversion und Neustart schriftlich bestätigen. Klären Sie, wer die Spurensuche übernimmt.
Eigener VPS oder Root-ServerSie selbstWas Sie tunSpielen Sie das Distributionspaket mit Backport ein, starten Sie alle PHP-Worker neu und prüfen Sie die Logs.
Docker oder ContainerWer die Images bautWas Sie tunBauen Sie das Image auf einer gepatchten Basis neu und rollen Sie es aus. Ein Neustart des alten Containers lädt keinen neuen Code.
PleskPlesk liefert, Sie oder Ihr Admin installierenWas Sie tunPlesk hat am 21.10.2026 gepatchte Handler für PHP 8.2 bis 8.5 bereitgestellt. EOL-Handler für 7.4, 8.0 und 8.1 kommen mit gleicher Versionsnummer und neuem Build-Datum. Das panel-eigene PHP (sw-engine) ist ebenfalls betroffen, Plesk hat die Hotfixes 18.0.80#11 und 18.0.81#4 angekündigt.
03

Bin ich von der PHP2Shell-Sicherheitslücke betroffen?

Betroffen ist jede PHP-Installation, die Web-Requests bedient und weder eine Fix-Version (8.5.12, 8.4.27, 8.3.36, 8.2.35) noch ein Distributionspaket mit Backport nutzt. Entscheidend ist der Code, den die laufenden Worker geladen haben. PHP schreibt dazu, es gebe keine vollständige Abhilfe außer dem Update.

  1. 01

    Prüfen Sie die Version der Web-SAPI.

    php -v zeigt nur die Kommandozeile, die eine andere Version nutzen kann als PHP-FPM oder mod_php. Legen Sie für einen kurzen Test eine Datei mit phpinfo() unter einem zufälligen Namen an, rufen Sie sie einmal auf und löschen Sie sie sofort wieder. So bleibt Ihre Konfiguration nicht öffentlich. Weitere Wege über WordPress oder das Hosting-Panel zeigt der Ratgeber PHP-Version Ihrer Website herausfinden.

  2. 02

    Erkennen Sie Backports der Distribution.

    Distributionen schließen Lücken oft, ohne die Upstream-Versionsnummer zu übernehmen. Prüfen Sie deshalb das Changelog auf die CVE-Nummern, etwa mit zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz oder rpm -q --changelog php-fpm | head -5.

  3. 03

    Gleichen Sie den Paketstand ab.

    Debian 13 liefert php8.4 8.4.27-1~deb13u1 (DSA-6574-1), Debian 12 php8.2 8.2.35-1~deb12u1 (DLA-4848-1), RHEL 9 das Erratum RHSA-2026:87072. Ubuntu hat am 21.10.2026 die Hinweise USN-8948-1 und USN-8948-2 veröffentlicht. Remi lieferte an diesem Tag kein Update, Sury nannte kein Datum. Für Debian 11 gibt es seit dem Ende von Debian LTS am 31.08.2026 Korrekturen nur noch über das kostenpflichtige Freexian ELTS.

  4. 04

    Starten Sie alle PHP-Worker neu.

    Ein installiertes Paket wirkt erst, wenn FPM-Pools und Apache neu gestartet sind. needrestart -b -r l listet Prozesse, die noch den alten Code im Speicher haben.

  5. 05

    Bauen Sie Docker-Images neu.

    Die offiziellen php-Images mit 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie wordpress, drupal und joomla:latest wurden am 21.10.2026 neu gebaut. Bauen Sie Ihre eigenen Images darauf neu, zum Beispiel mit docker build --pull, und rollen Sie sie aus.

  6. 06

    Denken Sie an Sonderinstanzen.

    Bei Plesk gehören die PHP-Handler und das Panel-PHP sw-engine dazu. Prüfen Sie auch PHP-Versionen, die für einzelne Projekte parallel installiert sind.

  7. 07

    Kontrollieren Sie die Wirkung.

    Fragen Sie die Version erneut über den Webserver ab und führen Sie needrestart noch einmal aus. Erst wenn beide Prüfungen sauber sind, ist der Patch aktiv.

Fix-Version für Ihren Branch

Wählen Sie den PHP-Branch, den Ihre Web-SAPI nutzt.

Noch kein Branch gewählt.

Fix-Version

oder ein Distributionspaket mit Backport. Danach alle PHP-Worker neu starten.

kein offizielles Release

Für diesen Branch gibt es nur Backports im Quellcode. Zu PHP 8.1, 8.0 und 7.4

Wenn das Update nicht sofort möglich ist

Es gibt Übergangsmaßnahmen, aber PHP nennt sie ausdrücklich keine vollständige Lösung. Sie senken das Risiko für einzelne Angriffswege und machen eine Installation nicht sicher. Nur das Update schließt die Lücken.

Gegen CVE-2026-109618 setzen Sie memory_limit=-1 so, dass Anwendungen den Wert nicht überschreiben können, zum Beispiel per php_admin_value im FPM-Pool oder in der Apache-Konfiguration. Damit gilt keine Speichergrenze pro Request mehr. PHP empfiehlt deshalb ein Limit über Container oder cgroup. RLIMIT_AS oder RLIMIT_DATA dürfen Sie dafür nicht verwenden, sie lösen genau den verwundbaren Pfad aus.

Dazu kommt post_max_size: 8M, wenn die Website keine Uploads braucht, sonst 32M. upload_max_filesize bleibt unter diesem Wert. Begrenzen Sie Requests auch am Webserver oder Proxy. Wo die Website keine Uploads braucht, können Sie Multipart-Requests dort sperren. Diese Sperre legt allerdings Upload-Formulare und Checkout lahm.

Gegen CVE-2026-109619 setzen Sie session.upload_progress.enabled=0 in der php.ini oder in der Pool-Konfiguration, nicht per ini_set() oder .user.ini, und starten alle Worker neu. Nur unter PHP 8.5 kommt fatal_error_backtraces=0 hinzu. Das GitHub-Advisory nennt außerdem pm.max_requests=1, das kostet aber Leistung.

error_reporting, display_errors oder der Wartungsmodus von WordPress und Magento helfen nicht. BSI und CERT-EU empfehlen, Systeme, die sich nicht patchen lassen, vorübergehend vom Internet zu trennen. Nach dem Patch setzen Sie memory_limit laut Sansec wieder auf einen endlichen Wert.

PHP 8.1, 8.0 und 7.4

Für diese Branches hat PHP kein Release veröffentlicht, nur Backports im Quellcode. Die Forscher halten auch PHP 5.4 bis 7.3 für betroffen, einen Fix gibt es dort nicht. Alle diese Branches haben ihr Support-Ende erreicht. Unser Ratgeber zeigt, welche PHP-Versionen noch Sicherheitsupdates bekommen, und nennt die Stichtage.

Wer eine solche Version betreibt, braucht mehr als einen Patch. Dann ist es Zeit, die PHP-Anwendung auf eine unterstützte Version heben zu lassen. Beachten Sie dabei, dass auch PHP 8.2 am 31.12.2026 das Support-Ende erreicht.

04

Woran Sie einen Angriff über PHP2Shell erkennen

Offizielle Indicators of Compromise gab es bis zum 21.10.2026 nicht. BSI, CERT-EU und watchTowr veröffentlichten keine, Huntress hat Sigma- und YARA-Regeln angekündigt. Eine erfolgreiche Kompromittierung bestätigte bis dahin keine Quelle.

Die Spurensuche nach PHP2Shell stützt sich deshalb auf Logs, Prozesse und Dateien. PHP selbst warnt, dass saubere Logs keine Sicherheit beweisen.

Sichern Sie Web- und PHP-Logs sowie die Konfiguration, bevor Sie etwas ändern. Bei einem konkreten Verdacht trennen Sie den Server vom Netz, so empfehlen es Huntress und watchTowr.

HTTP- und Fehler-Logs

Achten Sie auf ungewöhnliche Multipart-Requests, auf die Meldungen wie "Allowed memory size exhausted" oder eine Häufung von HTTP 500 folgen. Ein zweites Signal sind auffällig große oder fehlerhafte PHPSESSID-Cookies in den Antworten des Servers, denn darüber kann das Speicher-Leak laufen. Auch PHP-Worker, die ohne erkennbaren Grund ständig neu starten, gehören auf die Liste. In den Logs der Anwendung finden Sie dagegen wenig, weil die Fehler unterhalb von WordPress oder Laravel passieren.

Prozesse beobachten

Huntress erwartet, dass eine erfolgreiche Ausnutzung vor allem als verdächtiger Kindprozess von PHP sichtbar wird. Gemeint sind Fälle, in denen php-fpm, php-cgi, httpd oder apache2 Programme wie sh, bash, python, perl, curl, wget oder nc starten. Typische erste Befehle eines Angreifers sind whoami, id und uname -a. In Kommandozeilen sind /dev/tcp/, fsockopen und mkfifo Warnzeichen.

Für Linux gibt es den process-watcher von Florian Roth. Betreiben Sie ihn zuerst im Beobachtungsmodus, er meldet nur und verhindert nichts. Das Muster entspricht der Beschreibung von MITRE ATT&CK T1505.003.

Dateien gegen bekannte Stände prüfen

Die NSA und die australische ASD nennen den Vergleich mit einer bekannten sauberen Version als wirksamste Methode, Webshells zu finden. Bei WordPress vergleicht wp core verify-checksums die Core-Dateien mit den Prüfsummen von WordPress.org, mit --include-root meldet der Befehl auch fremde Dateien im Hauptverzeichnis. wp plugin verify-checksums --all prüft Plugins, soweit WordPress.org für sie Prüfsummen hat.

Eigene Anwendungen prüfen Sie gegen das Git-Repository, aus dem sie ausgerollt werden. git status und git diff zeigen jede Abweichung. Suchen Sie zusätzlich nach neuen .php- und .sh-Dateien im Webroot. Bedenken Sie, dass eine Codeausführung auch ganz im Speicher bleiben kann, ohne Datei auf der Platte.

Scanner als Ergänzung

Scanner finden bekannte Muster, aber nicht alles. Die NSA stellt YARA-Regeln für Webshells bereit und nennt Signaturen selbst "bestenfalls teilweise wirksam". PHP Malware Finder arbeitet ebenfalls mit YARA, das Projekt ist seit dem 11.02.2024 archiviert. Linux Malware Detect (maldet) ist auf Shared Hosting ausgelegt und kann Dateien per inotify laufend überwachen.

Cronjobs, Konten und Zugangsdaten

Prüfen Sie, ob neue Cronjobs oder neue Benutzerkonten angelegt wurden, auch für den Web-User. Weil CVE-2026-109619 Speicherinhalte offenlegen kann, tauschen Sie nach einem Verdacht Datenbank-Passwörter, API-Keys und TLS-Schlüssel. Danach machen Sie bestehende Sessions ungültig und erneuern bei WordPress die Salts in der wp-config.php.

Dokumentieren Sie den Vorfall technisch mit Zeitraum, betroffenen Systemen und getauschten Zugangsdaten. Ob daraus eine Meldepflicht nach der DSGVO folgt, entscheiden Sie als Verantwortlicher gemeinsam mit Ihrem Datenschutzbeauftragten oder Ihrer Anwältin bzw. Ihrem Anwalt. Wir liefern die technischen Fakten dafür, die rechtliche Bewertung liegt bei Ihnen.

05

Die Nacht vom 20. auf den 21. Oktober 2026: so haben wir betreute Kunden begleitet

Zwischen der ersten Meldung und dem offiziellen Patch lag gut ein Tag, ein großer Teil davon in der Nacht. Schon vor dem Release kursierten erste Hinweise auf funktionierende Exploits. Die Zeitleiste zeigt, was öffentlich geschah und was wir für die Systeme getan haben, die wir betreuen. Alle Uhrzeiten sind in MESZ angegeben. Unsere eigenen Schritte nennen wir meist nach Phasen. Warum dabei Stunden zählen, erklärt der Ratgeber dazu, wie KI das Tempo bei Sicherheitslücken verändert.

Einsatzbericht · 20./21.10.2026

PHP2Shell, Systeme, die wir betreuen

Laufende Lage, wir beobachten fortlaufend.

Uhrzeiten in MESZ
Lücken
CVE-2026-109618
CVE-2026-109619
Fix-Versionen
8.5.12, 8.4.27
8.3.36, 8.2.35
Stand
21.10.2026, 23:00 Uhr MESZ

20. Oktober 2026

  1. vormittags

    Ein anonymer Beitrag kündigt zwei kritische PHP-Lücken mit CVE-Nummern an. Er wird gelöscht, Screenshots verbreiten sich.

    Quelle: Huntress, The Hacker News
  2. tagsüber

    watchTowr bestätigt die Lücke öffentlich und reproduziert CVE-2026-109618, ohne Details zu nennen. Ein Screenshot eines PHP2Shell-Werkzeugs und ein kurzes Exploit-Video machen die Runde, einen vollständigen öffentlichen Exploit gibt es nicht.

    Quelle: SecurityWeek, watchTowr
  3. 21:33

    PHP zieht das Release auf den 21.10., 16:00 Uhr vor und behält sich ein früheres Release vor.

    Quelle: php.net
  4. 22:33

    CERT-EU veröffentlicht das Security Advisory 2026-018.

    Quelle: cert.europa.eu
  5. abends
    Digital Heroes

    Wir richten ein KI-gestütztes Monitoring für die Nacht ein. Zusätzlich zu den bestehenden Backups erstellen wir frische Sicherungen.

  6. Nacht
    Digital Heroes

    Wir überwachen die betreuten Systeme und werten die Meldungen des Monitorings aus.

21. Oktober 2026

  1. 05:02

    Cloudflare aktiviert WAF-Regeln gegen PHP2Shell für alle Pläne, auch für den kostenlosen.

    Quelle: Cloudflare-Blog
  2. gegen 05:10
    Digital Heroes

    Wenige Minuten nach der Bereitstellung aktivieren wir die neuen Cloudflare-WAF-Regeln auf den betreuten Systemen und prüfen, dass sie greifen.

  3. 09:43

    Cloudflare meldet erste Angriffsversuche, noch vor dem Patch.

    Quelle: Sansec, zitiert Cloudflare
  4. vormittags

    Das BSI veröffentlicht die Cybersicherheitswarnung 2026-297981-1032 und sieht unverzüglichen Handlungsbedarf.

    Quelle: bsi.bund.de
  5. etwa 15:00 bis 16:00

    PHP veröffentlicht 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die Quellen nennen für das Release unterschiedliche Uhrzeiten.

    Quelle: php.net, AlmaLinux, Huntress
  6. mit dem Release

    Das PHP-Sicherheitsteam veröffentlicht im Advisory auf php.net und in den GitHub Security Advisories offizielle Workarounds für php.ini und FPM. Eine vollständige Lösung ist laut PHP nur das Update.

    Quelle: php.net, GitHub
  7. zum Release
    Digital Heroes

    Wir rollen die neuen PHP-Versionen auf den Managed Servern aus, die wir betreuen, und begleiten und überwachen den Rollout.

  8. bis gepatchte Pakete verfügbar sind
    Digital Heroes

    Wo es noch keine gepatchten Pakete gab, etwa in Verwaltungspanels für Managed Hosting oder bei Docker-Images, setzen wir die offiziellen Workarounds sofort um. Das läuft KI-gestützt und parallel auf den betreuten Hosting-Systemen, erst im Staging, dann in Produktion. So hatten auch bei vielen Projekten alle betreuten Systeme nach kurzer Zeit die empfohlenen Sofortmaßnahmen, bis sie vollständig gepatcht waren.

  9. 16:17

    Die NVD veröffentlicht beide CVEs.

    Quelle: NVD
  10. 17:22

    BSI-Warnung in Version 1.1: Patches verfügbar, keine bestätigten Ausnutzungen, aber unbestätigte Berichte über existierende Exploits.

    Quelle: bsi.bund.de
  11. 18:16

    Die ersten gepatchten offiziellen php-Images für amd64 erscheinen auf Docker Hub, rund zweieinhalb Stunden nach dem Release.

    Quelle: Docker Hub
  12. 19:17 bis 19:32

    Die offiziellen php-Images für 8.2, 8.3 und 8.4 stehen für die gängigen Tags bereit, darunter die Varianten fpm, apache und alpine.

    Quelle: Docker Hub
  13. 20:11 bis 20:42

    Die offiziellen Images drupal, joomla und wordpress mit dem Tag latest sind neu gebaut.

    Quelle: Docker Hub
  14. 20:46

    Plesk meldet gepatchte PHP-Handler.

    Quelle: Plesk
  15. 20:54 bis 21:02

    Auch die Images für php 8.5.12 und php:latest stehen bereit, rund fünf Stunden nach dem Release.

    Quelle: Docker Hub
  16. nach dem Rollout
    Digital Heroes

    Spurensuche auf den aktualisierten Systemen, siehe unten.

  17. fortlaufend
    Digital Heroes

    Wir überwachen die Systeme weiter und verfolgen die Lage über mehrere Kanäle: Hinweise der Hersteller, CERTs und die Security-Community. Dabei achten wir auf neue Angriffsmuster und weitere betroffene Komponenten.

  • Öffentliche Meldung mit Uhrzeit aus der Quelle
  • Uhrzeit nur ungefähr bekannt
  • Unser Schritt
  • Unser Schritt, Uhrzeit ungefähr

Nach dem Rollout haben wir die Dateien der betreuten Websites gescannt. WordPress-Installationen haben wir mit den Prüfsummen der offiziellen Releases verglichen, individuelle Anwendungen mit den Git-Repositories, aus denen sie ausgerollt werden. Auffällige Dateien prüfen wir von Hand auf Schadcode. Dazu liefen Security-Scanner mit Mustererkennung.

Wo wir Zugriff auf den Server haben, beobachten Prozess-Watcher ungewöhnliche Forks von PHP-Prozessen und Aufrufe wie whoami. Die HTTP-Logs haben wir auf die Muster aus dem Abschnitt zur Spurensuche ausgewertet. Ein Patch schließt die Lücke, er sagt aber nichts darüber, ob sie vorher genutzt wurde. Dieser Frage gehen die Prüfungen nach dem Rollout nach.

06

Was wir bei der PHP2Shell-Sicherheitslücke für Sie übernehmen

Wir übernehmen die technische Seite und berichten Ihnen zu jedem Schritt den Stand. Die Leistungen lassen sich einzeln beauftragen oder als laufende Betreuung kombinieren.

Proaktives Monitoring

Wir überwachen Ihre Systeme auch außerhalb der Bürozeiten, so wie in der Nacht vom 20. auf den 21. Oktober 2026, als PHP2Shell vor dem Patch bekannt wurde. Unsere Verfügbarkeitsüberwachung betreiben wir selbst gehostet auf Servern bei Hetzner in Deutschland.

Einmaliger PHP2Shell-Sicherheitscheck

Wir prüfen die PHP-Version jeder Web-SAPI samt Backports, den Neustart-Status der Worker, Logs, Prozesse und die Integrität der Dateien. Sie erhalten ein schriftliches Protokoll mit Befund und Empfehlung. Der Check eignet sich auch, wenn Ihr Hoster gepatcht hat und Sie das Ergebnis unabhängig bestätigt haben möchten.

Patch-Management

Wir spielen Distributionspakete ein, bauen Docker-Images neu, aktualisieren Plesk-Handler und starten alle Worker neu. Danach kontrollieren wir, dass der neue Code wirklich läuft, und nehmen Übergangs-Workarounds zurück. Für WordPress-Websites, die wir dauerhaft betreuen sollen, gibt es unsere WordPress-Wartung mit Sicherheitsupdates nach Dringlichkeit.

Backups

Vor jedem Eingriff legen wir eine zusätzliche Sicherung an, getrennt vom Produktivsystem. Diese Sicherung kommt zu Ihren bestehenden Backups hinzu. So bleibt ein fehlgeschlagenes Update ein überschaubarer Rückschritt.

WAF-Konfiguration

Bei Cloudflare prüfen wir die Managed Rules, stellen sie auf Blockieren und filtern die Security-Events nach den Regel-IDs. Cloudflare ist ein US-Anbieter. Wenn Ihre Daten nicht über ein US-CDN laufen sollen, setzen wir einen selbst gehosteten Reverse-Proxy mit nginx oder HAProxy auf, der Multipart-Requests begrenzt oder sperrt und in der EU oder bei Hetzner in Deutschland läuft.

Für die Wahl des Standorts helfen die Kriterien für einen Hosting-Standort in Deutschland. Eine WAF ist dabei immer eine Überbrückung. Cloudflare passt die Regeln laufend an, weil Angreifer ihre Payloads verändern.

Integritätsprüfung

Wir vergleichen WordPress mit den offiziellen Prüfsummen und eigene Anwendungen mit dem Git-Repository, aus dem sie kommen. Scanner mit Mustererkennung ergänzen den Vergleich, auffällige Dateien sehen wir uns einzeln an. Das Ergebnis steht im Protokoll, mit Dateipfad und Befund.

Unterstützung im Verdachtsfall

Wir sichern Logs, isolieren das betroffene System und tauschen Zugangsdaten und Schlüssel. Danach bereinigen oder ersetzen wir das System und dokumentieren den Vorfall technisch, damit Sie eine belastbare Grundlage für Ihre weiteren Entscheidungen haben.

Digital Heroes ist eine inhabergeführte Digitalagentur, gegründet 2013, mit Sitz in Hamburg und bundesweit tätig. Wir entwickeln und betreuen PHP-Websites und Anwendungen nach hohen, aktuellen Sicherheitsstandards. Mehr dazu steht auf der Seite über unsere Leistungen für Webdesign und Webentwicklung. Wo Ihre Systeme laufen, entscheiden Sie: bei uns auf Servern in Deutschland, in der EU oder auf Ihrer eigenen Infrastruktur. Cloudflare setzen wir auf Wunsch als CDN und WAF davor.

Termin vereinbaren
07

So läuft Ihr PHP2Shell-Sicherheitscheck ab

Vom ersten Gespräch bis zum Protokoll zur PHP2Shell-Sicherheitslücke sind es vier Schritte.

  1. 01

    Termin vereinbaren.

    Sie buchen online ein kurzes Erstgespräch. Wir klären, was bei Ihnen läuft und wie dringend die Lage ist.

  2. 02

    Bestandsaufnahme.

    Wir erfassen PHP-Version, Hoster oder Server, CMS bzw. Framework und die Art Ihres Zugriffs. Wie viel Arbeit folgt, hängt stark vom System ab. Sie erfahren, welche Zugänge wir brauchen, und wir nennen Umfang und Aufwand, bevor wir anfangen.

  3. 03

    Prüfung und Patch.

    Wir spielen den Patch ein oder kontrollieren den Stand Ihres Hosters, starten alle Worker neu und suchen nach Spuren, wie oben beschrieben. Für PHP 8.1 und älter gibt es keinen offiziellen Patch. Dann braucht oft die Anwendung selbst ein Update, und wir heben sie auf eine unterstützte PHP-Version, auch wenn es Legacy-Software ist.

  4. 04

    Protokoll und nächste Schritte.

    Sie erhalten das Ergebnis schriftlich, mit Empfehlungen. Das kann die Umstellung einer Anwendung auf PHP 8.2 oder neuer sein oder eine laufende Betreuung.

Wie groß der Aufwand ist

  1. Günstigster Fall

    Update und Neustart

    Fix-Version einspielen, alle PHP-Worker neu starten, fertig.

  2. Mittlerer Fall

    Umgebung anpassen

    Konfiguration anpassen, Docker-Images neu bauen, Plugins und Abhängigkeiten aktualisieren.

  3. Aufwendigster Fall

    Legacy-Portierung

    Die ganze Anwendung auf eine unterstützte PHP-Version heben. Das ist unsere Portierung von Legacy-Software auf unterstützte PHP-Versionen. Lohnt sich der Umbau nicht mehr, ist eine Neuentwicklung als Individualsoftware der Weg.

Der Aufwand ist sehr individuell. Deshalb nennen wir keine Pauschalen, sondern machen Ihnen ein Angebot für Ihr System.

Auch der aufwendigste Fall ist für uns lösbar. Wir arbeiten KI-gestützt und damit schnell, und wenn es eilt, arbeiten wir auch nachts. Nacht- und Notfalleinsätze berechnen wir nach Absprache mit Aufschlag.

Lage per E-Mail schildern
08

Fragen zur PHP2Shell-Sicherheitslücke, die uns Kunden stellen

PHP2Shell-Sicherheitscheck: Termin vereinbaren

Sie buchen online ein kurzes Erstgespräch. Wir klären, was bei Ihnen läuft und wie dringend die Lage ist.

Wir übernehmen die technische Seite und berichten Ihnen zu jedem Schritt den Stand.
Wir nennen Umfang und Aufwand, bevor wir anfangen.
Sie erhalten das Ergebnis schriftlich, mit Empfehlungen.
Unverbindlich anfragen 👋

Suchen Sie sich direkt einen freien Termin für ein 30-minütiges Erstgespräch aus, oder schreiben Sie uns. Wir melden uns in der Regel innerhalb von 24 Stunden. Dauert es länger, sagen wir Ihnen Bescheid.

Termin vereinbaren Per E-Mail anfragen

Kostenloses Erstgespräch · info@digital-heroes.co