PHP2Shell: Kritische PHP-Sicherheitslücke, was WordPress-Betreiber jetzt tun müssen

Stand: 13. November 2026, 14:45 Uhr. Übernommene WordPress-Websites sind weiterhin nicht bekannt: Wordfence hat bis zum 28. Oktober keinen solchen Fall gesehen, und das BSI sieht in Deutschland keine großflächige Ausnutzung. Neu seit dem 12. November: Check Point berichtet, dass Angreifer ab dem 30. Oktober ungepatchte Firewalls des Herstellers über deren Mobile-Access-Portal mit PHP2Shell angegriffen und in einigen Fällen übernommen haben (Check Point Research). Webhosting und WordPress betrifft das nicht, es zeigt aber, dass auch Geräte mit Weboberfläche ihr PHP-Update brauchen. Die Sicherheitsfirma GreyNoise zählt inzwischen 1.229 erfolgreiche Angriffe auf ihre absichtlich verwundbaren Testsysteme von 24 Angreifer-Adressen, fünf davon am 12. November. Seit dem 11. November laden die Angreifer dabei ein Programm zum Schürfen von Kryptowährung (XMRig) auf den Server und starten es, am 12. November unter dem Namen xmrigMiner. Wer PHP noch nicht aktualisiert hat, sollte das jetzt nachholen. Neue PHP-Versionen gibt es nicht. Raidboxes hat seit dem 9. November auch die älteren PHP-Versionen mit Sicherheitsupdates versorgt. Die WordPress-Lücke im Update-Vorgang (CVE-2026-119977, behoben in WordPress 7.1.4) wird weiter angegriffen: Bis zum 5. November hat die Wordfence-Firewall über 240.000 Angriffsversuche geblockt, und die US-Behörde CISA führt die Lücke seit dem 3. November als aktiv ausgenutzt. 7.1.4 bleibt deshalb Pflicht (Abschnitt „Warum ein WordPress-Update diesmal nicht hilft“). Schon am 2. November hatte Wordfence gezeigt, dass sich eine verwandte Lücke in der Bibliothek Brotli auf dem Server über WordPress ausnutzen lässt. Ich aktualisiere diesen Beitrag, sobald es Neues gibt.

In PHP stecken zwei kritische Sicherheitslücken, genannt PHP2Shell (CVE-2026-109618 und CVE-2026-109619). Über sie können Angreifer ohne Anmeldung eigenen Code auf dem Server ausführen und damit die ganze Website übernehmen, auch bei WordPress. Das PHP-Team hat am 21. Oktober um 16 Uhr deutscher Zeit die abgesicherten Versionen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Wenn Ihre WordPress-Website auf einer älteren Version läuft, muss PHP heute aktualisiert werden. Ein Update von WordPress oder den Plugins reicht nicht.

Was passiert ist

Forscher, unter anderem von der Firma Calif, haben die Fehler im August entdeckt und dem PHP-Team gemeldet. Bevor die Updates fertig waren, gelangten Einzelheiten an die Öffentlichkeit. Das PHP-Team hat deshalb am 20. Oktober vorab gewarnt und die Updates auf den 21. Oktober, 14 Uhr UTC gelegt. Beide Lücken haben den Schweregrad 9,2 von 10 (CVSS 4.0).

Das BSI warnt, dass alle bekannten PHP-Versionen bis mindestens PHP 5 verwundbar sind, und hält eine großflächige Ausnutzung innerhalb weniger Stunden nach den Updates für wahrscheinlich. Cloudflare hat nach eigenen Angaben schon vor der Veröffentlichung Angriffe auf Websites seiner Kunden gesehen und beobachtet, wie Angreifer ihre Anfragen abwandeln, um Schutzregeln zu umgehen. Die Forscher von Calif haben die Lücke nach eigener Darstellung unter anderem gegen WordPress 7.1.2, Drupal, Joomla, Magento und Nextcloud ausgenutzt, ohne Anmeldung.

Seit dem Abend des 21. Oktober kursieren auf GitHub mehrere öffentliche Programme, die die Lücken ausnutzen sollen. Laut Recorded Future funktioniert nicht jedes davon, und wie viele Websites tatsächlich übernommen wurden, ist noch offen. In der aktuellen Fassung seiner Warnung (Version 1.2 vom 22. Oktober) schreibt das BSI, dass ihm bisher keine erfolgreichen Angriffe in der Breite bekannt sind. Angriffsversuche gab es aber schon vor den Updates, seitdem laufen sie verstärkt und automatisiert. Berichte, die Updates ließen sich umgehen, hält das BSI für widerlegt: Wer aktualisiert hat, ist gegen diese beiden Lücken geschützt. Für Sie heißt das: Ein Server ohne Update ist nicht nur in der Theorie gefährdet.

Am 26. Oktober hat die US-Cybersicherheitsbehörde CISA beide Lücken in ihren Katalog aktiv ausgenutzter Schwachstellen aufgenommen. Dort landen nur Lücken, für die es Belege für Angriffe gibt. Einzelheiten zu den Angriffen nennt CISA nicht, US-Bundesbehörden müssen bis zum 29. Oktober aktualisieren.

Inzwischen sind die ersten erfolgreichen Angriffe dokumentiert. Ein Sicherheitsforscher hat auf Fallen-Servern (Honeypots) mit dem ungepatchten PHP 8.4.26 und Apache mod_php 35 Fälle aufgezeichnet, in denen Angreifer mit einem öffentlich verfügbaren Angriffsprogramm Befehle auf dem Server ausgeführt haben (Bericht auf GitHub). Die Sicherheitsfirma Dream berichtet von 25 übernommenen Servern, Firewalls und Verwaltungsservern von Palo Alto Networks mit dem alten PHP 8.0.30; dort wurde PHP2Shell mit einer Lücke im Linux-Kernel kombiniert (Dream Research, ergänzt am 29. Oktober). Angegriffen wurde die Verwaltungsoberfläche der Firewalls, Palo Alto Networks hat dafür eigene Updates veröffentlicht (Sicherheitshinweis von Palo Alto Networks). Auch Check Point meldet am 12. November erfolgreiche Angriffe auf ungepatchte eigene Firewalls über deren Mobile-Access-Portal, ab dem 30. Oktober und kombiniert mit einer zweiten Lücke (CVE-2026-123039), über die die Angreifer volle Rechte auf dem Gerät bekamen (Check Point Research). Die Sicherheitsfirma GreyNoise zählt bis zum 12. November 1.229 erfolgreiche Angriffe auf ihre absichtlich verwundbaren Testsysteme, davon 982 am 31. Oktober, 36 am 4. November und nach fünf Tagen Pause sechs am 10., drei am 11. und fünf am 12. November (GreyNoise). Seit dem 11. November laden die Angreifer dabei den Krypto-Miner XMRig auf den Server und starten ihn. Echte Websites sind darin nicht enthalten, die Zahl zeigt aber, dass funktionierende Angriffsprogramme im Umlauf sind und weiter benutzt werden. Diese Kernel-Lücke (CVE-2026-46300) führt die CISA seit dem 28. Oktober ebenfalls als aktiv ausgenutzt. Wordfence, das nach eigenen Angaben über fünf Millionen WordPress-Websites schützt, kennt bis zum 28. Oktober keine WordPress-Website, die über PHP2Shell übernommen wurde. Vom 23. bis 27. Oktober hat es rund 77.600 Angriffsanfragen von mehr als 2.000 IP-Adressen gezählt (Wordfence, 28. Oktober). Das BSI zählt auf seiner Lageseite zu PHP2Shell Angriffsversuche im zweistelligen Millionenbereich, sieht in Deutschland aber bisher keine großflächige Ausnutzung und keine erfolgreichen Angriffe mit Datenabfluss. Es weist außerdem darauf hin, dass auch Router, NAS-Laufwerke und Smart-Home-Zentralen mit Weboberfläche betroffen sein können.

Ist meine WordPress-Website betroffen?

Sehr wahrscheinlich ja, bis PHP auf Ihrem Server aktualisiert ist. WordPress ist in PHP geschrieben, jede WordPress-Website läuft also auf PHP. Das PHP-Team nennt in seiner Sicherheitsmeldung alle PHP-Installationen, die Webanfragen beantworten, als gefährdet, ganz gleich ob über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Am höchsten ist das Risiko bei Apache mit mod_php: Dort lässt sich der Angriff auslösen, bevor WordPress überhaupt startet.

So sehen Sie, welche PHP-Version Ihre Website nutzt: Melden Sie sich in WordPress an und öffnen Sie Werkzeuge, Website-Zustand, Bericht. Im Abschnitt „Server“ steht die PHP-Version.

PHP-Version auf Ihrem Server	Was das heißt
8.5.12, 8.4.27, 8.3.36, 8.2.35 oder höher	Abgesichert. Prüfen Sie trotzdem, ob es vor dem Update Auffälligkeiten gab (unten).
8.2 bis 8.5, aber eine ältere Unterversion	Verwundbar. Das Update muss heute eingespielt werden, bei Hosting-Paketen vom Hoster.
8.1, 8.0, 7.x oder älter	Verwundbar und vom PHP-Projekt nicht mehr versorgt. Wechsel auf PHP 8.2 oder neuer, außer Ihr Hoster liefert ausdrücklich einen Sicherheitsfix für diese Version.

Was Sie jetzt tun müssen

1. PHP-Version prüfen, wie oben beschrieben, und den Stand notieren.
2. Beim Hoster nachfragen, wenn Ihre Website in einem Hosting-Paket liegt. Die meisten Hoster aktualisieren PHP selbst, oft melden sie den Stand auf ihrer Statusseite. Eine kurze Mail reicht: „Ist PHP für meine Website bereits auf eine Version gegen CVE-2026-109618 und CVE-2026-109619 aktualisiert und neu gestartet?“ Das Update wirkt erst, wenn PHP danach neu gestartet wurde.
3. Auf eine unterstützte Version wechseln, wenn Ihre Website noch PHP 8.1 oder älter nutzt. Laut php.net werden nur noch PHP 8.2 und neuer gepflegt. Die Version stellen Sie meist im Kundenmenü des Hosters um. Nehmen Sie dabei am besten gleich PHP 8.3 oder 8.4: PHP 8.2 bekommt laut PHP-Team nur noch bis 31. Dezember 2026 Sicherheitsupdates. Machen Sie vorher ein Backup: Alte Plugins und Themes laufen auf neuem PHP nicht immer. Zeigt die Website danach einen kritischen Fehler, hilft die Anleitung zum kritischen Fehler.
4. Eigener Server: PHP-Pakete der Distribution aktualisieren und alle PHP-Prozesse neu starten (PHP-FPM, Apache). Das PHP-Team weist darauf hin, dass das verbreitete Paketarchiv rpms.remirepo.net am 21. Oktober keine Updates hatte. Wer es nutzt, sollte auf die Pakete der Distribution wechseln. Aktualisieren Sie dabei auch den Linux-Kernel, denn Angreifer kombinieren PHP2Shell mit der Kernel-Lücke CVE-2026-46300.
5. Nach dem Update auf Spuren prüfen (nächster Abschnitt).

Was die Hoster melden: IONOS schreibt in seinem Hilfe-Center, dass es das PHP-Update auf seinen Servern eingespielt hat, auch für Versionen, die das PHP-Projekt nicht mehr pflegt. Wer die PHP-Version im IONOS-Kundenkonto auswählt, muss deshalb nichts tun. Dasselbe melden STRATO (auch für die älteren Versionen im PHP Extended Support) und All-Inkl (am 27. Oktober auf seiner Startseite, für sämtliche angebotenen PHP-Versionen, auch die nicht mehr unterstützten). Mittwald hat alle betriebenen Versionen ab PHP 5.6 gepatcht. Raidboxes hat nach den Versionen ab PHP 8.2 inzwischen auch die älteren mit Sicherheitsupdates versorgt (Stand 9. November) und meldet bisher keine kompromittierte Website. Hetzner hat bis zum 28. Oktober auf allen Webhosting- und Managed-Servern auch PHP 5.6 und 7.3 gepatcht. Anders bei einem eigenen Server (VPS oder Dedicated Server): Dort ist der Betreiber selbst für das Update zuständig. Fragen Sie bei anderen Hostern nach, ob es eine solche Meldung gibt. Den Wechsel weg von PHP 8.1 und älter würde ich trotzdem einplanen, denn ob ein Hoster alte Versionen absichert, ist seine freiwillige Leistung.

Vorsicht vor gefälschten Mails: IONOS warnt, dass Betrüger die Aufmerksamkeit für PHP2Shell nutzen und gefälschte Mails im Namen des Hosters verschicken, um an Zugangsdaten zu kommen. Melden Sie sich nur über die Adresse an, die Sie selbst im Browser eingeben, nie über einen Link aus so einer Mail, und führen Sie keine Skripte aus, die Ihnen jemand schickt.

Liegt Ihre Website hinter Cloudflare? Dann filtert Cloudflare seit dem 21. Oktober, 5:02 Uhr deutscher Zeit, bekannte Angriffsmuster, auch im kostenlosen Tarif, sofern die Web Application Firewall (WAF) aktiv ist. Cloudflare schreibt selbst, dass Angreifer ihre Anfragen abwandeln, und rät, PHP trotzdem zu aktualisieren. Das ist eine zusätzliche Schicht, kein Ersatz für das Update.

Für Server-Administratoren nennt das PHP-Team Einstellungen, die einzelne Angriffswege erschweren, wenn ein Update nicht sofort möglich ist. Es schreibt aber ausdrücklich, dass sie eine Installation nicht sicher machen. Ich würde mich nicht darauf verlassen. Seit dem 23. Oktober rät das PHP-Team außerdem, auch auf aktualisierten Servern session.upload_progress.enabled=0 zu setzen, bis das nächste reguläre PHP-Update erscheint. Es geht um einen dritten, laut PHP-Team unwahrscheinlichen Angriffsweg (CVE-2026-115560), der nur bei einer seltenen Kombination aus Server-Einstellung und Programmcode auftritt. Läuft heute kein Update, ist vorübergehendes Abschalten der Website die sichere Wahl. Laut n-tv haben unter anderem die Stadt Mainz und die Universität Mannheim ihre Websites aus diesem Grund vom Netz genommen.

Warum ein WordPress-Update diesmal nicht hilft

Bei den meisten Sicherheitswarnungen zu WordPress geht es um ein Plugin oder um WordPress selbst, und ein Klick auf „Aktualisieren“ im Dashboard behebt das Problem. Diesmal liegt der Fehler eine Ebene tiefer, in PHP, also in der Software auf dem Server, die WordPress ausführt. Der Sicherheitsdienst Sansec bringt es auf den Punkt: Die Lücke lässt sich nicht aus dem Code der Website heraus schließen. Auch Sicherheits-Plugins kommen bei Apache mit mod_php zu spät, weil der Angriff schon vor dem Start von WordPress greifen kann.

Das ist der Grund, warum gute WordPress-Wartung mehr umfasst als Plugin-Updates: Jemand muss auch wissen, auf welcher PHP-Version die Website läuft, und den Wechsel auf eine neue Version vorher auf einer Testkopie prüfen.

WordPress-Updates bleiben trotzdem Pflicht, schon wegen einer eigenen Lücke im Update-Vorgang, die WordPress 7.1.4 am 28. Oktober geschlossen hat (CVE-2026-119977). Für ältere Zweige gibt es eigene Korrekturen, etwa 7.0.8, 6.9.11 und 6.8.12. Wordfence hat bis zum 5. November über 240.000 Angriffsversuche geblockt, an der Spitze am 30. Oktober über 74.000 an einem Tag. Das klingt dramatischer, als es ist: Treffen kann ein Angriff nur im kurzen Zeitfenster, in dem gerade ein Update läuft. Das Update auf 7.1.4 läuft allerdings selbst ein letztes Mal durch den alten Vorgang. Wordfence rät deshalb, es nicht aufzuschieben und vorher auf dem Webserver den Zugriff auf PHP-Dateien im Ordner /wp-content/upgrade/ zu sperren. Die passende Firewall-Regel bekommt die kostenlose Wordfence-Version erst am 27. November.

Für eine verwandte Lücke, die am 2. November dazugekommen ist, hilft ein Update von WordPress ebenfalls nicht. Sie steckt nicht in PHP, sondern in Brotli, einer Bibliothek zum Entpacken komprimierter Daten, die das Betriebssystem des Servers mitbringt (CVE-2026-111497, von der US-Behörde CISA seit 27. Oktober als ausgenutzt geführt). Wordfence hat im Labor gezeigt, dass Angreifer darüber ohne Anmeldung Code ausführen können, und zwar über die Pingback-Funktion von WordPress (XML-RPC). Einen erfolgreichen Angriff auf eine echte Website kennt Wordfence bisher nicht. Auf den üblichen Linux-Servern tauscht ein WordPress- oder PHP-Update Brotli nicht aus, das muss der Hoster tun. Nur für PHP auf Windows-Servern gibt es seit dem 26. Oktober neue Pakete mit korrigiertem Brotli: 8.5.12-1, 8.4.27-1, 8.3.36-1 und 8.2.35-1 (php.net). Fragen Sie ihn, ob die Brotli-Bibliothek Ihres Servers die Korrektur für CVE-2026-111497 enthält und ob die Dienste danach neu gestartet wurden. Auf einem eigenen Server spielen Sie das Update des Betriebssystems ein. Die Einstellung in Wordfence, die die Anmeldung über XML-RPC abschaltet, sperrt die Pingbacks übrigens nicht.

Woran Sie einen erfolgreichen Angriff erkennen

Ein PHP-Update schließt die Lücke, entfernt aber nichts, was ein Angreifer vorher hinterlassen hat. Prüfen Sie nach dem Update deshalb:

• neue Administrator-Konten unter Benutzer, die niemand angelegt hat
• unbekannte PHP-Dateien, besonders im Ordner wp-content/uploads, wo normalerweise nur Bilder und Dokumente liegen. Wordfence rät, vor allem auf Dateien zu achten, die am 17. Oktober oder später angelegt wurden.
• eine Datei namens wp2s.php in wp-content/uploads oder in einem Plugin- oder Theme-Ordner. Unter diesem Namen versuchen die von Wordfence beobachteten Angriffe eine Hintertür abzulegen. Dieselben Angriffe versuchen, die Zugangsdaten aus der wp-config.php und der .env-Datei zu lesen.
• geänderte Dateien in WordPress, im Theme oder in Plugins (ein Abgleich mit frischen Originaldateien zeigt das)
• Weiterleitungen auf fremde Seiten, Spam-Seiten bei Google unter Ihrer Domain oder Warnungen im Browser
• für Administratoren: im Fehlerprotokoll des Servers gehäufte Abstürze von PHP-Prozessen (SIGSEGV) und Meldungen „Allowed memory size exhausted“, im Zugriffsprotokoll Upload-Anfragen, die zu keinem Formular Ihrer Website passen (Hinweise von BSI und Wordfence)
• für Administratoren: im Zugriffsprotokoll Anfragen von außen auf PHP-Dateien unter /wp-content/upgrade/, besonders setup-config.php, und liegen gebliebene Dateien oder Ordner dort. Ein normales Update braucht solche Anfragen nicht (Wordfence). Das betrifft die Lücke im Update-Vorgang, nicht PHP2Shell selbst.
• für Administratoren: ein laufender Prozess namens xmrig oder xmrigMiner, eine Datei /tmp/xmrig oder ein Ordner /tmp/b109. So heißt der Krypto-Miner, den Angreifer seit dem 11. November auf Testsystemen von GreyNoise starten.

Sansec beschreibt außerdem, dass eine der Lücken Speicherinhalte anderer Anfragen preisgeben kann, darunter Passwörter, Sitzungen und API-Schlüssel. Wenn Ihre Website ungepatcht im Netz war, würde ich nach dem Update die Passwörter der Administratoren ändern, die Sicherheitsschlüssel in der wp-config.php erneuern (das meldet alle Nutzer ab) und Zugangsschlüssel zu angebundenen Diensten wie Zahlungsanbieter oder Newsletter-Tool austauschen.

Finden Sie eines dieser Zeichen, ist die Website wahrscheinlich kompromittiert. Dann hilft ein Update allein nicht mehr, sondern eine Bereinigung. IONOS rät in diesem Fall, ein sauberes Backup vom Stand vor den Angriffen einzuspielen (Anfang Oktober 2026) und danach alle Passwörter und Zugangsschlüssel neu zu setzen. Wie die abläuft, steht auf meiner Seite WordPress gehackt: Soforthilfe.

Häufige Fragen

Nutzt WordPress PHP?

Ja. WordPress ist in PHP geschrieben und läuft nur mit PHP auf dem Server. Deshalb betrifft PHP2Shell jede WordPress-Website, bis der Server auf PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder neuer läuft.

Welche PHP-Version ist sicher?

PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer, veröffentlicht am 21. Oktober 2026. PHP 8.1 und älter bekommen vom PHP-Projekt keine neue Version mehr. Für 7.4, 8.0 und 8.1 hat das PHP-Sicherheitsteam nur Korrekturen im Quellcode veröffentlicht, die Linux-Distributionen und Langzeit-Anbieter in eigene Pakete einbauen können. Fragen Sie Ihren Hoster, ob er das getan hat. Sicherer ist der Wechsel auf PHP 8.3 oder 8.4.

Reicht es, WordPress und die Plugins zu aktualisieren?

Nein. Die Lücke steckt in PHP selbst, also in der Software, auf der WordPress läuft. Geschlossen wird sie nur durch ein PHP-Update auf dem Server. WordPress- und Plugin-Updates bleiben trotzdem wichtig, sie schließen diese Lücke aber nicht.

Schützt mich ein WordPress-Update wie 7.1.3 oder 7.1.4 vor PHP2Shell?

Nein. WordPress 7.1.3 ist am 6. Oktober erschienen, WordPress 7.1.4 am 28. Oktober. Beide schließen Lücken in WordPress selbst, 7.1.4 unter anderem eine Schwachstelle im Update-Vorgang, über die Angreifer während des Updates Code ausführen können. PHP2Shell steckt in PHP, der Software auf dem Server. Dagegen hilft nur das PHP-Update. WordPress 7.1.4 sollten Sie trotzdem gleich installieren, denn laut Wordfence wird die Lücke im Update-Vorgang bereits angegriffen: Bis zum 5. November hat die Wordfence-Firewall über 240.000 Angriffsversuche geblockt. Treffen kann ein Angriff nur, während gerade ein Update läuft, die Zahl sagt also wenig über tatsächlich übernommene Websites. Seit dem 3. November führt auch die CISA diese Lücke (CVE-2026-119977) in ihrem Katalog aktiv ausgenutzter Schwachstellen. Ob 7.1.4 installiert ist, sehen Sie unter „Dashboard > Aktualisierungen“. In welcher Reihenfolge Sie WordPress, Plugins und Theme aktualisieren, steht im Ratgeber WordPress-Updates richtig einspielen.

Hilft ein Sicherheits-Plugin wie Wordfence?

Nicht zuverlässig. Laut PHP-Team kann der Angriff bei Apache mit mod_php ausgelöst werden, bevor überhaupt Code der Anwendung läuft. Ein Plugin in WordPress kommt dann zu spät. Nur das PHP-Update schließt die Lücke.

Schützt mich Cloudflare vor PHP2Shell?

Teilweise. Cloudflare filtert seit dem 21. Oktober bekannte Angriffsmuster, auch im kostenlosen Tarif mit aktiver Web Application Firewall. Angreifer wandeln ihre Anfragen aber ab, um die Regeln zu umgehen. Cloudflare empfiehlt deshalb selbst, PHP trotzdem zu aktualisieren.

Ich bin bei einem Hoster. Muss ich trotzdem etwas tun?

Ja: prüfen, ob Ihr Hoster schon aktualisiert hat. IONOS, STRATO und All-Inkl zum Beispiel haben das Update für alle PHP-Versionen eingespielt, die Kunden dort auswählen können, auch für alte. Läuft Ihre Website noch auf PHP 8.1 oder älter, wechseln Sie trotzdem auf 8.3 oder 8.4, denn nicht jeder Hoster sichert alte Versionen ab. Auf einem eigenen Server (VPS) müssen Sie PHP selbst aktualisieren.

Muss ich meine Website offline nehmen?

Wenn Ihr Server heute nicht aktualisiert werden kann, ist vorübergehendes Abschalten die sichere Wahl. Mehrere Städte und Hochschulen haben ihre Websites am 21. Oktober genau deshalb vom Netz genommen. Ist PHP aktualisiert, kann die Website wieder online gehen.

Hilfe, wenn Sie nicht weiterkommen

Sie wissen nicht, auf welcher PHP-Version Ihre Website läuft, der Hoster antwortet nicht, oder nach dem PHP-Wechsel funktioniert etwas nicht mehr? Ich prüfe das für Sie, spiele das Update ein und teste die Website danach. Rufen Sie an unter 089 3288 6771 oder schreiben Sie mir über das Kontaktformular. Wenn Sie solche Lagen künftig nicht mehr selbst verfolgen wollen: Das ist der Kern meiner WordPress-Betreuung.

Quellen: Sicherheitsmeldung des PHP-Teams mit den technischen Details in GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp, Pressemitteilung des BSI und BSI-Warnung Version 1.2, CERT-EU, CISA und IONOS Hilfe-Center.