Sie haben nachgesehen, Ihre Website läuft auf einer PHP-Fassung von vor dem 21. Oktober, und beim Anbieter passiert nichts. Die Hotline nennt eine Wartezeit von vierzig Minuten, das Ticket ist seit gestern unbeantwortet, und auf der Statusseite steht der Eintrag von voriger Woche. Das ist eine unangenehme Lage, aber keine ausweglose. Dieser Beitrag beschreibt, was Sie selbst tun können und in welcher Reihenfolge.
Zuerst: Sind Sie wirklich betroffen?
Bevor Sie eskalieren, sollte die Grundlage stimmen.
Die vollständige Versionsnummer zählt. „PHP 8.3" sagt nichts – geschlossen ist die Lücke erst ab 8.3.36. Wenn im Kundenbereich nur die Hauptversion steht, ist das kein Beleg dafür, dass nicht gepatcht wurde. Viele Anbieter zeigen bewusst nur die Hauptversion an und aktualisieren die Unterversion im Hintergrund, oft innerhalb von Stunden.
Fragen Sie konkret, nicht allgemein. „Sind Sie von PHP2Shell betroffen?" bekommt eine Marketingantwort. „Welche vollständige PHP-Version läuft auf unserem Paket, Stand jetzt?" bekommt eine Zahl.
Sehen Sie auf der Statusseite nach, bevor Sie anrufen. Große Anbieter haben am 21. Oktober zentral aktualisiert und schreiben das dort hin. Dann hat sich das Thema erledigt.
Was Sie selbst umstellen können – meist mehr als gedacht
Bei den meisten Webhosting-Paketen können Sie die PHP-Version selbst wählen. Der Punkt heißt „PHP-Version", „PHP-Einstellungen" oder „PHP-Konfiguration" und liegt im Kundenbereich, oft bei der jeweiligen Domain.
Wenn dort eine gepatchte Fassung angeboten wird: umstellen. Vorher sichern. Innerhalb derselben Hauptversion ist das in aller Regel unkritisch – genau dafür gibt es Unterversionen.
Wenn nur die Hauptversion wählbar ist (also „8.3" ohne Unternummer): Dann entscheidet der Anbieter, welche Unterversion dahintersteckt, und Sie können nur fragen.
Wenn Ihre Hauptversion 7.x oder älter ist: Hier hilft kein Patch mehr, für diese Zweige erscheint keiner. Der Wechsel auf eine unterstützte Version ist die einzige Lösung, und wie der abläuft, steht in PHP 8.1 auf 8.4 migrieren.
Die Notbehelfe, solange nichts passiert
Keiner davon schließt die Lücke. Alle verschaffen Zeit.
Datei-Uploads blockieren. Alle bekannten Angriffe laufen über Anfragen im Format `multipart/form-data`. Wenn Ihr Paket eine vorgelagerte Absicherung oder eine eigene Konfigurationsdatei erlaubt, lässt sich das dort unterbinden. Ihr Kontaktformular funktioniert danach nicht mehr – das ist der Preis.
`session.upload_progress.enabled` auf `Off`. Lässt sich bei vielen Anbietern in einer eigenen `php.ini` oder `.user.ini` setzen. Nimmt einem der bekannten Angriffswege die Grundlage.
Nur lesende Zugriffe zulassen. Wenn die Seite ohnehin statisch ist, kostet die Beschränkung auf GET und HEAD nichts.
Oder abschalten. Das BSI nennt das ausdrücklich als Alternative zum Patch. Eine Website, die einen Tag nicht erreichbar ist, kostet Umsatz. Ein übernommener Server kostet mehr.
Eskalieren – aber richtig
Wenn der Anbieter nicht reagiert, hilft Lautstärke wenig. Was hilft, ist Präzision.
Schriftlich, mit konkreter Frage und Frist. Nicht „bitte um Rückmeldung", sondern: „Welche vollständige PHP-Version läuft auf Paket X, Stand heute? Wann wird auf eine der am 21.10.2026 veröffentlichten Fassungen aktualisiert? Wir bitten um Antwort bis morgen 12 Uhr."
Auf die BSI-Warnung verweisen. Aktenzeichen 2026-297981-1032, Warnstufe 3. Das ist keine Meinung eines Kunden, sondern eine Behördenwarnung – und das ändert erfahrungsgemäß die Bearbeitungsreihenfolge.
Den Vertrag heranziehen. Viele Hostingverträge enthalten eine Zusage zum Einspielen von Sicherheitsupdates. Steht dort eine Frist, nennen Sie sie.
Antworten aufheben. Mit Datum. Wenn später etwas passiert, ist der Nachweis, dass Sie rechtzeitig und konkret gefragt haben, Ihre Position gegenüber Versicherung und Aufsicht.
Wann der Wechsel fällig ist
Ein Anbieter, der an einem Tag wie dem 21. Oktober nicht erreichbar ist, wird es beim nächsten Mal auch nicht sein. Drei Anzeichen, bei denen sich ein Wechsel rechnet:
Keine Statusseite. Bei einem Vorfall dieser Größe informiert ein ordentlicher Anbieter von sich aus. Wer das nicht tut, hat entweder kein Verfahren oder keine Leute.
Keine aktuelle PHP-Version im Angebot. Wenn ein Jahr nach Veröffentlichung von PHP 8.4 nur bis 8.2 wählbar ist, ist das kein Zufall, sondern ein Zustand.
Keine Antwort binnen eines Arbeitstages auf eine konkrete Sicherheitsfrage. Das ist der klarste Befund von allen.
Aber nicht mitten im Vorfall wechseln. Ein Umzug unter Zeitdruck erzeugt neue Fehler. Sichern Sie erst die Lage – notfalls durch Abschalten –, und planen Sie den Wechsel danach in Ruhe.
Der Fall, über den niemand spricht: der Dienstleister dazwischen
Häufiger als ein schweigender Hoster ist eine schweigende Agentur. Die Website liegt bei einem großen Anbieter, der längst aktualisiert hat – aber zwischen Ihnen und dem Paket sitzt jemand, der die Zugangsdaten hat und nicht ans Telefon geht.
Dann ist das kein technisches, sondern ein vertragliches Problem. Zwei Dinge sollten Sie unabhängig davon klären:
Auf wen ist die Domain registriert? Auf Ihr Unternehmen, nicht auf die Agentur. Lässt sich in Minuten über eine Whois-Abfrage prüfen. Wenn dort nicht Ihr Name steht, ist das die dringendere Baustelle.
Haben Sie eigene Zugangsdaten zum Hosting-Paket? Nicht die der Agentur, sondern eigene. Ohne diese sind Sie bei jeder Lage auf jemanden angewiesen, der vielleicht gerade Urlaub hat.
Checkliste: erste Schritte
- Vollständige PHP-Version im Kundenbereich nachsehen, nicht nur die Hauptversion
- Statusseite des Anbieters prüfen, bevor Sie anrufen
- Wenn selbst wählbar: nach Sicherung auf eine gepatchte Fassung umstellen
- Schriftlich mit konkreter Frage und Frist nachfassen, BSI-Aktenzeichen nennen
- Vertrag auf zugesagte Fristen für Sicherheitsupdates ansehen
- Solange nichts passiert: Notbehelfe setzen oder Seite abschalten
- Alle Antworten mit Datum aufbewahren
- Prüfen, auf wen die Domain registriert ist und ob Sie eigene Zugänge haben
Wie DAVINCI unterstützt
Wir stellen fest, welche PHP-Fassung Ihre Website tatsächlich nutzt – auch wenn der Kundenbereich nur die Hauptversion zeigt –, formulieren die Nachfrage an Ihren Anbieter so, dass sie beantwortet werden muss, und übernehmen die Umstellung, wenn Sie es nicht selbst machen wollen. Einen ersten Eindruck liefert der kostenlose PHP-Sicherheitscheck, Klarheit der Quick-Check für 49 Euro. Wenn Sie den Betrieb dauerhaft abgeben wollen: IT-Betrieb und Support. Kontakt über die Kontaktseite.
Häufige Fragen
Unser Anbieter sagt, er sei „nicht betroffen". Reicht das?
Nein. Betroffen ist jede PHP-Installation, die Webanfragen bedient – das hat das PHP-Projekt selbst so veröffentlicht. „Nicht betroffen" kann nur heißen: bereits aktualisiert. Lassen Sie sich die Versionsnummer nennen, dann ist die Frage beantwortet.
Dürfen wir die PHP-Version einfach selbst umstellen?
Bei den meisten Paketen ja, dafür gibt es den Schalter. Das Risiko liegt nicht im Umstellen, sondern darin, ob Ihre Website mit der neuen Version läuft. Innerhalb derselben Hauptversion ist das selten ein Problem, über Hauptversionen hinweg schon.
Was, wenn danach die Seite weiß bleibt?
Zurückstellen – das geht im Kundenbereich in Sekunden. Dann ins Fehlerprotokoll sehen. Deshalb vorher sichern und nicht am Freitagabend umstellen.
Können wir Schadenersatz verlangen, wenn der Hoster zu spät patcht?
Das hängt vom Vertrag und vom konkreten Schaden ab und ist nichts, was sich pauschal beantworten lässt. Die Grundlage dafür schaffen Sie heute: schriftlich fragen, Antworten mit Datum aufheben. Die Bewertung gehört zu Ihrer Rechtsberatung.
Wir wissen gar nicht, wo unsere Website liegt.
Das kommt häufiger vor, als man denkt – besonders nach zwei Agenturwechseln. Eine Whois-Abfrage zur Domain und ein Blick auf die Nameserver führen meist zum Anbieter. Diese Frage sollten Sie unabhängig vom aktuellen Anlass klären.
Verwandte Themen: Wer hier weiterdenkt, liest bei WordPress-Sicherheit, PHP-Migration und PHP2Shell betroffen weiter.
