Webhosting, das die nächste PHP-Lücke
übersteht — ohne Offline-Schalten.
Mehrere Schutzschichten statt Hoffnung: Filter vor PHP, isolierte Container ohne Shell, Erkennung, garantierte Reaktionszeiten und Nachweise pro Kunde. Auch für Seiten, die woanders gehostet sind.
PHP2Shell: Angriffe vor dem Patch
Die Lücke wird ausgenutzt, bevor der eigentliche Anwendungscode läuft. Login, App-Rechte und WordPress-Updates helfen deshalb nicht.
Ausnutzung wurde bereits beobachtet, bevor die Lücke öffentlich war.
Korrigierte Versionen für die aktuell unterstützten PHP-Zweige.
Für ältere Zweige gibt es nur Quellcode-Patches. Viele Hoster und Systeme laufen genau dort.
NSA, NCSC und CERT-EU raten, nicht patchbare Systeme vom Netz zu nehmen. HostOps ist die Alternative dazu.
Ehrlich gesagt: Übergangsmaßnahmen sind kein vollständiger Fix
Konfigurationshärtung, Filterregeln und Container-Isolation senken das Risiko deutlich, ersetzen aber kein Update auf eine korrigierte PHP-Version. Wir sagen Ihnen offen, welcher Stand bei Ihnen erreicht ist, und planen den Weg zu einer unterstützten Version. Wir versprechen keine 100-prozentige Sicherheit.
Quellen: Datadog Security Labs · NCSC-NL
Sechs Schutzschichten statt einer Firewall
Jede Schicht fängt ab, was die vorherige durchlässt. So wird aus einer Zero-Day-Lücke ein kontrollierter Vorfall statt einer Kompromittierung.
1Edge-Filter
WAF- und Caddy-Regeln ('Virtual Patching') werden binnen Minuten nach Bekanntwerden ausgerollt: überlange Feldnamen, Null-Bytes, Grenzen für die Body-Größe.
2Isolierte Laufzeit
Ein Container pro Site, nur unterstützte PHP-Versionen, fest gepinnte Images, keine Shell im Image, schreibgeschützt, Speicherlimit, kein ausgehender Netzverkehr ohne Freigabe.
3Erkennung
Alarm, wenn ein PHP-Prozess eine Shell startet, bei auffälligen Fehlerlogs und neuen Dateien (Webshell-Scan, Integritätsprüfung).
4Patch-Reaktion
CVE-Feed, Abgleich mit Ihrem Inventar, Image neu bauen, Testinstanz, gestaffelter Rollout. Zielwert bei kritischen Lücken: Absicherung binnen 4 Stunden.
5Wiederherstellung
Stündliche, unveränderliche Snapshots, Site-Code in Git, Neuaufbau statt Bereinigung nach einer Kompromittierung.
6Transparenz
CVE-Bericht pro Kunde mit Zeitstempeln, Statusseite und Unterstützung bei NIS2-Meldungen.
Drei Gründe, warum klassisches Hosting hier nicht reicht
Patchen allein ist zu langsam
Zwischen Angriffsbeginn und Fix liegen Tage, bei älteren PHP-Zweigen gibt es gar kein fertiges Update. Ohne Schutz vor dem Patch bleibt nur Abschalten.
Eine Lücke darf nicht alles öffnen
Auf Shared Hosting teilen sich viele Seiten Prozess, Rechte und Netz. In HostOps bleibt ein Treffer auf eine Site begrenzt.
Sie müssen nachweisen können, was passiert ist
NIS2 und Kundenverträge verlangen Belege. Wir liefern pro CVE, wann welches System geschützt war.
Vom Alarm zum Nachweis in vier Schritten
Jeder Produktiv-Eingriff läuft hinter einer menschlichen Freigabe. Keine blinden Massen-Updates.
Bestandsaufnahme
Wir erfassen PHP-Versionen, Betriebsart und Exposition Ihrer Seiten. Nur Systeme, die Ihnen gehören oder für die ein Auftrag vorliegt.
Absichern
Edge-Filter und Härtung sofort, danach Umzug auf unterstützte, isolierte Container.
Überwachen
Erkennung rund um die Uhr, Alarme laufen in einen Incident-Prozess mit Zuständigkeit.
Nachweisen
Sie erhalten einen Bericht je CVE: erkannt, geschützt, gepatcht, mit Zeitstempeln.
Vier typische Ausgangslagen
Alle vier Gruppen haben dasselbe Problem: PHP ist überall, aber niemand will für jede Lücke nachts patchen.
KMU mit WordPress oder CMS
Ihre Website läuft bei einem günstigen Hoster. Sie wollen wissen, ob sie betroffen ist, und einen Betreiber, der reagiert.
Agenturen
Viele Kundenseiten, ein Haftungsrisiko. Sie brauchen eine feste Reaktionszeit und Berichte, die Sie weitergeben können.
Systemhäuser und Reseller
Sie betreuen Kunden mit gemischtem Bestand und wollen die Lösung unter eigener Marke anbieten.
Bestandskunden von Intelego
Wir kennen Ihre Systeme. Wir prüfen sie gezielt und härten sie im Rahmen Ihrer bestehenden Betreuung.
Nachweise für Auditoren und Kunden
HostOps liefert die Belege mit: wer wann welche Lücke erkannt, abgesichert und behoben hat.
Patch- und Schwachstellenmanagement mit Zeitnachweis, Unterstützung bei der Erstmeldung.
Technische Maßnahmen dokumentiert, Betrieb in der EU, Unterstützung bei Meldung einer Verletzung.
Management technischer Schwachstellen und Änderungsmanagement mit Freigabe und Protokoll.
Auftragsverarbeitung und Reaktionszeiten schriftlich, nicht als Marketing-Aussage.
Reseller und Agenturen
Sie liefern die Kundenbeziehung, wir den Betrieb. Ihre Marke, Ihre Preise, unsere Plattform und Reaktionszeit.
White-Label
Eigenes Branding, eigene Domain für Status- und Berichtsseiten.
Einheitliche Reaktion
Eine CVE-Reaktion gilt für alle Ihre Kunden gleichzeitig.
Berichte für Ihre Kunden
Fertige Nachweise pro Kunde und Vorfall, direkt weitergebbar.
Vier Stufen — vom Selbsttest bis zum Betrieb
Starten Sie klein und wachsen Sie mit Ihrer Lage.
- PHP-Version und Betriebsart bestimmen
- Betroffenheit für PHP2Shell einordnen
- Handlungsempfehlung in Klartext
- Nur eigene Systeme oder mit schriftlichem Auftrag
- Härtung der PHP-Konfiguration
- Edge-Filter (Virtual Patch)
- Speicherlimits und Container-Grenzen
- Erkennungs-Regeln für Shell-Aufrufe
- Abschlussbericht mit Restrisiko
- Isolierte Container pro Site
- Unterstützte PHP-Versionen, gepinnte Images
- Patch-Reaktion mit Zielzeit für kritische Lücken
- Stündliche unveränderliche Snapshots
- CVE-Bericht pro Kunde
- Auf Wunsch: TLS über CertOps
- Eigene Marke und Berichte
- Mehrere Endkunden unter einem Vertrag
- Einheitliche CVE-Reaktion
- Zweite-Ebene-Support für Ihr Team
Alle Preise zzgl. USt., B2B. Aktuelle Werte stehen im Konfigurator. Zeitangaben zur Patch-Reaktion sind Zielwerte und hängen von der Upstream-Verfügbarkeit ab.
Häufige Fragen
Warum hilft ein WordPress-Update nicht?
Die Lücke liegt in PHP selbst und wird beim Verarbeiten des Requests ausgelöst, bevor WordPress oder ein Plugin läuft. Ein CMS-Update ändert daran nichts. Entscheidend sind die PHP-Version und Schutz vor PHP.
Bin ich betroffen?
Wahrscheinlich ja, wenn Ihre Seite PHP nutzt. Betroffen sind PHP 5.4 bis 8.5 in allen gängigen Betriebsarten. Der Quick-Check ordnet Ihre Lage ein.
Reicht ein Filter oder eine WAF?
Er senkt das Risiko deutlich, ist aber eine Übergangsmaßnahme. Deshalb kombiniert HostOps mehrere Schichten und führt Sie zu einer unterstützten PHP-Version.
Was ist mit PHP 7.4 oder 8.0?
Dafür gibt es nur Quellcode-Patches. Wir betreiben solche Zweige nur befristet und gehärtet und planen mit Ihnen die Migration.
Prüfen Sie auch fremde Seiten?
Nein. Wir prüfen nur Systeme, die Ihnen gehören oder für die ein schriftlicher Auftrag vorliegt. Ungefragtes Scannen fremder Systeme ist in Deutschland potenziell strafbar.
Was passiert nach einer Kompromittierung?
Wir bauen aus sauberem Code und einem unveränderlichen Snapshot neu auf, statt zu bereinigen. Sie erhalten einen Vorfallbericht, der Sie bei Meldepflichten unterstützt.
Wo laufen die Daten?
In der EU. Mit Ihnen schließen wir einen Auftragsverarbeitungsvertrag.
Wissen, wo Sie stehen
Wir prüfen Ihre PHP-Systeme, sichern sie ab und zeigen Ihnen den Weg
zu einem Betrieb, der die nächste Lücke übersteht.