Sicherheitslücke Website: Was Hoster und Agentur prüfen sollten

Lass bei einer Sicherheitslücke Website und Server getrennt prüfen: Der Hoster klärt die von ihm betriebene Umgebung, die Agentur die Anwendung. Du brauchst eine begründete Aussage zur Betroffenheit, einen Nachweis wirksamer Schutzmaßnahmen und eine Prüfung auf mögliche Angriffsspuren. Ein installiertes Update beantwortet diese Fragen nicht allein.

Kurz gesagt: Ein aktuelles Redaktionssystem ist kein Nachweis für eine abgesicherte Serverumgebung. Hoster und Agentur müssen bestätigen, welche Systeme geprüft und aktualisiert wurden. Ob vorher ein Angriff stattgefunden hat, ist eine eigene Untersuchung.

Stand: Oktober 2026. Die rechtlichen Hinweise ersetzen keine Rechtsberatung. Falls personenbezogene Daten betroffen sein könnten, beziehe Datenschutzverantwortliche und bei Bedarf einen Anwalt oder die zuständige Aufsichtsbehörde ein.

Was bedeuten die aktuellen PHP-Sicherheitsupdates für deine Website?

Die PHP-Sicherheitsupdates sind ein konkreter Anlass, die Laufzeitumgebung deiner Website prüfen zu lassen. Ein aktuelles CMS allein reicht dafür nicht aus.

Laut dem PHP News Archive 2026 veröffentlichte das PHP-Projekt am 21. Oktober 2026 Sicherheitsupdates für CVE-2026-109618 und CVE-2026-109619. Unter bestimmten Bedingungen ermöglichen diese Schwachstellen fremden Code ohne Anmeldung auszuführen, berichtet das PHP-Projekt in seiner Meldung von 2026. CVE-Kennungen dienen dazu, veröffentlichte Sicherheitslücken eindeutig zu benennen.

PHP ist eine Programmiersprache, deren Laufzeitumgebung auf dem Server den Code vieler Websites ausführt. Das CMS ist dagegen das Redaktionssystem, in dem du etwa Texte oder Immobilienangebote pflegst. Die im PHP-Archiv 2026 beschriebenen Lücken betreffen eine technische Ebene unterhalb dieser Website-Anwendung.

Die Antwort „Wir haben das CMS gestern aktualisiert“ klärt deshalb die PHP-Frage nicht. Umgekehrt bedeutet die Nutzung von PHP noch nicht, dass die konkrete Website betroffen ist. Dafür muss der Betreiber den eingesetzten Softwarestand und die Konfiguration prüfen.

Komm.ONE berichtete am 22. Oktober 2026 über vorsorglich abgeschaltete PHP-Anwendungen, darunter kommunale Websites und Onlinedienste. Eine vorsorgliche Abschaltung beweist keinen erfolgreichen Angriff. Auch Hetzner dokumentierte gesonderte PHP-Aktualisierungen, was die getrennte Prüfung der Serverumgebung unterstreicht.

Sicherheitslücke Website: Was solltest du zuerst veranlassen?

Kontaktiere Hoster und Agentur gemeinsam und lass einen technischen Verantwortlichen benennen. Die erste Rückmeldung sollte sagen, was betroffen sein könnte, welche Schutzmaßnahme nötig ist und wann der nächste Status kommt.

Dafür musst du keine Serverbefehle kennen. Du musst verhindern, dass beide Anbieter aufeinander warten. Schicke ihnen eine gemeinsame Nachricht:

Bitte prüft unsere Websites und zugehörigen Anwendungen auf die gemeldete PHP-Sicherheitslücke. Bestätigt, welche Systeme betroffen sind und worauf eure Bewertung beruht. Sichert relevante Protokolle, prüft mögliche Angriffsspuren und nennt notwendige Schutzmaßnahmen. Wer koordiniert die technische Bearbeitung, und wann erhalten wir den nächsten Status?

Ergänze die Hauptdomain und bekannte Nebenanwendungen. Dazu zählen etwa ein Bewerbungsportal oder eine alte Website auf einer Subdomain. Eine Subdomain ist eine zusätzliche Adresse unter deiner Domain, beispielsweise für ein Kundenportal.

Lass vorerst nichts ungeplant löschen oder neu installieren. Dadurch können Spuren verloren gehen. Die Sicherung solcher Spuren darf allerdings eine dringend nötige Schutzmaßnahme nicht unnötig verzögern.

Was prüft der Hoster, was prüft die Agentur?

Der Hoster prüft typischerweise die Serverumgebung, die Agentur die Website-Anwendung. Wer tatsächlich zuständig ist, hängt davon ab, wer die jeweiligen Systeme betreibt und pflegt.

Bei einem selbst verwalteten Server kann die Serverpflege ebenfalls bei der Agentur liegen. Ein Hostingkonto beantwortet diese Frage nicht. Lass die Aufgaben deshalb ausdrücklich zuordnen.

Die Übergabe zwischen den Zuständigen muss ausdrücklich erfolgen. Meldet der Hoster die PHP-Aktualisierung als abgeschlossen, sollte die Agentur die Website anschließend testen. Eine funktionierende Startseite ersetzt dabei keinen Test des Anfrageformulars.

Fehlen dir Zugänge oder ein erreichbarer Ersatzansprechpartner, wird die Bearbeitung schwieriger. Der Ratgeber zur Abhängigkeit vom Softwareentwickler erklärt, welche Konten und Unterlagen du selbst kontrollieren solltest.

Welcher Nachweis zeigt, dass das Update wirklich greift?

Der Update-Nachweis muss sich auf die Umgebung beziehen, die deine Website tatsächlich verwendet. „Das Update ist installiert“ reicht nicht, wenn weiterhin ein alter Prozess läuft oder eine Nebenanwendung eine andere PHP-Version nutzt.

Auf einem Server können mehrere PHP-Umgebungen parallel laufen. Deine Hauptwebsite und ein älteres Buchungsformular müssen deshalb nicht denselben Softwarestand verwenden. Auch automatisch ausgeführte Hintergrundaufgaben können getrennt eingerichtet sein.

Bitte den Betreiber um diese Angaben:

• Welche Domains und Anwendungen wurden geprüft?
• Welche PHP-Umgebung nutzt jede Anwendung tatsächlich?
• Welche Sicherheitskorrektur wurde eingespielt, und seit wann ist sie aktiv?
• Wurden nötige Neustarts der Dienste durchgeführt?
• Welche Anwendungen sind noch ungeprüft oder eingeschränkt?

Eine Versionsnummer allein kann ebenfalls täuschen. Manche Betriebssystemanbieter übernehmen Sicherheitskorrekturen in bestehende Softwarestände, ohne die Hauptversionsnummer zu ändern. Der Betreiber sollte erklären können, woran er die eingespielte Korrektur erkennt.

Eine allgemeine Statusmeldung des Hosters ist daher nur ein Ausgangspunkt. Frage konkret: „Gilt diese Aktualisierung für den Server und die PHP-Umgebung unserer Website?“

Wie lässt sich ein möglicher Angriff prüfen?

Ein möglicher Angriff muss unabhängig vom Update untersucht werden. Die Sicherheitskorrektur beseitigt nicht automatisch bereits eingeschleuste Dateien oder fremde Benutzerkonten.

Lass Zugriffsprotokolle und Fehlerprotokolle sichern. Darin stehen technische Ereignisse, etwa aufgerufene Adressen oder fehlgeschlagene Programmabläufe. Je nach System helfen zusätzlich Aufzeichnungen über Anmeldungen und Dateiänderungen.

Die Untersuchung muss zur gemeldeten Schwachstelle passen. Hoster und Agentur suchen beispielsweise nach verdächtigen Aufrufen und unerwarteten Dateien. Ein auffälliger Aufruf allein beweist noch keinen erfolgreichen Angriff.

Frag ausdrücklich, welchen Zeitraum die Prüfung abdeckt. Wurden ältere Protokolle bereits gelöscht, lässt sich dieser Zeitraum möglicherweise nicht mehr ausreichend untersuchen. Keine gefundenen Angriffsspuren sind kein Beweis dafür, dass es keinen Angriff gab.

Bei konkreten Einbruchsspuren kann ein spezialisierter IT-Sicherheitsdienstleister nötig sein. Eine Webagentur muss nicht jede Untersuchung selbst leisten können. Sie sollte aber klar sagen, welche Prüfungen sie übernimmt und wo zusätzliche Unterstützung gebraucht wird.

Wann müssen Datenschutzverantwortliche dazu?

Datenschutzverantwortliche sollten früh beteiligt werden, sobald personenbezogene Daten betroffen sein könnten. Dazu können Kontaktanfragen, Bewerbungsunterlagen oder Kundenkonten gehören.

Ob eine meldepflichtige Datenschutzverletzung vorliegt, hängt vom konkreten Vorfall ab. Warte mit dieser Einordnung nicht, bis sämtliche technischen Arbeiten abgeschlossen sind. Hole bei Unsicherheit anwaltlichen Rat oder Unterstützung der zuständigen Aufsichtsbehörde ein.

Wann sollte die Website abgeschaltet werden?

Eine vorübergehende Abschaltung kann sinnvoll sein, wenn sich die Gefährdung nicht anders rechtzeitig begrenzen lässt. Der technische Verantwortliche sollte begründen, ob eine einzelne Funktion gesperrt werden kann oder die gesamte Anwendung betroffen ist.

Eine vorgeschaltete Wartungsseite allein ist keine verlässliche Schutzmaßnahme. Bleibt die verwundbare Anwendung dahinter erreichbar, kann auch die Gefahr bestehen bleiben. Entscheidend ist, den gefährdeten Zugriff tatsächlich zu unterbinden.

Kläre parallel, wie Kunden dich erreichen. Fällt die Terminbuchung aus, braucht es einen Ersatzweg, etwa eine Telefonnummer. Dafür kann eine statische Hinweisseite dienen, also eine Seite ohne die betroffene Programmlogik.

Lass außerdem die Bedingungen für die Wiederfreigabe festhalten. „Wir schalten später wieder ein“ hilft dir wenig, wenn dein Team weiterhin Anfragen erwartet und Werbeanzeigen auf die Website führen.

Was muss vor der Wiederfreigabe getestet werden?

Vor der Wiederfreigabe müssen die Schutzmaßnahmen wirksam sein und die wichtigen Geschäftsabläufe funktionieren. Bei einem bestätigten Einbruch gehört außerdem die nachvollziehbare Bereinigung dazu.

Teste einen vollständigen Vorgang. Bei einem Makler könnte ein Testinteressent ein Objekt öffnen, eine Anfrage absenden und die vorgesehene Bestätigung erhalten. Dein Team prüft anschließend, ob die Anfrage im richtigen Postfach oder Verwaltungssystem angekommen ist.

Verwende eindeutig erkennbare Testdaten statt echter Kundenangaben. Prüfe auch den Verwaltungsbereich, wenn dein Team dort täglich arbeitet. Weitere Beispiele für solche Abläufe findest du in der Software-Abnahme-Checkliste.

Eine Datensicherung ist nach einem Einbruch nicht automatisch ein sauberer Ausgangspunkt. Sie kann bereits manipulierte Dateien enthalten. Vor einer Wiederherstellung muss deshalb geklärt werden, welcher Stand geeignet ist und wie die Sicherheitslücke geschlossen bleibt.

Lass außerdem bewerten, welche Zugangsdaten möglicherweise offengelegt wurden. Dazu gehören auch geheime Schlüssel, mit denen die Website auf angebundene Dienste zugreift. Deren Austausch sollte aus einer bereinigten Umgebung erfolgen.

Fordere eine schriftliche Freigabe mit dem geprüften Umfang und offenen Aufgaben. Für jede offene Aufgabe braucht es einen Verantwortlichen und einen Termin.

Schicke Hoster und Agentur die gemeinsame Prüfanfrage samt Liste deiner Websites. Bitte zuerst um einen benannten Ansprechpartner und einen festen Zeitpunkt für die nächste Rückmeldung.