Unsere eigenen Server haben die PHP-Sicherheitslücke bereits geschlossen, Pingoclock läuft auf gepatchter PHP-Version. Wenn du in den letzten Stunden Down-Meldungen von uns bekommen haben, ist das in aller Regel kein Zeichen für einen Hack. In diesem Artikel erfährst du, was bei der PHP2Shell-Lücke passiert ist, warum so viele Websites kurz offline waren und was du jetzt prüfen solltest.
PHP-Sicherheitslücke: Warum dein Postfach voller Down-Meldungen war
Am 21. Oktober 2026 haben viele Website-Betreiber im deutschsprachigen Raum ungewohnt viele Benachrichtigungen bekommen. Seiten waren erreichbar, dann nicht, dann wieder. Bei Pingoclock gingen entsprechend viele Down-Meldungen raus.
Der erste Gedanke ist meistens: „Bin ich gehackt worden?” Diese Sorge ist verständlich. In diesem Fall ist sie in den meisten Fällen unbegründet. Die Ursache liegt eine Ebene tiefer, nämlich in PHP selbst.
Was bei PHP2Shell passiert ist
Unter dem Namen PHP2Shell kursieren zwei kritische Lücken: CVE-2026-109618 und CVE-2026-109619. Sie stecken nicht in WordPress oder einem Plugin, sondern in PHP. Laut Advisory können Angreifer ohne Login fremden Code mit den Rechten des Webservers ausführen. Das bedeutet im Ernstfall die Übernahme der Website. Bewertet wurden beide Lücken mit einem CVSS-Wert von 9,2.
Zuerst tauchten Informationen in einem Forenbeitrag auf. Das PHP-Team kündigte daraufhin einen Notfall-Release an und veröffentlichte am 21. Oktober die Updates 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Es gibt Berichte über erste Angriffsversuche, offiziell bestätigt sind sie nicht. Die technischen Details und Versionsfragen hat unser Schwesterprojekt ausführlich aufbereitet: PHP2Shell: PHP-Lücken CVE-2026-109618 und -109619 im Überblick.
Warum so viele Websites betroffen sind
PHP ist die Grundlage von WordPress, TYPO3, Drupal, Joomla, Shopware und Laravel. Im DACH-Raum laufen Millionen Websites darauf, oft auf Shared Hosting, bei dem sich der Hoster um PHP kümmert. Genau deshalb ist die Lücke so unangenehm: Ein aktuelles WordPress mit aktuellen Plugins schützt nicht, wenn das PHP darunter veraltet ist. Auch ein Sicherheits-Plugin ersetzt das Update nicht.
Dazu kommt ein zweites Problem. Für PHP 8.1 und älter gibt es keinen regulären Fix. Wer dort noch läuft, ist auf Backports seines Hosters angewiesen oder muss umziehen.
Warum Pingoclock so viele Warnungen verschickt hat
Pingoclock prüft deine Website von außen, genau so, wie ein Besucher sie sieht. Wenn die Seite nicht antwortet oder einen Fehler liefert, schlagen wir Alarm. Das haben wir getan, und es war korrekt.
Viele Hoster haben auf die Lücke mit einer Sicherheitsmaßnahme reagiert. Sie haben Websites zeitweise vom Netz genommen oder blockiert, bis die PHP-Version aktualisiert war. Für Besucher und für unser Monitoring sieht das aus wie ein Ausfall. Mit einem Angriff hat es nichts zu tun. Im Gegenteil: Der Hoster hat deine Seite geschützt.
Wenn deine Seite danach wieder lief, bist du in den meisten Fällen auf der sicheren Seite. Prüfen solltest du trotzdem diese Punkte:
- Welche PHP-Version läuft jetzt? Im WordPress-Backend unter „Website-Zustand” siehst du das.
- Hat dein Hoster das Update schriftlich bestätigt?
- Ist in deinem Tarif noch eine alte PHP-Version eingestellt, etwa 7.4 oder 8.1?
- Gibt es neue Administratoren oder unbekannte PHP-Dateien im Upload-Ordner?
Bleibt eine Seite länger offline oder zeigt sie ein ungewöhnliches Fehlerbild, frag beim Hoster nach.
Wie Pingoclock bei einer PHP-Sicherheitslücke hilft
Pingoclock ist ein DSGVO-konformes Uptime Monitoring aus Deutschland, das Websites bei einer PHP-Sicherheitslücke wie PHP2Shell von außen überwacht und Ausfälle sofort meldet. Der Free Plan überwacht bis zu 20 Domains kostenlos, der Pro Plan kostet 3,99 € im Monat. Entwickelt und gehostet wird in Deutschland.
Das Wichtigste in so einer Lage ist, dass du es zuerst erfährst. Im Free Plan prüfen wir stündlich per E-Mail-Benachrichtigung, im Pro Plan alle 5 Minuten, optional mit Webhook. Wer mehrere Kundenseiten betreut, findet auf der Seite Uptime Monitoring für Agenturen die passende Übersicht. Mit den individuellen Monitoring-Reports kannst du Kunden hinterher zeigen, wann genau welche Seite nicht erreichbar war. So wird aus einem Ausfall ein belegbarer Vorgang.
Mehr zur Technik hinter der Überwachung findest du auf der Übersichtsseite Uptime Monitoring.
Ein Szenario, das viele Agenturen kennen
Stell dir vor, du betreust 25 Kundenseiten. Morgens um sieben kommen zwölf Down-Meldungen, innerhalb von zehn Minuten. Ohne Monitoring erfährst du davon erst, wenn der erste Kunde anruft.
Mit Monitoring siehst du dagegen sofort ein Muster. Fast alle betroffenen Seiten liegen beim selben Hoster, die anderen laufen normal. Das spricht für eine Maßnahme des Hosters und gegen zwölf einzelne Hacks. Du schreibst deinen Kunden proaktiv, dass die Seiten wegen einer Sicherheitslücke kurz geschützt wurden und bald wieder online sind. Aus einem möglichen Vertrauensverlust wird ein Beleg für gute Betreuung.
Häufige Fragen
Heißt „Website down” automatisch „gehackt”?
Nein. Ausfälle haben viele Ursachen, von Wartung über Überlast bis zu Schutzmaßnahmen des Hosters. Bei PHP2Shell war letzteres der häufigste Grund. Ein Down-Alarm sagt dir, dass etwas nicht stimmt, aber nicht, was.
Mein Hoster kümmert sich doch um PHP. Brauche ich trotzdem Monitoring?
Ja, gerade dann. Der Hoster überwacht seine Server, nicht deine Website aus Besuchersicht. Ob deine Seite nach einem Update wirklich wieder sauber läuft, siehst du erst durch eine Prüfung von außen.
Wir haben Pingoclock gebaut, weil wir solche Tage selbst erlebt haben: Man will es erfahren, bevor der Kunde anruft. Den kostenlosen Free Plan startest du hier. Wer Intervalle von 5 Minuten und Webhooks braucht, wechselt jederzeit auf den Pro Plan. Weitere Beiträge rund um Ausfälle und Monitoring findest du in der Blog-Übersicht.
Kostenlos starten, später ohne Datenverlust upgraden
Keine Kreditkarte. Server in Deutschland.
