PHP2Shell: Wie wir die WordPress-Websites unserer Kunden ohne Ausfallzeit geschützt haben

Am 21. Oktober 2026 wurde unter dem Namen PHP2Shell eine der schwerwiegendsten PHP-Schwachstellen der letzten Jahre bekannt. Während viele Website-Betreiber auf Social Media über plötzliche Server-Downtimes klagten oder stundenlang in Support-Warteschleifen feststeckten, liefen die WordPress-Instanzen auf unserer Infrastruktur geräuschlos weiter.

Hier erfährst du, was genau hinter PHP2Shell steckt, warum herkömmliche Sicherheits-Plugins hier machtlos sind und wie unser Tech-Team die Websites unserer Kunden schon vor den offiziellen Sicherheitsupdates serverseitig abgeschirmt hat.

„Riesiges Lob an euch alle. Von den vielen Hostern, die ich nutze, habt ihr mit Abstand am schnellsten reagiert und gepatcht – und die Plattform blieb durchgehend erreichbar. Einige Mitbewerber sind immer noch offline…“ – Feedback eines Kunden am Abend des 21. Oktober

Was genau ist PHP2Shell?

Hinter dem Namen PHP2Shell verbergen sich zwei Schwachstellen im PHP-Core, CVE-2026-109618 und CVE-2026-109619. Die Einstufung vom PHP Security Team mit einem Schweregrad von 9.2 (von 10) zeigt, wie kritisch das Problem ist: Es handelt sich um eine sogenannte Pre-Authentication Remote Code Execution (Pre-Auth RCE).

Das bedeutet auf Deutsch:

1. Kein Login nötig: Ein Angreifer muss weder ein Kundenkonto noch Zugangsdaten zum WordPress-Admin besitzen.
2. Ausführung von Fremdcode: Durch speziell manipulierte HTTP-Anfragen an den Server kann bösartiger Code direkt im Kontext des Webserver-Prozesses ausgeführt werden.
3. Volle Systemkontrolle als Risiko: Gelingt die Ausführung, können Angreifer Daten manipulieren, Hintertüren installieren oder die Serverressourcen für bösartige Zwecke kapern.

Warum WordPress-Security-Plugins hier machtlos sind

Viele WordPress-Betreiber verlassen sich auf bekannte Security-Plugins wie Wordfence oder Solid Security. Gegen PHP2Shell bieten diese Tools jedoch keinen verlässlichen Schutz.

Ein Sicherheits-Plugin wird erst aktiv, wenn WordPress bereits geladen ist und PHP-Code verarbeitet. Die Schwachstelle sitzt jedoch eine Ebene tiefer – direkt in der PHP-Laufzeitumgebung des Webservers. Ein Angriff auf dieser Ebene sorgt häufig dafür, dass WordPress gar nicht erst vollständig geladen wird. Echter Schutz gegen solche Zero-Day-Gefahren sind nur auf Server-Ebene möglich.

Welche Websites sind betroffen?

Das Problem betrifft nahezu alle verbreiteten PHP-Zweige – zurück bis zu alten Versionen wie PHP 5.4. Offizielle Sicherheits-Releases wurden für die aktiv unterstützten Versionen bereitgestellt (u. a. PHP 8.2, 8.3 und 8.4).

Besonders heikel ist die Situation im klassischen Shared Hosting:

Das Nachbarschafts-Risiko: Wenn sich dutzende Kunden dieselbe Server-Instanz teilen und ein Account über die Schwachstelle kompromittiert wird, ist der gesamte Server gefährdet.

Raidboxes-Architektur: Klassisches Shared Hosting gibt es bei uns nicht. Dank unserer Container-Infrastruktur läuft ausnahmslos jede Box in einer eigenen, voneinander isolierten Umgebung. Webserver, Datenbank und Caching-Dienste sind strikt voneinander getrennt. Durch diese Architektur ist selbst im theoretischen Fall einer Kompromittierung ein Überspringen auf benachbarte Kunden-Websites technisch ausgeschlossen.

Wie wir bei Raidboxes mit PHP2Shell umgegangen sind

Dass unsere Kunden den 21. Oktober entspannt verbringen konnten, lag an einer schnellen Rettungskette zwischen unserem Tech-Team und der Sicherheitsinfrastruktur von team.blue.

Die Timeline des 21. Oktober:

• Vormittag – Früherkennung: Sicherheitsforscher registrieren weltweit erste automatisierte Angriffswellen. BSI und CERT-EU veröffentlichen Warnungen der höchsten Stufe. Erste Hoster schalten ganze Serverpools präventiv ab; Behörden und Plattformen gehen weltweit in den Notbetrieb.
• Vormittag – Präventiver Schutzschild: Stunden bevor offizielle Sicherheits-Releases überhaupt existieren, reagiert unser Tech-Team. Wir rollen serverseitige Filterregeln und Ratenbegrenzungen über die Flotte aus. Sie schirmen die bekannten Einfallstore ab – bei 100 % Uptime für alle Kunden-Boxen.
• 11:51 Uhr – Transparenz im Support: Der Support informiert anfragende Kunden über Schutzmaßnahmen, die Systemstabilität.
• 15:30 Uhr – PHP zieht den Release vor:
  Aufgrund massiver Leaks und weltweiter Angriffe zieht das offizielle PHP-Team den Release-Plan vor und veröffentlicht Notfall-Patches (8.2.35, 8.3.36, 8.4.27, 8.5.12).
• 16:15 Uhr – Flotten-Rollout abgeschlossen: 45 Minuten nach Code-Veröffentlichung schließt Raidboxes den vollautomatisierten Rollout der Patches für alle Versionen ab PHP 8.2 ab – zeitlich noch vor den finalen BSI-Handlungsempfehlungen. Zu diesem Zeitpunkt rollen die schwersten Angriffe durch das weltweite Netz; das Angriffsfenster bei Raidboxes ist bereits geschlossen.

Schutz schon vor dem offiziellen Patch (Virtual Patching)

Als die Warnungen aufliefen, gab es noch keine fertigen PHP-Updates zum Download. Hätten wir gewartet, wären Raidboxes Websites stundenlang ungeschützt gewesen.

Noch am Vormittag hat unser Tech-Team in Zusammenarbeit mit der Threat Intelligence von team.blue serverseitige Konfigurationsanpassungen direkt an den Webserver-Directives und Netzwerk-Layern vorgenommen. Diese fungierten als eine Art digitaler Schutzschild: Die bekannten Angriffsmuster wurden geblockt, noch bevor sie die anfälligen Routinen im PHP-Worker überhaupt erreichen konnten. Bypasses für diesen Schutz gab es nicht.

Container-Isolation: Kein Shared Hosting, keine Kettenreaktion

Ein Hauptgrund für die weltweiten Ausfälle bei Massenhostern liegt in veralteten Shared-Hosting-Strukturen: Teilen sich hunderte Kunden denselben Server-Stack, führt ein Notfall oft zu Serverüberlastung oder erfordert einen harten, kollektiven Reboot.

Da bei uns jede Box in voneinander getrennten, isolierten Containern für Webserver, Datenbank und Cache läuft, gibt es keine geteilten Prozesse und keine Risiken durch unsichere Nachbarn („Bad Neighbour Effect“).

Weder für die Konfigurationsanpassungen am Vormittag noch für den finalen Patch-Rollout um 16:15 Uhr mussten Server hart neugestartet werden. Laufende Kunden-Sessions wurden unterbrechungsfrei zu Ende geführt, während neue Prozesse sofort auf der gehärteten Umgebung starteten.

Menschlicher Support + smarte Live-Automatisierung

Über den Tag verteilt erreichten uns Hunderte besorgte Anfragen von Agenturen und Shopbetreibern. Statt Kunden mit Standard-Mails abzuspeisen, haben wir direkt während des Spitzenaufkommens einen zweisprachigen Krisen-Workflow ausgerollt.

Routinefragen wurden automatisiert geklärt, sodass unsere WordPress-Expertinnen und -Experten im Support den Kopf frei hatten, um komplexe Spezialfälle persönlich und tiefgehend im Chat zu lösen.

Über 550 Kunden konnten so binnen kürzester Zeit informiert und beruhigt werden.

„Mit dem Support von raidboxes® zu der Sache war ich sehr zufrieden, lief alles glatt.“ — Michael Giglhuber

Warum stand im Dashboard vorübergehend noch die alte PHP-Version?

Einige aufmerksame Kunden wandten sich im Live-Chat an uns: „Ihr sagt, wir sind geschützt – aber in meinem Dashboard steht noch immer PHP 8.3.x statt einer neuen Versionsnummer?“

Die Erklärung: Unsere präventive Maßnahme griff auf Server-Ebene vor dem eigentlichen PHP-Paket. Der Schutz war zu 100 % aktiv, noch bevor die PHP-Binary selbst ausgetauscht wurde. Erst nach dem finalen Rollout der offiziellen Pakete änderte sich auch die Versionsanzeige im Dashboard.

Warum gab es bei Raidboxes keine Ausfallzeiten?

Einige Massenhoster mussten drastische Maßnahmen ergreifen: Server wurden rebootet, Prozesse abrupt beendet oder Seiten temporär in Wartungsmodi versetzt.

Dank unserer Container-Architektur konnten wir die notwendigen Konfigurationsänderungen und den späteren Patch-Rollout per Graceful Reload der Prozesse einspielen. Bestehende Verbindungen wurden sauber abgearbeitet, neue Anfragen nahtlos an die gehärtete Umgebung übergeben – ohne eine einzige Sekunde geplante Downtime.

Was ist mit älteren PHP-Versionen?

Im Agenturalltag gibt es immer wieder Kunden-Websites, die aufgrund veralteter Plugins nicht sofort auf PHP 8.2 oder 8.3 aktualisiert werden können. Für diese Legacy-Umgebungen bleiben unsere serverseitigen Schutzmaßnahmen dauerhaft aktiv, bis entsprechende Backports bereitstehen.

Das Ergebnis: Auf der gesamten Raidboxes-Infrastruktur gab es nach aktuellem Stand keine einzige kompromittierte Website.

Deine Seite liegt nicht bei Raidboxes? So prüfst du dein Setup

Wenn du deine WordPress-Websites bei anderen Hostern betreibst, solltest du jetzt zeitnah aktiv werden:

1. PHP-Version in WordPress auslesen

1. Logge dich in dein WordPress-Dashboard ein.
2. Gehe im Menü auf Werkzeuge → Website-Zustand.
3. Klicke auf den Reiter Bericht und klappe den Bereich Server auf.
4. Prüfe den Eintrag bei PHP-Version.

2. Sichere Versionsnummern abgleichen

Die offiziellen Sicherheitsfixes wurden in folgenden Versionen veröffentlicht:

• PHP 8.2.35 (oder höher)
• PHP 8.3.36 (oder höher)
• PHP 8.4.27 (oder höher)
• PHP 8.5.12 oder höher 

Läuft deine Website auf einer älteren Version (z. B. PHP 8.2.20 oder Versionen unter 8.2), solltest du dringend mit deinem Hoster abklären, ob deine Seite geschützt ist.

Muss ich mir beim normalen Surfen Sorgen machen?

Nein, nicht direkt auf deinem Endgerät. PHP2Shell greift Webserver an, nicht den Browser auf deinem Laptop oder Smartphone.

Allerdings besteht ein indirektes Risiko: Wenn eine ungepatchte Website erfolgreich attackiert wird, können Angreifer schädliche Skripte (Malware, Phishing-Formulare, Spam-Weiterleitungen) in die kompromittierte Website einschleusen, die dann reguläre Besucher gefährden. Eine schnelle Absicherung schützt also nicht nur deine Daten, sondern auch das Vertrauen deiner Kunden.

Was PHP2Shell über den Wert von Managed Hosting zeigt 

Vorfälle wie PHP2Shell zeigen den fundamentalen Unterschied zwischen günstigem Webspace und echtem Managed Hosting.

Shared Hoster verkaufen billigen Speicherplatz. Im Ernstfall bist du jedoch auf dich allein gestellt: Du musst Sicherheitswarnungen selbst recherchieren, Serverversionen manuell kontrollieren und landest im Notfall bei Support-Bots oder in überlasteten Hotlines. Wenn du 30, 50 oder 100 Kunden-Websites betreust, bedeutet das puren Stress und unbezahlte Arbeitszeit.

Managed Hosting bei Raidboxes bedeutet:

• Proaktive Sicherheit: Wir handeln auf Server-Ebene, bevor Sicherheitslücken zum Problem auf deiner Website werden.
• Keine Ausfallzeiten: Modernste Container-Technologie sorgt dafür, dass Updates deine Kundenprojekte nicht lahmlegen. 
• Keine Wartungs-Schichten: Unsere Infrastruktur aktualisiert sich im Hintergrund, ohne dass du deine Feierabende opfern musst.
• Echte WordPress-Experten im Chat: Wenn Fragen auftauchen, erreichst du an 7 Tagen die Woche in wenigen Minuten Menschen, die WordPress verstehen – keine Chatbots, keine Skript-Vorleser.

Willst du erleben, wie entspannt Hosting sein kann? Teste Raidboxes 14 Tage lang völlig kostenlos oder nutze unseren kostenlosen Umzugsservice, um eine deiner Kunden-Websites risikofrei im Live-Vergleich zu testen.