Phishing nutzt php2shell, Hoster patcht

1 week ago 4

Sicherheit (Pexels, allgemeine Nutzung) Die Woche hat sicherlich die php2shell-Thematik die Leserschaft in Atem gehalten. Nun wurde ich von Lesern informiert, dass erste Phisher das Thema für sich ausschlachten. Und der Hoster all-inkl.com erklärt, warum seine Seiten am 21. Oktober 2026 für Stunden nicht erreichbar waren und wie er Kunden schützt. Da ich das Thema php2shell hier im Blog in mehreren Artikel begleitet habe, nachfolgend ein Abriss auf neue Entwicklungen zu den oben angesprochenen Themenfeldern

php2shell für Phishing-Nachrichten missbraucht

Es hat nicht lange gedauert, bis Phisher die php2shell-Sicherheitslücke für sich entdeckt haben. Mir ist zwar noch nichts untergekommen, aber ChristophH hat sich in diesem Kommentar gemeldet und schrie, dass bereits E-Mails kursieren, welche die Empfänger auffordern, sich an einem gefälschten Kundenportal anzumelden und die PHP-Version zu aktualisieren.

Im konkreten Fall werde unter dem Absender "METANIT" und dem Betreff "Wichtige Mitteilung: PHP-Update erforderlich" versucht, Website-Administratoren auf ein gefälschtes Kundenportal des Schweizer Providers metanet.ch zu locken. ChristophH schrieb: "Hoffen wir, dass Personen welche so nebenbei mal eine Website aufgebaut haben aber von der Technik dahinter keine große Ahnung haben, nicht darauf reinfallen und ihre Zugangsdaten preisgeben." Beim Leser wurde die Nachricht immerhin direkt in den Spam-Ordner geschoben.

Auch Leser Heinrich bestätigt, dass es wohl auch in Deutschland schon Phishing mit dem Betreff php2shell gebe. In diesem Kommentar zitiert er folgende Warnung von Strato:

Vorsicht vor Phishing: Betrüger nutzen solche Lücken vermehrt für Phishing – sie verschicken gefälschte E-Mails, um an Zugangsdaten zu geraten. STRATO rät, keine Links in E-Mails anzuklicken, die sich auf die PHP-Lücke berufen und keine Zugangsdaten einzugeben.

Keine Ahnung, wie andere Hoster reagieren – man sollte aber aufmerksam bleiben.

Wie All-inkl.com auf die Thematik reagiert

Im Beitrag php2shell: PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619 klang es ja (in Benutzerkommentaren) an, dass Kommunen zahlreiche Webseiten zum 21. Oktober 2026 vorsorglich wegen der betreffenden Sicherheitslücken vom Netz genommen hätten. Es wurden ja schnell Angriffe erwartet, wobei diese bereits vier Tage vorher beobachtet wurden. Derzeit ist mir aber nichts bezüglich "großflächigen Hacks" über php2shell bekannt.

Interessant ist aber, wie einzelne Hoster oder Betreiber reagierten. Ich habe im Vorfeld der PHP-Patch-Freigabe mit meinem technischen Ansprechpartner des Eigentümers von borncity.com per E-Mail im Austausch gestanden. Dort läuft ja auch der IT-Blog hier unter borncity.com/blog. Der neue Eigentümer des Blogs hostet zwar bei Hetzner, haben aber einen eigenen Server für diverse Webseiten. Dort wurde mir gesagt, dass PHP bereits im Vorfeld zur Freigabe der PHP-Patches "gehärtet" und die Infrastruktur geschützt wurde. Meine Nischenblogs unter borncity.eu sind dagegen bei all-inkl.com gehostet.

All-inkl.com über Stunden "ausgefallen"?

Zum 21. Oktober 2026 wollte ich am späteren Nachmittag meine Nischenblogs temporär deaktivieren. Ich kam zwar in die KAS genannte Seite zur Vertragsverwaltung. Aber die separate Seite zur technischen Verwaltung war nicht mehr aufrufbar, sondern der Browser versucht die Seite ergebnislos zu laden. Kurze Zeit später kam ich auch nicht mehr in die KAS-Oberfläche.

Mich erreichten einige Mails mit dem Tenor "all-inkl.com seit Stunden ausgefallen", und auch hier im Blog gibt es diesen Kommentar-Thread dazu. Benjamin merkte um 16:24 Uhr an "all-inkl.com scheint auch nicht erreichbar zu sein". Ich hatte mich im Kommentar-Thread zwei Mal zu dieser Thematik geäußert. Meine Vermutung war, dass all-inkl.com die eigene Infrastruktur zur Verwaltung der Verträge und Hosting-Pakete offline genommen habe, da das alles auf PHP aufsetzt.

Die Hosting-Pakete samt Blogs waren ja durchgehend erreichbar und am frühen Morgen des 22. Oktobers 2026 kam ich wieder in die Verwaltungskonsole. Und ich konnte feststellen, dass der Provider PHP für meine Hosting-Pakete zeitnah gepatcht hatte.

All-inkl.com informiert auf der Webseite

Im Rahmen dieses Beitrags (auch weil ich heute eine Mail vom Provider bekommen habe) habe ich eben die Webseite von all-inkl.com abgerufen und wurde mit folgender Information begrüßt.

Der Hoster informiert, dass er zum Schutz der eigenen Infrastruktur und der Daten der Kunden vorsorglich einige der eigenen Dienste vorübergehend abgeschaltet habe. Diese werden nach Abschluss der Sicherheitsprüfungen wieder vollständig zur Verfügung gestellt. Die Webseiten der Kunden waren von diesen Abschaltungen nicht betroffen. Hinweise auf eine Ausnutzung gab es nicht.

Der Hoster schreibt, dass man unmittelbar nach Bekanntgabe der php2shell-Sicherheitslücken reagiert habe. Bereits vor Veröffentlichung der Sicherheitsupdates seien zusätzliche Schutzmaßnahmen auf den Servern aktiviert worden.

Inzwischen seien sämtliche vom Hoster angebotenen PHP-Versionen mit den notwendigen Sicherheitskorrekturen versehen. Dies gilt auch für ältere PHP-Versionen, die vom PHP-Projekt offiziell nicht mehr unterstützt werden.

Parallel dazu habe ich heute eine E-Mail des Hosting-Anbieters mit ausführlichen Informationen erhalten, die ich am Artikelende mal einstelle.

php2shell Info-E-Mail des Anbieters all-inkl.com an Kunden

(English version below)

Sehr geehrte ALL-INKL.COM – Kundin,
Sehr geehrter ALL-INKL.COM – Kunde,

am 21. Oktober 2026 wurden zwei außergewöhnlich kritische Sicherheitslücken in der Programmiersprache PHP veröffentlicht, die weltweit zahlreiche Webseiten und Webhosting-Anbieter betroffen haben. Nachfolgend geben wir Ihnen einen Überblick über die ergriffenen Maßnahmen, den aktuellen Stand und die Auswirkungen der Ereignisse auf unsere Dienste.

Was war passiert?

Die beiden Sicherheitslücken (CVE-2026-109618 und CVE-2026-109619) ermöglichten es Angreifern unter bestimmten Voraussetzungen, ohne vorherige Anmeldung Schadcode auf betroffenen Webservern auszuführen. Besonders kritisch war, dass dafür nicht einmal eine Sicherheitslücke in der jeweiligen Webseite erforderlich war. Bereits eine speziell präparierte Anfrage an den PHP-Interpreter konnte ausreichen. Betroffen waren zahlreiche PHP-Versionen, die seit vielen Jahren eingesetzt werden. Es handelte sich damit um eine außergewöhnliche Sicherheitslage, die zahlreiche Betreiber von Webservern vor erhebliche Herausforderungen stellte. Anders als bei vielen gewöhnlichen Sicherheitslücken waren nicht nur einzelne Anwendungen betroffen, sondern der PHP-Interpreter selbst. Dadurch bestand ein potenzielles Risiko für eine sehr große Anzahl von Webseiten weltweit. Für uns war deshalb entscheidend, die Zeit zwischen Veröffentlichung der Sicherheitslücken und Installation der notwendige
n Updates auf ein Minimum zu reduzieren.

Welche Maßnahmen haben wir ergriffen?

Unsere Techniker haben unmittelbar reagiert und bereits vor Veröffentlichung der Sicherheitsupdates zusätzliche Schutzmaßnahmen vorbereitet und aktiviert. Nach Veröffentlichung der Sicherheitskorrekturen haben wir mit höchster Priorität damit begonnen, die notwendigen Patches zu erstellen, zu testen und auf unseren Kundenservern zu verteilen. Dabei mussten wir zahlreiche unterschiedliche PHP-Versionen berücksichtigen. Innerhalb von etwa acht Stunden konnten wir die notwendigen Sicherheitsupdates auf unserer Hosting-Infrastruktur verteilen. Inzwischen haben wir sämtliche bei uns angebotenen PHP-Versionen gegen die beiden bekannt gewordenen Sicherheitslücken gepatcht. Dies gilt ausdrücklich auch für ältere Versionen wie PHP 5.6 und PHP 7.x. Für unsere Kunden war hierfür keine eigene Aktualisierung erforderlich.

Warum waren einige unserer Dienste nicht erreichbar?

Um mögliche Angriffe auf unsere zentralen Systeme und die darüber verwalteten Kundendaten zu verhindern, haben wir vorsorglich Teile unserer eigenen Infrastruktur abgeschaltet. Davon betroffen waren unter anderem unsere Kundenverwaltung (Members Area), KAS, Webmail und WebFTP sowie unsere eigene Webseite. Diese Entscheidung haben wir bewusst getroffen, um größere Sicherheitsrisiken zu vermeiden und gleichzeitig sämtliche verfügbaren technischen Ressourcen auf die schnellstmögliche Absicherung der Kundenserver konzentrieren zu können. Die Webseiten unserer Kunden waren von diesen vorsorglichen Abschaltungen nicht betroffen. Auch während der Einschränkungen bei Webmail funktionierten der reguläre E-Mail-Empfang und -Versand über entsprechend eingerichtete E-Mail-Programme weiterhin.

Wurden Kundendaten kompromittiert?

Nach unserem bisherigen Kenntnisstand liegen uns keine konkreten Hinweise auf eine erfolgreiche Ausnutzung dieser Sicherheitslücken auf unseren Systemen vor. Eine mögliche Ausnutzung vor Installation der Sicherheitsupdates lässt sich allerdings nicht vollständig ausschließen. Wir überwachen unsere Systeme weiterhin auf auffällige Aktivitäten. Unabhängig davon empfehlen wir, Webseiten und Anwendungen regelmäßig auf ungewöhnliche Veränderungen zu überprüfen, beispielsweise auf unbekannte Dateien, unerwartete Änderungen oder neu angelegte Benutzerkonten.

Warum dauert die Bearbeitung von Supportanfragen länger?

Die Ereignisse haben zu einem außergewöhnlich hohen Supportaufkommen geführt. Innerhalb kürzester Zeit erreichten uns etwa zwanzigmal so viele Anfragen wie üblich. Unsere Mitarbeiter arbeiten mit großem Einsatz daran, die aufgelaufenen Anfragen zu bearbeiten. Dennoch kommt es derzeit zu deutlich längeren Wartezeiten als gewohnt. Wir bitten hierfür ausdrücklich um Entschuldigung. Unsere oberste Priorität lag zunächst darauf, die Sicherheitslücken auf den Kundenservern so schnell wie möglich zu schließen. Dabei mussten wir die Bearbeitung einzelner Anliegen und die gewohnte Kommunikation vorübergehend zurückstellen. Wir wissen, dass diese Situation für viele Kunden mit Einschränkungen und Unannehmlichkeiten verbunden war.

Wie geht es weiter?

Die notwendigen Sicherheitskorrekturen für die beiden bekannt gewordenen PHP-Sicherheitslücken wurden inzwischen auf unseren Kundenservern eingespielt. Wir beobachten die weitere Sicherheitslage aufmerksam und prüfen auch neue Erkenntnisse zu möglichen Angriffsmethoden. Grundsätzlich empfehlen wir, für Webseiten möglichst aktuelle PHP-Versionen einzusetzen. Ältere PHP-Versionen haben wir zwar ebenfalls gegen die beiden aktuellen Sicherheitslücken abgesichert, sie erhalten jedoch vom PHP-Projekt keine regulären Sicherheitsupdates mehr.

Abschließend möchten wir uns für Ihr Verständnis und Ihre Geduld bedanken.

Die Ereignisse vom 21. Oktober haben uns vor eine außergewöhnliche Herausforderung gestellt. Unser gesamtes Team hat alles darangesetzt, die notwendigen Sicherheitsmaßnahmen so schnell wie möglich umzusetzen und mögliche Risiken für unsere Kunden zu minimieren.

Wir sind überzeugt, dass es richtig war, der Sicherheit Ihrer Webseiten und Daten in dieser Situation höchste Priorität einzuräumen.

—————————————————————————

– English version –

Dear ALL-INKL.COM customer,

On 21 October 2026, two exceptionally critical security vulnerabilities in the PHP programming language were disclosed, affecting numerous websites and web hosting providers worldwide. Below, we provide an overview of the measures taken, the current status and the impact of these events on our services.

What happened?

The two security vulnerabilities (CVE-2026-109618 and CVE-2026-109619) enabled attackers, under certain conditions, to execute malicious code on affected web servers without first logging in. What was particularly critical was that this did not even require a security vulnerability in the website itself. A specially crafted request to the PHP interpreter alone was sufficient. Numerous versions of PHP that have been in use for many years were affected. This therefore constituted an exceptional security situation that posed considerable challenges for many web server operators. Unlike many common security vulnerabilities, it was not just individual applications that were affected, but the PHP interpreter itself. This posed a potential risk to a very large number of websites worldwide. It was therefore crucial for us to minimise the time between the disclosure of the vulnerabilities and the installation of the necessary updates.

What measures have we taken?

Our technicians responded immediately and had already prepared and activated additional protective measures even before the security updates were released. Once the security fixes were published, we began, as a matter of the highest priority, to create, test and deploy the necessary patches to our customers' servers. In doing so, we had to take into account numerous different versions of PHP. Within around eight hours, we were able to deploy the necessary security updates across our hosting infrastructure. We have now patched all PHP versions offered by us against the two security vulnerabilities that have come to light. This explicitly includes older versions such as PHP 5.6 and PHP 7.x. Our customers did not need to carry out any updates themselves.

Why were some of our services unavailable?

To prevent potential attacks on our central systems and the customer data managed through them, we took the precautionary measure of taking parts of our own infrastructure offline. Amongst others, this affected our customer management system (Members Area), KAS, Webmail and WebFTP, as well as our own website. We made this decision deliberately in order to avoid major security risks and, at the same time, to be able to focus all available technical resources on securing the customer servers as quickly as possible. Our customers' websites were not affected by these precautionary shutdowns. Even whilst Webmail was restricted, the normal sending and receiving of emails via appropriately configured email programmes continued to function.

Has customer data been compromised?

Based on the information available to us at present, we have no concrete evidence that these security vulnerabilities have been successfully exploited on our systems. However, we cannot completely rule out the possibility of exploitation prior to the installation of the security updates. We are continuing to monitor our systems for suspicious activity. Regardless of this, we recommend that you regularly check websites and applications for unusual changes, such as unknown files, unexpected alterations or newly created user accounts.

Why is it taking longer to process support enquiries?

These events have led to an exceptionally high volume of support enquiries. Within a very short space of time, we received around twenty times as many enquiries as usual. Our staff are working tirelessly to process the backlog of enquiries. Nevertheless, waiting times are currently significantly longer than usual. We sincerely apologise for this. Our top priority initially was to close the security vulnerabilities on our customers' servers as quickly as possible. In doing so, we had to temporarily put the processing of individual enquiries and our usual communication on hold. We are aware that this situation has caused restrictions and inconvenience for many customers.

What happens next?

The necessary security patches for the two PHP vulnerabilities that have come to light have now been installed on our customers' servers. We are monitoring the security situation closely and are also reviewing new findings regarding potential attack methods. As a general rule, we recommend using the most up-to-date PHP versions for websites wherever possible. Whilst we have also patched older PHP versions against these two current security vulnerabilities, they no longer receive regular security updates from the PHP project.

Finally, we would like to thank you for your understanding and patience.

The events of 21 October presented us with an extraordinary challenge. Our entire team has done everything in its power to implement the necessary security measures as quickly as possible and to minimise potential risks to our customers.

We are convinced that it was the right decision to give the highest priority to the security of your websites and data in this situation.

—————————————————————————

Mit freundlichen Grüßen

Neue Medien Münnich

Read Entire Article