Stand: 22. Oktober 2026. Die Lage ändert sich stündlich, prüfen Sie parallel die Statusseite Ihres Hosters.

Wenn andere aufgeben, fangen wir erst an. Das ist kein Werbespruch, sondern unsere Arbeitsweise, und bei einer Lücke wie PHP2Shell wird sie gebraucht.

Am 21. Oktober hat das PHP-Projekt zwei kritische Schwachstellen gepatcht: CVE-2026-109618 und CVE-2026-109619, zusammen bekannt als PHP2Shell. Beide stehen bei 9,2 von 10 Punkten (CVSS v4.0), beide können im schlimmsten Fall zu Remote Code Execution führen, und beide brauchen keinen Login. Betroffen ist PHP bis zurück zur Version 5.4, also rund 14 Jahre Codebasis.

Die entscheidende Erkenntnis: Das ist kein WordPress-Problem. Der Fehler liegt in der Laufzeitumgebung, auf der Ihr CMS, Ihr Shop, Ihr ERP, Ihr CRM und Ihre Eigenentwicklung laufen. Alles, was in PHP geschrieben ist und auf einem ungepatchten Server läuft, ist betroffen. In diesem Beitrag lesen Sie, was technisch passiert, welche Systeme dazugehören, wie Sie in Minuten Klarheit bekommen, warum Ihr Backup jetzt zum Hebel wird und wo Sie in Berlin und Brandenburg Hilfe bekommen, wenn etwas nicht läuft.

PHP2Shell technisch erklärt

Beide Schwachstellen sind Fehler im Speichermanagement der PHP-Engine:

  • CVE-2026-109618: Wird PHP bei Speichermangel mitten in der Verarbeitung einer Anfrage unterbrochen, behandelt der anschließende Cleanup halb initialisierte Strukturen als gültig. Die Engine landet in einem inkonsistenten Zustand.
  • CVE-2026-109619: Interne Anfragedaten bleiben referenzierbar, obwohl ihr Speicher schon freigegeben wurde (Use-after-free-Muster). Die nächste Anfrage im selben PHP-Prozess greift auf diese Reste zu.

Ein wichtiger Auslöser sind Multipart-Anfragen, das Format, mit dem Browser Formulare und Datei-Uploads übertragen. Dieser Parser läuft, bevor Ihr Anwendungscode ausgeführt wird. Entdeckt wurden die Lücken von Wiz. Cloudflare meldet erste Angriffe am Morgen des 21. Oktober, watchTowr berichtet Ausnutzung in freier Wildbahn, und funktionierender Exploit-Code ist öffentlich. Hoster wie Mittwald haben zeitweise Uploads gesperrt beziehungsweise den eingehenden Verkehr komplett angehalten.

Warum nicht nur WordPress: Alles, was PHP nutzt, ist betroffen

Der Angriff beginnt in der Engine, noch vor dem Start Ihrer Anwendung. Deshalb ist es egal, welches System obendrauf läuft. Eine Auswahl der typischen PHP-Systeme, die wir bei Kunden sehen:

Content-Management-Systeme (CMS)

  • WordPress (inklusive Elementor, Beaver Builder, Divi, WPBakery, Gutenberg)
  • TYPO3, Joomla, Drupal, Contao
  • Neos, Craft CMS, Concrete CMS, ProcessWire, Grav, October CMS, Pimcore
  • MediaWiki, phpBB und andere Wiki- und Forensysteme

Onlineshops und E-Commerce

  • WooCommerce (WordPress-Shops)
  • Shopware (5 und 6), Magento / Adobe Commerce, OXID eShop
  • PrestaShop, Gambio, xt:Commerce, modified eCommerce, JTL-Shop, Sylius
  • Marktplatz-Anbindungen, Zahlungs-Module und Schnittstellen (Payment, Versand, Warenwirtschaft)

ERP, CRM, Warenwirtschaft und Business-Software

  • Dolibarr (ERP/CRM), SuiteCRM, EspoCRM, vtiger, OroCRM
  • Rechnungs- und Zeiterfassungstools wie Invoice Ninja oder Kimai
  • Ticket- und Helpdesk-Systeme sowie IT-Dokumentation wie GLPI, i-doit, Snipe-IT
  • Marketing-Automation wie Mautic, Lernplattformen wie Moodle
  • Produktdaten-Systeme wie Akeneo

Oft vergessen: Hilfs- und Nebenanwendungen

  • Nextcloud und ownCloud, Roundcube (Webmail), phpMyAdmin, Matomo
  • Kundenportale, Buchungs- und Terminsysteme, Formular-Skripte, alte Landingpages
  • Eigenentwicklungen auf Laravel, Symfony, CodeIgniter, Slim oder in reinem PHP
  • Vergessene Testsysteme, Staging-Kopien und Altprojekte auf demselben Server

Der letzte Punkt ist der gefährlichste. Auf einem Server oder in einem Hosting-Paket läuft oft mehr, als man im Alltag im Blick hat. Ein einziges verwundbares Altprojekt neben Ihrem Hauptsystem reicht, damit der Angreifer im Verzeichnisbaum und im Benutzerkonto landet, auf das auch Ihr Shop zugreift.

Was nicht betroffen ist

Wir sagen Ihnen auch, wo Sie ruhig bleiben dürfen: Reine SaaS-Dienste wie Shopify, Systeme, die nicht in PHP laufen (z. B. Odoo oder ERPNext auf Python, Node.js-Anwendungen), sind von dieser Lücke nicht betroffen. Prüfen Sie dort aber, ob nebenher PHP-Komponenten laufen, etwa ein Webmailer, ein Blog oder ein Datenbank-Tool auf demselben Server.

Warum Updates und Security-Plugins hier ins Leere laufen

Die Angriffskette beginnt in der PHP-Engine, vor dem Laden Ihres Frameworks, Ihres Themes und jedes Plugins oder Moduls. Daraus folgt:

  • Kein Plugin, Modul oder Bundle kann es abfangen. Security-Erweiterungen sind selbst PHP-Code und kommen zu spät.
  • Die Version Ihres CMS oder Shops ist irrelevant. Ein vollständig aktualisiertes System auf einem verwundbaren PHP bleibt verwundbar.
  • Nur PHP selbst zählt. Abhilfe schafft ausschließlich eine gepatchte PHP-Version oder bei älteren Zweigen ein vom Hoster eingebauter Backport.
  • Vorgelagerte WAF-Regeln (z. B. bei Cloudflare, das Regeln für alle Kunden aktiviert hat) sind eine sinnvolle zusätzliche Schicht, aber kein Ersatz für das Update.

Schritt 1: PHP-Version und Patch-Stand verifizieren

Wichtig ist die Version, die Ihr Webserver ausliefert, nicht die der Kommandozeile. FPM, mod_php und CLI können unterschiedliche Versionen haben. Wo Sie die Web-Version finden:

  • WordPress: Werkzeuge → Website-Zustand → Bericht → Server
  • WooCommerce: WooCommerce → Status → Server-Umgebung
  • Joomla: System → Systeminformationen
  • Drupal: Berichte → Statusbericht
  • TYPO3: Admin Tools → Environment (Systeminformationen und Umgebungsstatus)
  • Alle anderen Systeme: Fragen Sie Ihren Hoster oder rufen Sie die PHP-Version im Kundenbereich der Hosting-Verwaltung ab. Eine temporäre phpinfo()-Datei liefert die Infos ebenfalls, muss aber unmittelbar danach wieder gelöscht werden. Eine öffentlich erreichbare phpinfo-Seite ist selbst ein Sicherheitsrisiko.

Gepatchte Upstream-Versionen sind:

  • PHP 8.5.12 oder neuer
  • PHP 8.4.27 oder neuer
  • PHP 8.3.36 oder neuer
  • PHP 8.2.35 oder neuer (der 8.2-Zweig erhält nur noch bis 31. Dezember 2026 Sicherheitsupdates)

Falle bei Distributionspaketen: Debian, Ubuntu und andere portieren Fixes oft zurück, ohne die Versionsnummer zu ändern. Eine „alte" Nummer ist dann nicht automatisch verwundbar. Prüfen Sie das im Paket-Changelog, etwa mit apt changelog php8.3-cli und der Suche nach den CVE-Nummern, oder holen Sie sich eine schriftliche Bestätigung Ihres Hosters.

Schritt 2: Die richtige Maßnahme je Hosting-Typ

Shared Hosting (IONOS, Strato, All-Inkl, Mittwald u. a.)

Die PHP-Binaries gehören dem Hoster. Sie warten auf dessen Rollout und beobachten die Statusseite. Planen Sie ein, dass Formular- und Datei-Uploads, Kontaktformulare, Medien-Uploads oder Shop-Funktionen zeitweise als Sofortschutz abgeschaltet sein können. Testen Sie nach dem Update Formulare, Uploads, Login, Warenkorb und Checkout.

PHP 8.1 und älter (8.0, 7.4, 7.x …)

Für diese Zweige gibt es keine regulären Releases mehr. Das PHP-Projekt hat minimale Source-Korrekturen bereitgestellt, die jedoch jeder Hoster selbst einbauen müsste. Verlassen Sie sich nicht darauf. Stellen Sie auf PHP 8.3 oder 8.4 um. Vorher gilt: vollständiges Backup (Dateien und Datenbank), Test auf einer Staging-Kopie und Kompatibilitätsprüfung. Besonders bei älteren Shop-Systemen, ERP- und CRM-Lösungen, individuellen Modulen und Eigenentwicklungen bricht der Sprung gern mit Deprecations, Fatal Errors oder defekten Schnittstellen. Hier sparen Sie sich mit Fachhilfe viel Zeit und Ausfall.

Eigener Server, VPS, Root-Server

Aktualisieren Sie die PHP-Pakete Ihrer Distribution und starten Sie die Prozesse neu (PHP-FPM beziehungsweise Apache), sonst laufen die alten verwundbaren Worker weiter im Speicher. Laut PHP-Projekt sind Setups mit Apache und mod_php am stärksten gefährdet.

Ist ein sofortiges Update nicht möglich, nennt das PHP-Projekt folgende Übergangsmaßnahmen. Sie senken das Risiko, schützen aber ausdrücklich nicht vollständig:

  • session.upload_progress.enabled = 0 in der php.ini oder im FPM-Pool setzen, nicht per .user.ini oder ini_set(), denn das greift zu spät.
  • memory_limit = -1 serverseitig per php_admin_value setzen und den Speicher stattdessen über Container- oder cgroup-Limits begrenzen.
  • post_max_size verkleinern (8 MB ohne, 32 MB mit Datei-Uploads) und auf Webserver- oder Proxy-Ebene die Größe von Anfragen sowie die Zahl von Formularfeldern, Multipart-Teilen und Headern begrenzen.

Betrachten Sie das als Pflaster für Stunden, nicht für Tage.

Backup: Ihre Lebensversicherung, aber nur, wenn sie funktioniert

Bei jeder PHP-Umstellung und nach jedem Verdacht auf Befall entscheidet das Backup darüber, ob Sie in einer Stunde oder in einer Woche wieder online sind. Aus unserer Erfahrung scheitert es selten am fehlenden Backup, sondern an einem unbrauchbaren. Worauf es ankommt:

  • Vor jeder Umstellung ein vollständiges Backup von Dateien und Datenbank, getrennt vom Produktivserver gespeichert.
  • 3-2-1-Regel: drei Kopien, auf zwei unterschiedlichen Medien, eine davon extern (Offsite). Besser noch mit unveränderlichem Speicher (Immutable), den auch ein Angreifer mit Server-Zugriff nicht löschen kann.
  • Restore testen. Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung und kein Backup.
  • Den sauberen Zeitpunkt kennen. Wurde die Lücke bereits ausgenutzt, enthält ein frisches Backup unter Umständen schon die Hintertür. Wir bestimmen den letzten sauberen Stand, bevor wir zurückspielen.
  • Datenbank nicht vergessen. Manipulierte Admin-Konten, Cron-Einträge oder eingeschleuste Inhalte stecken oft dort und nicht im Dateisystem.

Genau hier sind wir Ihr Backup-Partner: Wir richten automatisierte, externe Sicherungen ein, überwachen sie, testen regelmäßig die Wiederherstellung und stehen bereit, wenn der Ernstfall eintritt.

Schritt 3: Forensik und Spurensuche

Ein Patch schließt die Lücke, entfernt aber nichts, was bereits abgelegt wurde. Weil die Ausnutzung vor den Updates begann, sollten Sie systematisch prüfen:

  • PHP-Code in Upload-Verzeichnissen (hat dort nichts verloren): find wp-content/uploads -type f ( -name "*.php" -o -name "*.phtml" -o -name "*.phar" ). Bei anderen Systemen entsprechend in den Medienordnern, etwa fileadmin/ (TYPO3), images/ (Joomla), sites/default/files/ (Drupal), pub/media/ (Magento) oder public/media/ (Shopware 6).
  • Kürzlich geänderte PHP-Dateien: find . -type f -name "*.php" -mtime -3
  • Unbekannte Administratoren: im Benutzerbereich Ihres Systems und direkt in der Datenbank.
  • WordPress-spezifisch: wp core verify-checksums, wp plugin verify-checksums --all, wp user list --role=administrator und ein Blick in wp-content/mu-plugins/, denn Must-Use-Plugins laden automatisch und sind ein beliebtes Versteck.
  • Cronjobs und geplante Aufgaben auf Server- und Anwendungsebene.
  • Logs: Häufungen von Multipart-POST-Anfragen, gefolgt von PHP-Fehlern wie „Allowed memory size exhausted" oder abgestürzten FPM-Workern (z. B. Signal 11 im FPM-Log), sind ein Indiz und kein Beweis, aber ein guter Anlass zum genaueren Hinsehen.
  • Außenwirkung: Weiterleitungen auf fremde Seiten (besonders mobil oder aus der Google-Suche), fremde Unterseiten Ihrer Domain im Suchindex, plötzlich versendeter Spam.

Bei jedem Verdacht gilt: Passwörter für Anwendung, Datenbank, FTP/SFTP und Hosting-Konto ändern, Schlüssel und Salts erneuern (bei WordPress in der wp-config.php), API-Zugangsdaten zu Zahlungsanbietern, ERP und CRM rotieren und die Installation gründlich bereinigen. Eine einzelne gelöschte Datei genügt nicht, denn Angreifer legen in aller Regel mehrere Persistenzmechanismen an: Backdoors in Themes und Modulen, manipulierte Plugins, Cronjobs, versteckte Admin-Konten.

Die Kurz-Checkliste

  • Alle PHP-Systeme inventarisieren: Hauptseite, Shop, ERP, CRM, Portale, Nebenanwendungen, Altprojekte, Staging-Kopien
  • Web-Version bestimmen (FPM/mod_php), nicht nur die CLI-Version
  • Gegen 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 abgleichen oder Backport-Nachweis des Hosters einholen
  • Vollständiges Offsite-Backup anlegen und Restore prüfen
  • PHP 8.1 und älter: Staging-Test, Umstellung auf 8.3/8.4
  • Eigener Server: Pakete aktualisieren und FPM beziehungsweise Apache neu starten
  • Bis dahin Notbehelfe setzen (Upload-Progress aus, Request-Limits)
  • Danach Formulare, Uploads, Login, Warenkorb und Checkout testen
  • Uploads, Admin-Liste, Cronjobs und Logs prüfen

Wenn andere aufgeben, fangen wir erst an

Ein Update, das nicht durchläuft. Ein Shop, der nach der Umstellung weiß bleibt. Ein ERP, das keine Daten mehr abgleicht. Ein Hoster, der nur auf die Statusseite verweist. Das sind die Momente, in denen viele aufgeben. Und genau dort setzen wir an. Systemhaus.IT aus Berlin und Brandenburg ist die Adresse, wenn es nicht läuft.

Wir arbeiten auf Server-Ebene und nicht nur an der Oberfläche. Wir betreuen IT-Infrastruktur und entwickeln selbst PHP-Anwendungen. Wir lesen Pool-Konfigurationen, Webserver-Limits und Logs ebenso sicher wie Theme-, Modul- und Plugin-Code. Wenn nach einem PHP-Sprung das Layout zerbricht, ein Modul Fatal Errors wirft oder eine Schnittstelle still stirbt, finden wir die Ursache, statt nur Symptome zu überpinseln.

Wir kennen die ganze Bandbreite. Ob WordPress, TYPO3, Joomla, Drupal, Contao, Shopware, Magento, WooCommerce, PrestaShop, Dolibarr, SuiteCRM oder Ihre individuelle Eigenentwicklung: Wir sind nicht auf ein System festgelegt, sondern darauf, dass Ihres wieder läuft.

Wir denken in Kette, nicht in Einzelmaßnahme. Bestandsaufnahme, Backup, sichere Umstellung mit Staging-Test, Kompatibilitätsprüfung, Spurensuche, Bereinigung, Härtung und anschließende Überwachung. Das gehört zusammen, und wir liefern es aus einer Hand.

Wir sagen Ihnen, was Sache ist. Kein Alarmismus, kein Fachchinesisch. Sie erfahren, ob Ihr System betroffen ist, was zu tun ist und was es kostet. Und wenn alles in Ordnung ist, sagen wir Ihnen auch das.

Ihr IT-Partner in Berlin und Brandenburg

Systemhaus.IT sitzt in Berlin-Wilmersdorf und ist in der gesamten Region zu Hause. Wenn Sie in Berlin oder Brandenburg ein Unternehmen, einen Shop, eine Kanzlei, eine Praxis, eine Hausverwaltung oder einen Verein betreiben, haben Sie bei uns Ansprechpartner, die Ihre Region kennen und bei Bedarf auch vor Ort sind.

Berlin

Wir unterstützen Unternehmen in Charlottenburg, Wilmersdorf, Mitte, Spandau, Steglitz, Zehlendorf, Tempelhof, Neukölln, Kreuzberg, Friedrichshain, Prenzlauer Berg, Pankow, Reinickendorf, Lichtenberg, Marzahn-Hellersdorf und Treptow-Köpenick.

Brandenburg

Ebenso erreichen wir Kunden in Potsdam, Falkensee, Hennigsdorf, Oranienburg, Bernau, Eberswalde, Strausberg, Königs Wusterhausen, Teltow, Werder (Havel), Brandenburg an der Havel, Neuruppin, Frankfurt (Oder) und Cottbus, auf Wunsch persönlich, in jedem Fall aber per Fernwartung.

Wer einen IT-Notdienst in Berlin, Webseiten-Reparatur in Brandenburg oder einen Backup-Partner in der Region sucht, findet bei uns einen direkten Draht statt einer anonymen Hotline.

Alles an einem Ort: unsere Lösungen im Überblick

Unter systemhaus.in/loesungen finden Sie unter „Womit können wir helfen?" die passenden Leistungen für Ihr Anliegen. Einen Gesamtüberblick über das Systemhaus bekommen Sie auf systemhaus.in.

  • System läuft nicht mehr oder zeigt Fehler? Wir diagnostizieren und reparieren, auch nach PHP-Umstellungen und bei Schnittstellenproblemen.
  • Verdacht auf Befall? Wir prüfen, bereinigen und sichern ab.
  • PHP-Umstellung geplant? Wir testen vorab und stellen sauber um.
  • Backup fehlt oder ist ungetestet? Wir sind Ihr Backup-Partner mit Offsite-Sicherung und Restore-Test.
  • Dauerhaft sicher bleiben? Wir übernehmen Wartung und Monitoring.

Häufige Fragen zu PHP2Shell

Ist mein CMS, Shop oder ERP betroffen?

Ja, wenn die Anwendung in PHP läuft und das PHP auf Ihrem Server nicht gepatcht ist oder der Hoster den Backport nicht bestätigt hat. Anwendungsversion, Theme und Plugins spielen dafür keine Rolle.

Reicht ein Update meines CMS oder Shops?

Nein. Der Angriff passiert in der PHP-Engine, bevor Ihre Anwendung geladen wird. Nur ein PHP-Update oder ein vom Hoster eingespielter Fix schließt die Lücke.

Schützt mich ein Security-Plugin oder eine Firewall-Erweiterung?

Nicht verlässlich, weil solche Erweiterungen selbst in PHP laufen und erst nach dem kritischen Punkt aktiv werden. Eine vorgelagerte WAF ist eine gute Zusatzschicht, aber kein Ersatz.

Ist Shopify betroffen?

Als gehostete Plattform nicht direkt. Läuft aber nebenher eine PHP-Anwendung auf Ihrem eigenen Server (Blog, Schnittstelle, Portal), muss diese geprüft werden.

Was muss ich bei Shared Hosting tun?

Das Update spielt Ihr Hoster ein. Sie prüfen Version und Statusseite, sichern vorab, testen danach Formulare, Uploads und Checkout und stellen bei PHP 8.1 oder älter selbst auf 8.3 oder 8.4 um.

Woran erkenne ich einen erfolgreichen Angriff?

Unbekannte Administratoren, PHP-Dateien in Upload- und Medienordnern, fremde Dateien in Modul- oder mu-plugins-Verzeichnissen, Prüfsummen-Abweichungen, Weiterleitungen auf fremde Seiten oder unbekannte Unterseiten Ihrer Domain bei Google.

Können Sie auch kurzfristig helfen?

Sprechen Sie uns an. Wir schauen uns Ihre Situation an und sagen Ihnen ehrlich, was zu tun ist und in welchem Zeitrahmen wir es umsetzen können.

Jetzt Klarheit schaffen

Sie wollen wissen, ob Ihre Systeme gepatcht sind, brauchen einen verlässlichen Backup-Partner oder jemanden, der sauber umstellt, prüft und aufräumt, wenn andere nicht weiterkommen? Rufen Sie uns an, wir kümmern uns darum.

Telefon: +49 3322 8509070

E-Mail: team@systemhaus.in

Lösungen & Leistungen: systemhaus.in/loesungen

Systemhaus.IT, Berlin & Brandenburg: Wenn andere aufgeben, fangen wir erst an.