PHP2Shell: Was die PHP-Sicherheitslücke für Ihre Website bedeutet und was Sie jetzt tun müssen

Kurz gesagt: das Wichtigste in 60 Sekunden

PHP2Shell ist der Name für zwei kritische Sicherheitslücken in PHP, der Technik unter WordPress, Joomla, TYPO3, Shopware und rund sieben von zehn Websites ^{Quelle 1} , ^{Quelle 17} . Geschlossen sind sie erst, wenn auf dem Server PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder neuer läuft; ein Update von WordPress oder Plugins reicht dafür nicht ^{Quelle 1} , ^{Quelle 5} . Prüfen Sie deshalb jetzt Ihre PHP-Version und lassen Sie sich das Update von Ihrem Hoster bestätigen. Stand dieses Beitrags: 24. Oktober 2026 für die Angaben des PHP-Projekts und von CERT-EU, 23. Oktober 2026 für alles Übrige.

• Was es ist: zwei Fehler im Kern von PHP, offiziell CVE-2026-109618 und CVE-2026-109619, beide mit 9,2 von 10 Punkten als kritisch bewertet ^{Quelle 1} .
• Was Angreifer damit können: ohne Anmeldung eigenen Code auf Ihrem Webserver ausführen oder Arbeitsspeicher auslesen, in dem Passwörter und Zugangsschlüssel stehen können ^{Quelle 3} .
• Seit wann es Updates gibt: seit dem Nachmittag des 21. Oktober 2026 ^{Quelle 1} , ^{Quelle 6} . Für PHP 8.1, 8.0 und 7.4 gibt es nur einen Notfall-Flicken im Quellcode, für noch ältere Versionen nichts ^{Quelle 1} .
• Wie ernst die Lage ist: Das BSI stuft sie mit „3 / Orange“ ein: Maßnahmen müssen unverzüglich ergriffen werden ^{Quelle 5} . Angriffsversuche liefen schon Stunden vor den Updates ^{Quelle 10} , und viele Kliniken, Hochschulen und Behörden nahmen ihre Websites vorsorglich vom Netz ^{Quelle 8} , ^{Quelle 9} .
• Was beruhigt: Ein erfolgreicher Einbruch über PHP2Shell ist bisher nicht öffentlich belegt ^{Quelle 5} , ^{Quelle 14} , und die großen deutschen Hoster melden, dass ihre Server aktualisiert sind. Verwundbar heißt nicht automatisch gehackt.
• Was Sie jetzt tun: PHP-Version prüfen, das Update vom Hoster bestätigen lassen, Passwörter und Schlüssel wechseln, ein sauberes Backup sichern, auf Spuren achten. Die Schritte stehen weiter unten.
• Keine Zeit dafür? Im PHP2Shell-Check für WordPress prüfen wir den Korrekturstand und klären ihn mit Ihrem Hoster. Eine erste Einschätzung bekommen Sie kostenlos: kostenlose Ersteinschätzung anfragen.

Was ist PHP2Shell? Die Lücke verständlich erklärt

PHP2Shell ist kein WordPress-Problem, sondern ein Fehler im Fundament, auf dem WordPress steht.

Das Bild dazu: Stellen Sie sich Ihre Website als Auto vor. WordPress, Joomla oder TYPO3 sind die Karosserie, die Plugins die Extras, PHP ist der Motor. PHP2Shell ist ein Konstruktionsfehler im Motor. Wie gepflegt die Karosserie ist, spielt dafür keine Rolle: Jedes Auto mit diesem Motor muss in die Werkstatt.

Was genau kaputt ist: Hinter dem Namen stecken zwei Fehler im Kern von PHP ^{Quelle 1} , ^{Quelle 2} .

• Der erste betrifft den Moment, in dem PHP während einer Anfrage der Speicher ausgeht. PHP bricht die Anfrage dann ab, räumt danach aber mit Speicher auf, der in einem undefinierten Zustand ist. Ein Angreifer kann diesen Moment gezielt herbeiführen.
• Der zweite betrifft PHP-Prozesse, die viele Anfragen nacheinander bearbeiten. Nach einem schweren Fehler kann ein Verweis auf bereits freigegebenen Speicher übrig bleiben, und eine spätere Anfrage an denselben Prozess kann ihn verwenden.

Was Angreifer damit erreichen: Die Entdecker nennen zwei Folgen ^{Quelle 3} :

• Code ausführen, ohne angemeldet zu sein, mit den Rechten des PHP-Prozesses auf Ihrem Server. Damit lassen sich Dateien ändern, Schadsoftware ablegen oder Daten abgreifen.
• Arbeitsspeicher auslesen, ohne dass dabei Schadcode läuft. Darin können Passwörter, Anmelde-Token, API-Schlüssel und Zertifikate anderer Anfragen oder des Servers selbst stehen. Wiz vergleicht das mit Heartbleed aus dem Jahr 2014 ^{Quelle 4} .

Warum ein Update von WordPress nicht hilft: Ein Update der Anwendung aktualisiert die PHP-Version darunter nicht ^{Quelle 3} ; auch das BSI schreibt, ein Update der Anwendungen reiche nicht aus ^{Quelle 5} . Am gefährdetsten sind Server mit Apache und mod_php: Dort kann der Angriff greifen, bevor überhaupt Code Ihrer Website läuft ^{Quelle 1} . Bei PHP-FPM, das viele Hoster einsetzen, laufen die bekannten Angriffswege über den Code der Anwendung; betroffen ist auch diese Variante ^{Quelle 1} , ^{Quelle 2} .

Warum das erst jetzt auffällt: Laut Wiz ist jede PHP-Version der letzten zehn Jahre betroffen, zurück bis PHP 5.4 aus dem Jahr 2012 ^{Quelle 4} . Gemeldet haben die Fehler zwischen August und September 2026 Forscher von Calif, Wiz und OpenAI, unabhängig voneinander ^{Quelle 2} , ^{Quelle 4} . Wiz arbeitete dabei mit KI-Modellen und schreibt, ein einzelner Forscher habe so in einer Woche geschafft, wofür früher ein Spitzenteam Monate gebraucht hätte ^{Quelle 4} . Erste Anzeichen des Speicherproblems waren dem PHP-Projekt schon 2024 aufgefallen. Einen konkreten Angriffsweg fand man damals nicht, und die Behebung kam über Monate nicht voran, wie die PHP Foundation selbst einräumt ^{Quelle 2} .

Woher der Name kommt: „php2shell“ haben die Forscher ihr Angriffsskript genannt, inzwischen steht der Name für die ganze Forschung ^{Quelle 3} . Eine „Shell“ ist in der Fachsprache eine Kommandozeile, über die sich ein Server steuern lässt.

Was ist passiert? Die Chronik

Geplant war eine geordnete Veröffentlichung am 22. Oktober. Weil die CVE-Nummern einen Tag vorher durchsickerten, zog PHP die Updates vor, und viele Betreiber nahmen ihre Websites vom Netz, bis aktualisierte Pakete bereitstanden ^{Quelle 7} .

• 11. August 2026: Ein Forscher von Calif meldet dem PHP-Projekt einen Weg, auf PHP-Servern ohne Anmeldung Code auszuführen ^{Quelle 2} .
• 19. bis 24. August 2026: Wiz findet die Lücken unabhängig davon, führt Angriffe ohne Login gegen Drupal und WordPress vor und meldet sie am 24. August dem PHP-Sicherheitsteam ^{Quelle 4} .
• September und Oktober 2026: OpenAI meldet unabhängig dieselbe Ursache ^{Quelle 2} . PHP arbeitet an der Behebung und plant die Veröffentlichung für den 22. Oktober ^{Quelle 2} .
• 17. Oktober 2026: Amazon beobachtet auf einem Köder-System einen ersten Angriffsversuch, vier Tage vor der Veröffentlichung. Woher der Angreifer die Details hatte, ist unklar ^{Quelle 12} .
• 20. Oktober 2026: Die beiden CVE-Nummern kursieren im Netz, mit falscher Uhrzeit und falscher Bewertung; technische Details sind nicht dabei ^{Quelle 2} . PHP kündigt die Updates am Abend an und zieht sie auf den 21. Oktober vor ^{Quelle 1} , ^{Quelle 2} .
• 21. Oktober, früh: Cloudflare schaltet Schutzregeln für seine Website-Firewall frei, auch im kostenlosen Tarif ^{Quelle 11} . Laut Cloudflare-Chef laufen in den zehn Stunden vor den Updates bereits Tausende Angriffsversuche ^{Quelle 10} .
• 21. Oktober, Nachmittag: PHP veröffentlicht die Updates 8.5.12, 8.4.27, 8.3.36 und 8.2.35, angekündigt für 16 Uhr deutscher Zeit, dazu Notfall-Flicken für 8.1, 8.0 und 7.4 ^{Quelle 1} , ^{Quelle 6} . Die Forscher veröffentlichen ihre technischen Details ^{Quelle 4} . Das BSI warnt mit Stufe 3/Orange ^{Quelle 5} , CERT-EU rät, Anwendungen notfalls vom Netz zu nehmen, bis das Update eingespielt ist ^{Quelle 6} .
• 21. Oktober, Nachmittag und Abend: Die Charité, die FU Berlin, die Stadt Mainz, die Unikliniken Heidelberg und Mannheim sowie Polizei- und Behördenseiten nehmen ihre Websites vorsorglich vom Netz ^{Quelle 8} , ^{Quelle 9} , ^{Quelle 7} . Mittwald und netcup trennen die Websites ihrer Kunden für einige Stunden vom Internet ^{Quelle 25} , ^{Quelle 24} . Laut Cloudflare zählen die Angriffe 45 Minuten nach den Updates in die Zehntausende, nach zwei Stunden in die Hunderttausende ^{Quelle 10} . Debian, Ubuntu, Red Hat und weitere Linux-Distributionen liefern Pakete aus ^{Quelle 7} .
• 22. Oktober 2026: Laut heise hat es Abschaltungen „in diesem Ausmaß noch nicht gegeben“; erste Websites sind wieder online ^{Quelle 7} . IONOS, STRATO, All-Inkl, Hetzner, netcup, Mittwald, DomainFactory und Raidboxes melden ihre Plattformen als aktualisiert (siehe unten). Das BSI hält fest, dass Berichte über unvollständige Updates widerlegt sind und ihm keine erfolgreiche Ausnutzung in der Breite bekannt ist ^{Quelle 5} .
• 23. Oktober 2026: Das PHP-Projekt weist auf eine dritte Lücke hin (CVE-2026-115560), die nur bei einer ungewöhnlichen Konfiguration ausnutzbar ist. Ein Sonder-Update gibt es dafür nicht; bis zum nächsten regulären Update empfiehlt PHP, session.upload_progress.enabled=0 zu setzen, und CERT-EU übernimmt das in sein Advisory ^{Quelle 1} , ^{Quelle 6} . Amazon spricht von breiten Angriffsversuchen ^{Quelle 12} . Sophos hat am Vorabend eine frühere Erfolgsmeldung zurückgenommen und sieht keinen Beleg für einen erfolgreichen Einbruch ^{Quelle 14} .

Wer ist betroffen?

Praktisch jede Website, die auf PHP läuft, unabhängig davon, welches System darauf aufsetzt. Laut W3Techs nutzen rund 69 % aller Websites, deren Server-Technik bekannt ist, PHP ^{Quelle 17} . Betroffen sind alle Varianten, mit denen ein Webserver PHP ausführt, darunter PHP-FPM, Apache mit mod_php und LiteSpeed ^{Quelle 1} .

Nach PHP-Version:

Das Problem dahinter: Laut W3Techs laufen rund 27 % aller PHP-Websites noch auf PHP 7 und rund 8 % auf PHP 5 ^{Quelle 17} . Gut ein Drittel aller PHP-Websites bekommt also kein reguläres Update vom PHP-Projekt.

Nach System: Die Forscher haben Angriffe ohne Login gegen WordPress, Drupal und Joomla in ihren aktuellen Versionen vorgeführt ^{Quelle 3} . Betroffen ist aber jede PHP-Anwendung auf einem verwundbaren Server, also auch WooCommerce, TYPO3, Shopware, Magento, Nextcloud, Moodle und Eigenentwicklungen mit Laravel oder Symfony ^{Quelle 1} .

Auch Geräte im Büro: Das BSI nennt NAS-Speicher von QNAP und Synology, Firewalls wie OPNsense, pfSense und Palo Alto sowie die Hosting-Software cPanel als mindestens teilweise betroffen ^{Quelle 5} . Betreiben Sie ein solches Gerät, vor allem eines, dessen Oberfläche aus dem Internet erreichbar ist, achten Sie auf Updates des Herstellers.

Nach Hosting-Situation:

Was die großen Hoster melden (Stand 22. Oktober 2026):

Diese Meldungen gelten für die Plattformen der Hoster. Für einen eigenen Server oder VPS sind Sie selbst zuständig, auch wenn er bei einem dieser Anbieter steht.

Nicht betroffen: Websites, die auf dem Server kein PHP ausführen. Dazu gehören statische Websites aus fertigen HTML-Dateien und Websites, die mit Werkzeugen wie Astro oder React gebaut und als fertige Dateien ausgeliefert werden. Bei Shopify und Wix betreibt der Anbieter die Server; dort können und müssen Sie keine PHP-Version aktualisieren. Prüfen Sie aber Nebenprojekte wie einen alten Blog, ein Intranet oder eine Nextcloud: Die laufen oft auf PHP.

Bin ich betroffen? Der Selbstcheck in 5 Minuten

Drei Fragen entscheiden: Läuft Ihre Website auf PHP, welche Version, und hat Ihr Hoster das Update eingespielt?

1. Läuft Ihre Website auf PHP? Wurde sie mit WordPress, WooCommerce, Joomla, TYPO3, Drupal, Shopware oder Magento gebaut, lautet die Antwort ja. Wenn Sie es nicht wissen, fragen Sie die Agentur, die die Website gebaut hat. Lässt sich unter ihre-domain.de/wp-admin eine Anmeldung öffnen, ist es WordPress.
2. Welche PHP-Version läuft? In WordPress unter Werkzeuge → Website-Zustand → Bericht → Server. Im Kundenmenü Ihres Hosters steht die PHP-Version meist in den Einstellungen der Domain oder des Webspace.
3. Vergleichen Sie mit der Tabelle oben. Steht dort 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder höher, ist das Update drin. Achtung bei eigenen Servern mit Ubuntu oder Red Hat: Dort bauen die Distributionen den Fix in die alte Versionsnummer ein. Entscheidend ist dann die Paketversion, nicht die PHP-Version ^{Quelle 5} , ^{Quelle 19} .
4. Steht dort eine ältere Nummer? Dann hat Ihr Hoster entweder noch nicht aktualisiert, oder Ihre Website läuft auf einer Version ohne offizielles Update. Hat Ihr Hoster einen Notfall-Flicken eingebaut, sehen Sie das an der Nummer nicht. In allen Fällen gilt: nachfragen und handeln, siehe nächster Abschnitt.
5. Lassen Sie sich das Update bestätigen. Die meisten Hoster informieren auf einer Statusseite oder per E-Mail. Fragen Sie im Zweifel schriftlich nach, ob die Updates auf Ihrem Server eingespielt sind. Eine grüne Statusseite heißt nur, dass der Server läuft, nicht, dass er aktualisiert ist.

Ergebnis: Ist die Version aktuell oder vom Hoster bestätigt, machen Sie weiter mit Passwörtern, Backup und Spurensuche (Schritte 3 bis 8 unten). Ist sie veraltet oder unklar, beginnen Sie bei Schritt 1.

Sie möchten das nicht selbst machen? Im PHP2Shell-Check für WordPress prüfen wir den Korrekturstand, klären ihn in Ihrem Auftrag mit Ihrem Hoster und melden Ihnen, was bestätigt und was offen ist, für 290 € einmalig netto. Für eine erste Einschätzung schreiben Sie uns die Adresse Ihrer Website; wir melden uns an Werktagen innerhalb von 24 Stunden: kostenlose Ersteinschätzung anfragen.

Was jetzt zu tun ist: Schritt für Schritt

Das Update ist die einzige vollständige Lösung ^{Quelle 1} , ^{Quelle 5} . Alles andere ist Überbrückung und Nachsorge.

1. Update einspielen lassen. Im Hosting-Paket erledigt das der Hoster. Läuft Ihre Website noch auf PHP 8.1 oder älter, stellen Sie im Kundenmenü auf PHP 8.3 oder neuer um; 8.2 bekommt nur noch bis Ende 2026 Sicherheitsupdates ^{Quelle 18} . Ziehen Sie vorher ein Backup und prüfen Sie, ob Theme und Plugins die neue Version unterstützen. Auf eigenen Servern: Pakete aktualisieren, Docker-Images neu bauen und PHP neu starten ^{Quelle 5} . Bei PHP-FPM genügt ein Neuladen, bei Apache mit mod_php braucht es einen vollständigen Neustart ^{Quelle 19} .
2. Wenn das Update nicht sofort möglich ist: Das BSI empfiehlt dann, eine vorübergehende Trennung des Webservers vom Internet zu erwägen, bis das Update eingespielt ist ^{Quelle 5} . Eine Website-Firewall wie die von Cloudflare kann einen Teil der Angriffe abfangen, ersetzt das Update aber nicht ^{Quelle 3} , ^{Quelle 11} . Für Administratoren nennen PHP und das BSI Einstellungen, die das Risiko senken, etwa session.upload_progress.enabled=0 in der php.ini oder im FPM-Pool mit anschließendem Neustart aller PHP-Prozesse. Sicher machen sie eine Installation ausdrücklich nicht ^{Quelle 1} , ^{Quelle 5} . Wegen einer dritten, nur bei ungewöhnlicher Konfiguration ausnutzbaren Lücke empfiehlt PHP seit dem 23. Oktober, session.upload_progress.enabled=0 bis zum nächsten regulären Update gesetzt zu lassen ^{Quelle 1} , ^{Quelle 6} .
3. Passwörter und Schlüssel wechseln. Arbeitsspeicher ließ sich auslesen, ohne dass Schadcode lief, und die Protokolle der Anwendung zeigen davon oft wenig ^{Quelle 3} . Wir empfehlen deshalb, alle Geheimnisse auf dem Server als möglicherweise bekannt zu behandeln: Admin-Passwörter, das Datenbank-Passwort in der wp-config.php, die WordPress-Sicherheitsschlüssel, API-Schlüssel für Zahlungsanbieter, Newsletter-Dienste und Google sowie Zugänge per FTP, SFTP und SSH. Erst das Update, dann der Wechsel, sonst wechseln Sie umsonst.
4. Alle Nutzer abmelden. In Shops und Portalen mit Kundenlogin beenden Sie alle Sitzungen, damit abgegriffene Anmeldedaten wertlos werden. Neue Sicherheitsschlüssel in der wp-config.php melden in WordPress alle Benutzer ab; wie das geht, steht im Ratgeber WordPress gehackt.
5. Ein sauberes Backup beiseitelegen. Sichern Sie einen Stand von vor dem 17. Oktober, dem frühesten bekannten Angriffsversuch ^{Quelle 12} , und bewahren Sie ihn außerhalb der normalen Rotation auf. Zeigt sich später ein Einbruch, brauchen Sie einen Stand von davor.
6. System und Plugins trotzdem aktualisieren. Das schützt nicht vor PHP2Shell. Ein Angreifer, der einmal auf dem Server ist, nutzt aber gern alte Plugin-Lücken, um sich festzusetzen.
7. Spuren prüfen. Wie das geht, steht im nächsten Abschnitt.
8. Dokumentieren und Meldepflicht prüfen. Halten Sie fest, wann welche Version lief und wann das Update kam. Können personenbezogene Daten betroffen sein, etwa aus Formularen oder Kundenkonten, ist in der Regel eine Meldung an die Datenschutz-Aufsichtsbehörde nötig, unverzüglich und möglichst binnen 72 Stunden ^{Quelle 29} . Das ist eine Information, keine Rechtsberatung.

Was Sie nicht tun müssen: Als Besucher einer Website müssen Sie nichts unternehmen. Die Lücke sitzt auf dem Server, nicht auf Ihrem Rechner oder Smartphone.

Wurde meine Website schon angegriffen?

Ehrliche Antwort: Eindeutige Erkennungsmerkmale gibt es nicht. Das BSI schreibt, konkrete Indikatoren seien nicht verfügbar ^{Quelle 5} , und die Entdecker betonen, dass fehlende Anzeichen nicht beweisen, dass nichts passiert ist ^{Quelle 3} . Es gibt aber typische Spuren.

Anzeichen, die Sie ohne Technik-Wissen erkennen:

• Die Website leitet auf fremde Seiten weiter, zeigt Spam oder ist plötzlich sehr langsam.
• Google warnt in den Suchergebnissen, die Website sei möglicherweise gehackt.
• Ihr Hoster meldet sich wegen auffälligem Datenverkehr oder Schadsoftware.
• In WordPress stehen Administratoren oder Plugins, die niemand aus Ihrem Betrieb angelegt hat.

Spuren, nach denen Ihr Administrator sucht:

• neue oder geänderte PHP-Dateien, vor allem in Upload-, Cache- und Temp-Ordnern, bei WordPress etwa in wp-content/uploads ^{Quelle 15} , ^{Quelle 13}
• auffällige Multipart-Anfragen, auf die Speicherfehler oder Serien von HTTP-500-Antworten folgen, vor allem an Seiten, die gar keine Uploads annehmen ^{Quelle 5} , ^{Quelle 15}
• übergroße PHPSESSID-Cookies und POST-Anfragen mit dem Feld PHP_SESSION_UPLOAD_PROGRESS ^{Quelle 5}
• abgestürzte oder ungewöhnlich oft neu gestartete PHP-Prozesse ^{Quelle 3} , ^{Quelle 15}
• Programme wie sh, curl oder wget, die vom Webserver aus gestartet wurden, und neue Verbindungen vom Webserver zu unbekannten Zielen ^{Quelle 15} , ^{Quelle 13}
• erfolgreiche Admin-Anmeldungen, die niemand zuordnen kann ^{Quelle 13}

Welcher Zeitraum zählt? Amazon rät, mindestens ab dem 17. Oktober zu prüfen ^{Quelle 12} . Sophos geht weiter zurück, bis zum 1. August, weil die ersten Meldungen im August beim PHP-Projekt eingingen ^{Quelle 13} .

Hilfsmittel für Administratoren: Sophos und Check Point haben Suchanleitungen veröffentlicht ^{Quelle 13} , ^{Quelle 15} . Das niederländische Cybersicherheitszentrum NCSC-NL führt auf GitHub eine Liste betroffener Produkte, dazu ein Skript mit Notmaßnahmen für cPanel ^{Quelle 16} . Malware-Scanner für WordPress finden abgelegte Hintertüren, sogenannte Webshells, aber nicht den Angriff selbst.

Wenn Sie etwas finden: Nehmen Sie die Website vom Netz, informieren Sie Hoster und IT-Dienstleister und löschen Sie nichts, denn die Spuren werden noch gebraucht. Setzen Sie die Website aus einem sauberen Backup neu auf, statt sie nur zu säubern, wechseln Sie danach alle Zugänge und prüfen Sie die Meldepflicht. Die Reihenfolge im Detail steht im Ratgeber WordPress gehackt: Was jetzt zu tun ist. Ein unvollständig bereinigter Server ist gefährlicher als ein bekannt befallener.

Die eigentliche Lehre: Warum das wieder passieren wird

PHP2Shell ist kein Einzelfall. Es ist die zweite kritische Lücke innerhalb von drei Monaten, über die sich WordPress-Websites ohne Login angreifen ließen.

• Juli 2026, wp2shell: Zwei Fehler im WordPress-Kern (CVE-2026-60137 und CVE-2026-63030) ließen sich so verketten, dass Angreifer ohne Login einen Administrator anlegen und darüber Code ausführen konnten. Betroffen waren WordPress 6.9.0 bis 6.9.4 und 7.0.0 bis 7.0.1. Das Update kam am 17. Juli, zwei Tage später zählte VulnCheck mehr als zwei Dutzend öffentliche Angriffswerkzeuge, ab dem 20. Juli beobachtete es aktive Angriffe ^{Quelle 28} .
• Oktober 2026, PHP2Shell: dieselbe Lage eine Ebene tiefer, im PHP-Motor selbst.

Das Muster dahinter: Eine klassische CMS-Website führt bei jedem Seitenaufruf Programmcode auf dem Server aus: PHP, dazu das Redaktionssystem, dazu oft eine ganze Reihe von Plugins. Jede dieser Schichten kann eine Lücke haben, jede braucht Updates, und jedes Update kann die Website beschädigen. Wer nicht aktualisiert, ist angreifbar. Wer aktualisiert, braucht jemanden, der das regelmäßig und mit Backup erledigt. Für die meisten kleinen und mittleren Betriebe ist das laufende Arbeit, für die niemand zuständig ist.

Die Zahlen zeigen, wie verbreitet das ist: Gut ein Drittel aller PHP-Websites läuft auf PHP 7 oder älter ^{Quelle 17} , also auf Versionen, die das PHP-Projekt seit Jahren nicht mehr pflegt. PHP 8.2 bekommt nach dem 31. Dezember 2026 keine Sicherheitsupdates mehr ^{Quelle 18} . Wer heute auf 8.2 umstellt, steht in gut zehn Wochen vor derselben Frage.

Sie haben drei Möglichkeiten:

Keine Technik ist unverwundbar. Die Angriffsfläche unterscheidet sich aber deutlich: Eine Website, die als fertige Seiten ausgeliefert wird, hat keinen PHP-Prozess, keinen Admin-Login auf dem Server und keine Plugins, die ein Angreifer treffen könnte. Was es nicht gibt, muss man nicht patchen.

Die Alternative: Websites, die PHP2Shell nicht treffen konnte

Die Websites, die wir für unsere Kunden gebaut haben, waren von PHP2Shell nicht betroffen. Nicht, weil wir schneller aktualisiert hätten, sondern weil auf ihren Servern kein PHP läuft. Sie finden sie unter unseren Projekten.

So funktioniert das: Wir bauen Websites als Code, zum Beispiel mit Astro oder React. Die Seiten werden vorab fertig erzeugt und über ein weltweites Auslieferungsnetz ausgeliefert. Beim Aufruf läuft kein PHP, auf dem Server wartet kein Admin-Login auf Passwort-Rateversuche, und es gibt keine Plugins, die Updates brauchen. Möchten Sie Texte selbst ändern, planen wir ein Redaktionssystem dazu; was das kostet, steht im Angebot. Funktionen wie Formulare oder Terminbuchung laufen über eigene, schlanke Schnittstellen. Websites, die wir betreuen, überwachen wir.

Was das nicht heißt: Es gibt keine unverwundbare Website. Es gibt eine deutlich kleinere Angriffsfläche und einen Betrieb, bei dem Sie sich nicht mehr selbst um PHP-Versionen kümmern müssen.

So helfen wir Ihnen jetzt:

Zeigt die Prüfung einen Einbruch, gehören die Wiederherstellung aus dem Backup und das Schließen der Lücke zur Betreuung. Fehlt ein sauberes Backup und wird die Bereinigung dadurch aufwändiger, sagen wir Ihnen den Mehraufwand an, bevor wir weiterarbeiten. Neue Inhalte oder Funktionen sind in der Betreuung nicht enthalten; alles Weitere dazu steht auf der Seite zur Website-Betreuung.

Jetzt kostenlose Ersteinschätzung anfragen oder den PHP2Shell-Check für WordPress direkt per WhatsApp anfragen.

Sie erreichen uns auch telefonisch unter 0174 9152726, per WhatsApp oder per E-Mail an info@akuma-digital.de. Wir sitzen in Gera und betreuen Websites von Betrieben in ganz Deutschland.