Kurz gesagt: White-Label-IT-Sicherheit heißt für Ihre Agentur: Sie behalten die Kundenbeziehung, wir erledigen im Hintergrund die Sicherheitsarbeit. Bei PHP2Shell bedeutet das Inventar aller Kundenseiten, Priorisierung nach Risiko, Patch und Neustart je Server und ein Nachweis je Kunde, den Sie weitergeben können.
Warum Agenturen bei PHP2Shell besonders unter Druck stehen
Eine Agentur mit vielen Kunden betreut selten eine einheitliche Landschaft. Ein Teil der Seiten liegt auf eigenen Servern mit Plesk, ein Teil bei den Hostern der Kunden, einige Altprojekte auf PHP-Versionen, die längst keine offiziellen Updates mehr bekommen. Dazu kommen verschiedene Systeme: WordPress, TYPO3, Shopware, Craft CMS, Laravel-Eigenentwicklungen.
Bei einer Lücke in PHP selbst trifft es alle Projekte gleichzeitig. Kunden erwarten eine Antwort, ob ihre Seite sicher ist, und das Projektteam ist mit laufenden Aufträgen ausgelastet. Viele Wartungsverträge regeln das CMS, aber nicht den Server darunter.
Hinzu kommen Systeme, die in keiner Projektliste mehr auftauchen: Staging-Umgebungen auf Subdomains, Kampagnenseiten aus abgeschlossenen Projekten, Testinstallationen von Entwicklern auf eigenen vServern. Sie laufen oft auf älteren PHP-Versionen, werden nicht überwacht und tragen trotzdem den Namen Ihrer Agentur oder Ihres Kunden. Für automatisierte Scans sind sie genauso sichtbar wie die Hauptseite.
Welche Fragen Ihre Kunden jetzt stellen
- Ist meine Website betroffen, und ist sie inzwischen gepatcht?
- Wurde vor dem Patch schon etwas eingeschleust?
- Gilt das Update des CMS als Schutz? Nein, ein CMS-Update schließt die PHP-Lücke nicht.
- Muss ich meine Website vom Netz nehmen? Das BSI empfiehlt es für Server, die nicht sofort aktualisiert werden können.
Auf jede dieser Fragen braucht Ihre Agentur eine belegbare Antwort pro Kunde, nicht eine Rundmail mit allgemeinen Aussagen.
Wie White-Label-IT-Sicherheit für Agenturen abläuft
Wir arbeiten als Teil Ihres Teams, aber ohne eigenen Kundenkontakt. Die Aufteilung ist klar:
| Aufgabe | Ihre Agentur | PHP SOS |
|---|---|---|
| Kundenkommunikation und Abrechnung | ja | nein |
| Inventar aller Kundenseiten mit PHP-Stand | liefert Zugänge | erstellt und pflegt es |
| Patch, Neustart, Prüfung je Server | gibt Wartungsfenster frei | führt aus oder koordiniert mit Hostern |
| Prüfung auf Kompromittierung | erhält Befund | sucht nach Webshells und Auffälligkeiten |
| Nachweis je Kunde | gibt weiter | erstellt neutral oder in Ihrem Format |
Bei Seiten auf fremden Hostern holen wir die Bestätigung des Paketstands ein. Die angezeigte Versionsnummer allein reicht nicht, weil Backports sie unverändert lassen können.
Priorisieren Sie zuerst Server mit Apache und mod_php, wo das PHP-Team das Risiko am höchsten einstuft, dann Shops und Seiten mit Logins, dann Projekte auf PHP 8.1 und älter. Statische Altprojekte, die niemand mehr braucht, schalten Sie besser ab, statt sie zu patchen.
Mehrere Kundenseiten auf einem Server: Isolation prüfen
Auf Agentur-Servern teilen sich oft viele Kundenseiten eine Maschine. Wird eine davon kompromittiert, entscheidet die Trennung darüber, ob der Angreifer auch an die anderen kommt. Wichtig sind eigene Systembenutzer und PHP-FPM-Pools pro Website, saubere Dateirechte und Grenzen wie open_basedir. Auf Plesk-Servern lassen sich diese Einstellungen pro Abonnement prüfen.
Nach dem Patch gilt: Alle Pools und Worker neu starten. Erst dann laufen keine alten PHP-Prozesse mehr im Speicher. Logs ab dem 20.10.2026 sollten für jede Kundenseite aufbewahrt werden.
Kundeninformation: was belegt ist und was nicht
Die größte Versuchung in dieser Lage ist eine beruhigende Sammelmail. Sicherer ist eine Aussage pro Kunde, die nur enthält, was belegt ist: welcher Server, welcher PHP-Paketstand, wann neu gestartet, ob eine Prüfung auf Kompromittierung stattgefunden hat und mit welchem Ergebnis. Was noch offen ist, steht ebenfalls darin.
Formulierungen wie „Ihre Seite ist sicher“ vermeiden Sie besser. Ein Patch schließt die Lücke, beweist aber nicht, dass vorher nichts passiert ist. Wer das ehrlich trennt, steht später nicht in der Erklärungspflicht, falls doch ein Befund auftaucht.
Wartungsverträge nach PHP2Shell neu fassen
Viele Agenturverträge regeln Updates von CMS und Erweiterungen, schweigen aber zum Server. Nutzen Sie die Lage, um für jeden Kunden festzuhalten, wer PHP aktualisiert, wer Neustarts verantwortet, wer bei einem Vorfall entscheidet und welche Leistungen gesondert beauftragt werden. Auch eine Vereinbarung zur Auftragsverarbeitung mit allen beteiligten Dienstleistern gehört dazu. Die vertragliche Ausgestaltung klären Sie mit Ihrer Rechtsberatung.
Wie hilft PHP SOS konkret?
- Wir übernehmen die Bestandsaufnahme aller Kundenseiten mit PHP-Version, Betriebsart, Hoster und Zuständigkeit.
- Über unseren PHP-Patch-Service patchen wir Ihre eigenen Server, starten alle Worker neu und belegen das je Kunde.
- Wir prüfen priorisierte Seiten auf Kompromittierung und bereinigen bei Befund, bis der Vorfall abgeschlossen und dokumentiert ist.
- Wir liefern Textbausteine für Ihre Kundeninformation, die Sie anpassen und selbst versenden.
- Danach übernehmen wir auf Wunsch mit einem Security-Wartungsvertrag die laufende Sicherheitsbetreuung im Hintergrund.
Häufige Fragen
Treten Sie gegenüber unseren Kunden auf?
Nur wenn Sie das möchten. Im White-Label-Modell arbeiten wir ausschließlich im Hintergrund, und alle Kommunikation läuft über Ihre Agentur. Unsere Dokumentation liefern wir neutral oder in Ihrem Format.
Brauchen wir dafür einen Vertrag zur Auftragsverarbeitung?
Wenn wir auf Systeme mit personenbezogenen Daten Ihrer Kunden zugreifen, ist in der Regel eine Vereinbarung zur Auftragsverarbeitung nötig, oft als Unterauftragsverarbeitung. Wie das in Ihre bestehenden Verträge passt, klären Sie mit Ihrer Rechtsberatung. Wir stellen die nötigen Angaben zu unseren Tätigkeiten bereit.
Was ist mit Kundenseiten, deren Server wir gar nicht verwalten?
Liegen Kundenseiten bei fremden Hostern, holen wir in Ihrem Namen oder mit Ihren Vorlagen Bestätigungen zu Patchstand und Neustart ein. Wo nur FTP- oder CMS-Zugang besteht, prüfen wir, was von dort aus möglich ist, und kennzeichnen offen, was nur der Hoster belegen kann.
Können wir das auch nach PHP2Shell dauerhaft auslagern?
Ja. Viele Aufgaben wiederholen sich bei jeder Lücke: Inventar pflegen, Patches einspielen, Neustarts belegen, Auffälligkeiten melden. Diese Arbeit lässt sich als laufende Betreuung im Hintergrund organisieren.