PHP2Shell (CVE-2026-109618, CVE-2026-109619): Was bisher bekannt ist

Was ist über die PHP-Sicherheitslücken CVE-2026-109618 und CVE-2026-109619 bekannt?

Unter dem Namen PHP2Shell kursieren seit dem 20. Oktober 2026 Berichte über zwei kritische Sicherheitslücken im PHP-Kern (CVE-2026-109618 und CVE-2026-109619), die Angreifern das Ausführen eigenen Codes auf dem Webserver ermöglichen sollen. Das PHP-Projekt hat das offizielle Sicherheitsupdate für den 21. Oktober 2026 um 16:00 Uhr MESZ angekündigt. Prüfen Sie jetzt Ihre aktive PHP-Version und bereiten Sie das Server-Update vor.

Stand: 21. Oktober 2026, vormittags. Dieser Artikel beschreibt die Lage vor der offiziellen Patch-Freigabe und wird täglich aktualisiert, sobald gesicherte Erkenntnisse vorliegen. Die meisten derzeit verbreiteten Informationen stammen dabei aus inoffiziellen Kanälen, Foren-Leaks und vorläufigen Analysen. Offiziell gesichert ist bislang allein die Vorankündigung des PHP-Sicherheitsteams auf php.net vom 20. Oktober 2026.

In dieser Meldung kündigt das Team für Mittwoch, den 21. Oktober 2026, um 14:00 Uhr UTC (16:00 Uhr MESZ) ein Sicherheitsrelease für zwei kritische Schwachstellen an. Beide Lücken bewertet das PHP-Projekt nach dem Common Vulnerability Scoring System (CVSS v4.0) mit einem Schweregrad von 9.2 auf einer Skala bis 10,0. Vollständige Details sowie die betroffenen und behobenen Versionen will das Team erst mit dem Release veröffentlichen, behält sich aber eine frühere Freigabe vor, falls Einzelheiten öffentlich werden oder Angriffe auftreten.

Warum sorgt die Ankündigung für solche Unruhe? Nach übereinstimmenden Berichten von Sicherheitsforschern können Angreifer über die beiden öffentlich geführten Schwachstellen – sogenannte Common Vulnerabilities and Exposures (CVE) – ohne Anmeldung über das Netz eigene Befehle auf dem Server ausführen, also eine unauthentifizierte Remote Code Execution (RCE) auslösen. Anders als bei der ähnlich benannten WordPress-Sicherheitslücke wp2shell vom Juli 2026 liegt der Fehler nicht im Content Management System (CMS), sondern tief in der PHP-Laufzeitumgebung selbst.

Was ist offiziell bestätigt und was stammt aus Berichten oder Gerüchten?

Das PHP-Projekt bestätigt am Vormittag des 21. Oktober 2026 offiziell ausschließlich den Release-Termin um 14:00 Uhr UTC (16:00 Uhr MESZ) sowie zwei kritische Schwachstellen mit dem Schweregrad CVSS 9.2. Die Nummern CVE-2026-109618 und CVE-2026-109619 entstammen Berichten von Sicherheitsfirmen und CERT-EU, während der Name PHP2Shell, die Ursache und konkrete Patch-Versionen auf unbestätigte Leaks zurückgehen.

Um in der laufenden Nachrichtenlage keine falschen Entscheidungen zu treffen, hilft der Blick auf die Herkunft der jeweiligen Meldung. Denn nicht jede Zahl im Netz stimmt. Die folgende Übersicht trennt die offiziellen Herstellerangaben von den Einschätzungen namentlich bekannter Sicherheitsfirmen und dem inoffiziellen Rauschen in sozialen Netzwerken.

Drei-Stufen-Überblick: Bestätigte Fakten, Fachberichte und unbestätigte Leaks

Auf der zweiten Ebene stufen etablierte Sicherheitsteams und Behörden die Gefahr als real ein und warnen vor einem extrem kurzen Zeitfenster nach dem Release. Das Computer Emergency Response Team der Europäischen Union (CERT-EU) im Security Advisory 2026-018 ordnet die Ankündigung des PHP-Projekts den beiden Kennungen CVE-2026-109618 und CVE-2026-109619 zu. Gegenüber BleepingComputer bestätigte Benjamin Harris, Geschäftsführer von watchTowr, dass beide Schwachstellen real sind; laut SecurityWeek geht watchTowr davon aus, CVE-2026-109618 bereits reproduziert zu haben. Am Morgen des 21. Oktober meldeten sowohl watchTowr als auch Huntress noch keine Angriffe in freier Wildbahn. Die auf Online-Shops spezialisierte Sicherheitsfirma Sansec erwartet jedoch Massenangriffe binnen 15 Minuten nach dem Release.

Wie kam es überhaupt zu dieser Vorwarnung vor dem eigentlichen Patch? Laut Sansec, Threat Landscape und dem Entwickler Vincent Schmalbach erschien der erste Hinweis am 20. Oktober 2026 um 15:20 Uhr UTC in einem inzwischen entfernten „Tell HN“-Beitrag des Nutzers petecooper auf Hacker News (Eintrag 50167754). Der Beitrag nannte zwei PHP-Lücken mit CVSS 10.0, deren Veröffentlichung unter Sperrfrist (Embargo) für den 22. Oktober um 18:00 Uhr MESZ angesetzt sei. Nachdem sich Screenshots auf X und Mastodon verbreiteten und Sicherheitsforscher Kevin Beaumont das Leck um 16:39 Uhr UTC aufgriff, zog das PHP-Team die Ankündigung um 19:33 Uhr UTC auf den 21. Oktober vor. Wie Sie solche Schweregrade grundsätzlich einordnen, erkläre ich im Ratgeber zu Sicherheitslücken in WordPress-Plugins.

Aus denselben Leaks stammt auch der Name PHP2Shell. Nach Berichten von Sansec und Secure in Seconds kursiert der Screenshot eines gleichnamigen Exploit-Werkzeugs, das dem Team Calif zugeschrieben wird. Dessen Banner behauptet, jede Version ab PHP 5.4.0 sei angreifbar, und ein Video soll erfolgreiche Zugriffe auf Systeme mit WordPress, Magento, MediaWiki, Laravel, Drupal und WHMCS zeigen.

Wie ließ sich die wahrscheinliche Ursache trotz Geheimhaltung so rasch im offenen PHP-Quelltext eingrenzen? Erste Hinweise lieferte SecurityWeek mit dem Bericht über einen Use-After-Free-Fehler (UAF) – dabei greift ein Programm auf Speicherbereiche zu, die bereits wieder freigegeben wurden. Laut IT-Connect brachten der Forscher Kirill Firsov auf X und die japanische Firma GMO Flatt Security die Lücke anschließend mit der Funktion session.upload_progress in Verbindung. Noch konkreter äußerte sich auf X ein Forscher unter dem Namen J4ck3LSyN, über dessen Analyse der Blog Lilting berichtet: Demnach liegt der erste Fehler als Heap-Use-After-Free in der C-Funktion php_session_rfc1867_callback() in der Datei ext/session/session.c, während der zweite im Multipart-Parser für Datei-Uploads ausgelöst wird. Sowohl Forscher von watchTowr als auch einzelne Analysten meldeten schon wenige Stunden nach dem Leak am 20. Oktober, zumindest eine der Schwachstellen im Umfeld von session.upload_progress und dem Multipart-Parser nachgestellt zu haben. Das spricht dafür, dass die kursierenden Leak-Hinweise für die Eingrenzung der verwundbaren Stelle ausreichten – eine Einordnung anhand des zeitlichen Ablaufs, keine bestätigte Angabe.

Besondere Vorsicht gilt bei konkreten Versionsnummern angeblich sicherer Patch-Versionen. Laut den offiziellen Release-Nachrichten auf php.net sowie Beazley Security Labs hat das PHP-Projekt zuletzt am 24. September 2026 die Versionen PHP 8.5.11, 8.4.26, 8.3.35 und 8.2.34 veröffentlicht. Wenn in der Analyse von J4ck3LSyN laut Lilting 8.5.12, 8.4.27, 8.3.36 und 8.2.35 als Zielversionen stehen, sind das zwar rechnerisch plausible Folgeschritte, aber bis 16:00 Uhr nur unbestätigte Schätzungen.

Was sollten Sie jetzt tun? Sofortmaßnahmen nach Betriebsart

Ihr Fahrplan vor und ab 16:00 Uhr MESZ richtet sich danach, wer auf Ihrem System die PHP-Laufzeitumgebung verwaltet. Im klassischen Webhosting und bei Managed WordPress bitten Sie den Anbieter, das Sicherheitsupdate sofort nach der Freigabe einzuspielen, wogegen Sie auf eigenen Servern und in Docker-Containern selbst aktualisieren und die PHP-Dienste anschließend neu starten müssen.

Ein Grundsatz gilt dabei für alle Website-Betreiber gleichermaßen: Sie können PHP2Shell nicht innerhalb Ihrer Website-Dateien beheben. Ein CMS-Update reicht dafür nicht. Wie Sansec und Teramont betonen, hilft weder ein Update von WordPress, Shopware oder Magento noch ein Aufruf von Composer, weil der verwundbare Code im PHP-Interpreter des Servers liegt. Bevor Sie oder Ihr Dienstleister am System arbeiten, sichern Sie den aktuellen Stand vollständig – wie das sauber gelingt, zeigt meine Anleitung zum Erstellen eines WordPress-Backups.

Entscheidungs- und Handlungsmatrix nach Betriebsart

Damit Sie am Nachmittag ohne Hektik vorgehen, arbeiten Sie diese vier Schritte der Reihe nach ab:

1. Aktive PHP-Version und Zuständigkeit prüfen

   Stellen Sie zuerst fest, auf welchem PHP-Zweig Ihre Website läuft und wer den Server verwaltet. In WordPress sehen Sie die Version ohne Zusatzprogramm unter Werkzeuge → Website-Zustand → Bericht → Server (laut Help Net Security). Auf einem eigenen Linux-Server prüfen Sie die Kommandozeilen-Version per SSH mit php -v und in Docker-Umgebungen laut Vincent Schmalbach mit docker run --rm ihr-image php -v, ohne dass dabei Dateien verändert werden.

2. Vollständiges Backup vor dem Eingriff anlegen

   Legen Sie vor jedem Update oder Versionswechsel eine Sicherung Ihrer Dateien und der Datenbank an und speichern Sie diese außerhalb des Webspace. Falls nach einer Umstellung ein älteres Plugin streikt, spielen Sie dieses Backup in wenigen Minuten zurück, statt unter Zeitdruck am offenen System zu suchen.

3. Sicherheitsupdate ab 16:00 Uhr einspielen oder prüfen

   Im Shared Hosting und bei Managed WordPress liegt das Update bei Ihrem Anbieter; fragen Sie beim Support nach, wann der Patch bei Ihnen aktiv ist. Auf eigenen Servern spielen Sie das Update über die Paketverwaltung ein, sobald die gepatchten Pakete nach 16:00 Uhr bereitstehen. Wo ein zeitnahes Patchen öffentlich erreichbarer Anwendungen technisch unmöglich ist, raten CERT-EU, Huntress, Beazley Security Labs und Sicherheitsforscher Andrew Case (laut dem Fachportal Administrator), das System vorübergehend vom öffentlichen Netz zu trennen. PHP-Core-Entwicklerin Gina Peter Banyard räumte laut Vincent Schmalbach allerdings ein, dass ein komplettes Abschalten für die meisten Betreiber im Alltag kaum zumutbar ist.

4. PHP-Prozesse neu starten und Versionsstand kontrollieren

   Ein aktualisiertes Paket auf einem eigenen Server schützt erst, wenn die laufenden Prozesse das neue Programm auch laden. Starten Sie deshalb nach dem Paket-Update zwingend den Dienst php-fpm sowie Apache oder nginx neu (Hinweis von Teramont). Bei Distributionen wie Debian oder Ubuntu kommt eine Besonderheit hinzu: Laut Vincent Schmalbach und Teramont portieren diese Systeme Sicherheitsfixes in bestehende Versionen zurück (Backporting). Dadurch bleibt die vordere Versionsnummer gleich, und erst die Paket-Revision hinter dem Bindestrich in dpkg -l | grep php zeigt den Patch.

Betreiber mit PHP 8.1, 8.0 oder 7.4 stehen vor einem besonderen Problem, weil diese Versionen keine offiziellen Fixes mehr bekommen. Laut der offiziellen Support-Übersicht auf php.net pflegt das PHP-Projekt jeden Zweig zwei Jahre aktiv und zwei weitere Jahre mit Sicherheitsupdates, bevor er sein End of Life (EOL) erreicht. Aktuell erhalten nur PHP 8.2, 8.3, 8.4 und 8.5 Updates von php.net, während PHP 8.1 bereits am 31. Dezember 2025 ausgelaufen ist. Laut dem IT-Portal IT-BOLTWISE und dem Fachportal Administrator zählte die Sicherheitsfirma Mallory am 20. Oktober 2026 über die Suchmaschine Shodan dennoch rund 884.000 über das Internet erreichbare Server mit PHP 8.1 oder älter – gemessen unter etwa 1,5 Millionen Systemen mit sichtbarer Versionsangabe, neben weiteren 740.000 Hosts ohne Versionskennung.

Wenn Sie bei Ihrem Hoster für PHP 8.1 oder 7.4 einen kostenpflichtigen Zusatzdienst nutzen, klären Sie heute beim Anbieter, ob dieser den Patch gegen PHP2Shell zurückportiert. Welche Kosten dabei anfallen und wie Sie kündigen, beschreibe ich unter PHP Extended Support beim Hoster. Für das Update selbst unterscheide ich strikt zwischen zwei Fällen: Ein reines Sicherheitsupdate innerhalb Ihres bestehenden Zweigs (etwa innerhalb von PHP 8.4) sollte sofort und automatisch durchlaufen, weil das Zeitfenster zwischen Bekanntwerden und Ausnutzung einer Lücke schrumpft und jedes Abwarten die Seite offen lässt.

Ein Wechsel der PHP-Hauptversion von 7.4 oder 8.1 nach oben greift dagegen tief in ältere Erweiterungen ein und braucht ein Backup direkt davor. Stellen Sie dabei nicht kurzfristig auf PHP 8.2 um: Für PHP 8.2 endet der Sicherheitssupport laut php.net schon am 31. Dezember 2026 (für PHP 8.3 am 31. Dezember 2027, für PHP 8.4 am 31. Dezember 2028 und für PHP 8.5 am 31. Dezember 2029). Wer jetzt umstellt, sollte gleich auf PHP 8.4 oder 8.5 gehen und PHP 8.3 nur als Zwischenschritt wählen, falls ein wichtiges Plugin unter 8.4 noch streikt. Die Prüfliste dafür finden Sie unter WordPress-PHP-Version aktualisieren.

Hilft das Deaktivieren von session.upload_progress als Übergangslösung?

Das Abschalten von session.upload_progress.enabled wird im Netz als vorläufige Maßnahme diskutiert, ist vom PHP-Projekt aber nicht bestätigt und ersetzt kein Update. Laut der Analyse eines einzelnen Forschers deckt die Einstellung höchstens eine der beiden Lücken ab, während ein falsches php_flag in der .htaccess unter modernem PHP-FPM Ihre gesamte Website sofort mit einem 500-Fehler lahmlegt.

Wie arbeitet diese Upload-Funktion im Hintergrund, und wo lässt sie sich überhaupt schalten? Einen klaren Befund liefert die offizielle PHP-Dokumentation zur Session-Konfiguration: Demnach steht die Einstellung session.upload_progress.enabled standardmäßig auf "1" (aktiviert) und zeichnet den Fortschritt eines Datei-Uploads auf, sobald eine Anfrage die zugehörige POST-Variable mitsendet. Den Ausschlag gibt der Zeitpunkt im Ablauf: Laut PHP-Handbuch schreibt PHP diese Upload-Fortschrittsinformationen bereits in die Session, bevor irgendein PHP-Skript ausgeführt wird. Deshalb trägt die Option den Modus INI_PERDIR – sie lässt sich also nur in der php.ini, der .htaccess, der httpd.conf oder einer .user.ini setzen, nicht aber per ini_set() in der wp-config.php.

Hilft das Abschalten der Option in der Server-Konfiguration nun gegen PHP2Shell? Weder php.net noch watchTowr oder Beazley Security Labs bestätigen einen solchen Workaround. Zwar empfahlen der Sicherheitsforscher Kirill Firsov auf X und die japanische Sicherheitsfirma GMO Flatt Security laut IT-Connect und Lilting das Deaktivieren als vorläufige Bremse, doch räumt GMO Flatt Security selbst ein, keine 100-prozentige Schutzwirkung zusichern zu können. Laut der von Lilting ausgewerteten Analyse des Forschers J4ck3LSyN blockiert das Abschalten von session.upload_progress.enabled ohnehin nur eine der beiden Schwachstellen, während die zweite direkt im Multipart-Parser für Datei-Uploads ausgelöst wird. Auf die Frage im Netz, ob das Deaktivieren der Einstellung ausreiche, antwortete PHP-Core-Entwicklerin Gina Peter Banyard laut dem Entwickler-Blog von Vincent Schmalbach mit dem wörtlichen Satz: „The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much.“

Noch gefährlicher wird der Workaround, wenn Betreiber im Shared Hosting ungeprüfte Befehle aus Foren oder ersten Blogartikeln kopieren. Einzelne Beiträge empfehlen dort seit gestern, die Zeile php_flag session.upload_progress.enabled off oder php_value session.upload_progress.enabled 0 in die .htaccess-Datei im Hauptverzeichnis einzufügen. Doch dieser Rat legt moderne Websites lahm:

„php_value und php_flag in der .htaccess funktionieren nur mit mod_php. Unter PHP-FPM, heute der Normalfall, lösen sie sofort einen 500er aus – typisch, wenn eine ältere Anleitung aus einem Forum kopiert wurde.“

— Sascha Fix

Wie das offizielle PHP-Handbuch zu .user.ini-Dateien bestätigt, greifen .htaccess-Befehle für PHP nur dann, wenn PHP als altes Apache-Modul läuft. Unter CGI/FastCGI und PHP-FPM verarbeitet PHP stattdessen .user.ini-Dateien, die der Server standardmäßig alle 300 Sekunden (5 Minuten, gesteuert über user_ini.cache_ttl) neu einliest. Falls Ihre Website nach einem solchen Eintrag bereits mit einem Serverfehler ausgefallen ist, führt Sie meine Anleitung 500 Error nach .htaccess-Änderung beheben Schritt für Schritt zurück.

Auf einem eigenen Server mit Root-Zugriff kommt eine zweite technische Hürde hinzu, die Vincent Schmalbach im Test dokumentiert hat. Setzen Sie session.upload_progress.enabled = Off lediglich in der allgemeinen php.ini oder einer Drop-in-Datei unter conf.d, kann eine .user.ini im Webverzeichnis die Funktion wegen des Modus INI_PERDIR für einzelne Anfragen wieder einschalten. Wenn Sie die Funktion auf einem eigenen PHP-FPM-Server bis zum Einspielen des Updates um 16:00 Uhr dennoch als zusätzliche Vorsichtsmaßnahme sperren wollen, setzen Sie den Befehl als Administrator-Flag in Ihrer FPM-Pool-Konfiguration (Voraussetzung: Root-Zugriff; Wirkung: schaltet die Upload-Fortschrittsmessung für diesen Pool unkippbar ab; Rückweg: Zeile nach dem PHP-Update löschen und php-fpm neu laden):

php_admin_flag[session.upload_progress.enabled] = off

Auch eine vorgeschaltete Web Application Firewall (WAF) kann helfen, auffällige Upload-Anfragen abzufangen, ersetzt das Einspielen des offiziellen PHP-Updates um 16:00 Uhr jedoch ebenso wenig. Genauso wichtig wie der Schutz vor neuen Anfragen ist nach dem Patch die Kontrolle, ob Ihr Server in der Zwischenzeit bereits angegriffen wurde.

Woran erkennen Sie, ob ein Server bereits kompromittiert wurde?

Einen erfolgreichen Angriff über eine Remote-Code-Execution-Lücke in PHP erkennen Sie vor allem an ungewöhnlichen Unterprozessen des Webservers, neu abgelegten Skriptdateien im Webverzeichnis und verdächtigen POST-Anfragen in den Server-Protokollen. Sichern Sie bei einem Verdacht zuerst alle Dateien, Datenbanken und Logs vollständig, bevor Sie den Server vom Netz trennen oder einzelne Schaddateien löschen.

Bis zum Vormittag des 21. Oktober 2026 haben watchTowr und Huntress noch keine aktive Ausnutzung in freier Wildbahn gemeldet, doch mit der Veröffentlichung der Patches rechnen Sicherheitsforscher binnen Minuten mit Angriffen – Sansec erwartet schon nach 15 Minuten erste Angriffswellen. Sobald Sie Ihr PHP-Update nach 16:00 Uhr eingespielt haben (und erst recht, falls Ihr System länger ungepatcht erreichbar war), sollten Sie deshalb prüfen, ob bereits jemand die Lücke genutzt hat.

Wonach suchen Sie auf einem eigenen Server zuerst? Wenn ein Angreifer über PHP Betriebssystembefehle mittels Funktionen wie exec(), system(), shell_exec(), passthru() oder popen() ausführt, ruft PHP unter Linux im Hintergrund /bin/sh -c auf. Laut den Sicherheitsanalysen von Huntress und PenTestIT verrät sich ein solcher Einbruch dadurch, dass ein PHP-Worker-Prozess wie php-fpm, php-cgi, httpd oder apache2 plötzlich ungewöhnliche Kindprozesse startet:

• Kommandozeilen-Shells: sh, bash, cmd.exe oder powershell.exe direkt unterhalb von php-fpm oder dem Webserver-Prozess.
• Skript-Interpreter und Netzwerkwerkzeuge: Aufrufe von python, perl, curl, wget, nc (Netcat) oder certutil.exe, mit denen Angreifer weiteren Schadcode nachladen.
• Auffällige Dateien und Zeitpunkte: Neu angelegte oder veränderte PHP-Dateien im Webverzeichnis – insbesondere eine eingeschleuste Webshell in Upload- oder Cache-Ordnern –, unbekannte Cronjobs, geplante Aufgaben sowie neu angelegte Administratorkonten.

Im klassischen Shared Hosting sehen Sie keine laufenden Prozessbäume, wohl aber die Zugriffs- und Fehlerprotokolle sowie die Dateistruktur per SFTP. Wie Sie die Protokolldateien auswerten, erkläre ich unter WordPress Error-Logs finden und verstehen.

Stoßen Sie bei dieser Kontrolle auf fremde Skriptdateien oder verdächtige Prozesse, gilt eine eiserne Reihenfolge: Löschen Sie nicht sofort einzelne Dateien und installieren Sie Ihr CMS nicht einfach über die bestehende Seite. Wie auch Huntress empfiehlt, trennen Sie einen betroffenen Server vom öffentlichen Netz und bewahren Sie alle Webserver- und PHP-Logs auf. Bevor ich an einer verdächtigen Website etwas ändere, ziehe ich immer zuerst eine vollständige Sicherung von Dateien und Datenbank: So gibt es jederzeit einen Weg zurück, und die Spuren zeigen später, auf welchem Weg der Angreifer hereingekommen ist.

Denken Sie außerdem an den Unterschied zwischen der Sicherheitslücke und einer bereits abgelegten Hintertür. Das PHP-Update um 16:00 Uhr schließt zwar das Einfallstor im PHP-Interpreter, nimmt einem Angreifer aber weder eine bereits hochgeladene Webshell noch ein angelegtes Administratorkonto weg. Den kompletten Ablauf zur Spurensuche und Bereinigung finden Sie im Ratgeber Website gehackt? Malware erkennen und entfernen.

Selbst absichern oder Unterstützung anfragen?

Ob Sie die Absicherung rund um PHP2Shell selbst übernehmen oder abgeben sollten, entscheidet sich an Ihrer Hosting-Umgebung, Ihren Server-Zugängen und bereits sichtbaren Fehlern. Während im Webhosting mit aktuellem PHP 8.3 oder 8.4 die Versionskontrolle im Kundenmenü genügt, ist Unterstützung sinnvoll, sobald ein 500-Fehler nach Konfigurationsänderungen auftritt oder Spuren auf einen Einbruch hindeuten.

Für viele Website-Betreiber lässt sich die heutige Sicherheitslage mit wenigen Handgriffen selbst klären. Sie brauchen keine externe Unterstützung, wenn Ihre Website in einem regulären Webhosting-Paket oder Managed-WordPress-Tarif bereits auf PHP 8.3, 8.4 oder 8.5 läuft, Ihr Hoster das Sicherheitsupdate nach 16:00 Uhr zentral einspielt und Ihre Seite danach fehlerfrei lädt. Gleiches gilt, wenn Sie Ihren eigenen Linux-Server oder Ihre Container-Umgebung routiniert per SSH verwalten und eine getestete Sicherung griffbereit haben.

Anders sieht es aus, wenn Sie bei der Vorbereitung oder beim Update auf eines dieser drei Hindernisse stoßen:

1. Die Website fällt nach einer Änderung aus: Sie haben vorsorglich eine .htaccess- oder .user.ini-Anweisung aus dem Netz eingetragen oder im Kundenmenü die PHP-Version umgestellt, und die Seite antwortet nur noch mit einem 500 Internal Server Error oder einer weißen Seite. In meiner Website-Reparatur übernehme ich die Fehleranalyse und Reparatur zum Festpreis von 99 € (kleine Textänderung 49 €, jeweils netto zzgl. 19 % MwSt., Stand Oktober 2026; die Einschätzung vorab ist kostenlos).
2. Die Website hängt auf PHP 8.1 oder älter fest: Ihr System bekommt von php.net keinen offiziellen Patch mehr, und es ist unklar, ob Ihre Plugins und Ihr Theme den Sprung auf PHP 8.4 überstehen, ohne dass der laufende Betrieb oder Bestellungen abbrechen.
3. Es gibt Hinweise auf einen Einbruch: Sie entdecken nach dem Bekanntwerden der Lücke unbekannte PHP-Dateien, fremde Prozesse unter php-fpm oder unerklärliche Zugriffe in den Logs. Auf meiner Leistungsseite zur WordPress-Hack-Hilfe ist die Erstanalyse kostenlos; die Bereinigung, bei der ich die gefundene Malware und die erkennbaren Hintertüren entferne, Zugänge zurücksetze und alle Schritte dokumentiere, kostet als Festpreis ab 299 € netto zzgl. 19 % USt. (Stand Oktober 2026).

Falls ein Server mit personenbezogenen Kundendaten – etwa aus einem Online-Shop, einem Mitgliederbereich oder gespeicherten Kontaktanfragen – tatsächlich kompromittiert wurde, können zudem Meldepflichten wegen einer Datenschutzverletzung nach Art. 33 DSGVO bestehen. Ob in Ihrem Fall eine Meldung nötig ist, ist eine rechtliche Frage, die Sie mit Ihrem Datenschutzbeauftragten oder einem Fachanwalt klären; wenn Sie Strafanzeige erstatten oder ein Gutachten für ein Gerichtsverfahren benötigen, ist ein zertifizierter IT-Forensiker der richtige Ansprechpartner. Meinen technischen Abschlussbericht aus der Bereinigung können Sie für diese Klärung verwenden.