Die erste Welle war technisch: patchen, prüfen, durchatmen. Die zweite ist es nicht. Sie kommt per E-Mail, meist von der Einkaufsabteilung eines größeren Kunden, und sie sieht harmlos aus:
> „Im Zusammenhang mit den bekannt gewordenen PHP-Schwachstellen bitten wir um Rückmeldung, ob Ihre Systeme betroffen waren und zu welchem Zeitpunkt die Aktualisierungen eingespielt wurden. Bitte antworten Sie bis Freitag."
Zwei Sätze, und sie sind schwerer zu beantworten als die ganze Patcherei davor.
Warum diese Mail jetzt kommt
Wer selbst unter Aufsicht steht, muss seine Lieferkette prüfen. Das steht in NIS2, es steht in jedem Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO, und es steht in den Fragebögen der Versicherer. Nach einem Ereignis dieser Größenordnung geht genau dieselbe Mail an alle Dienstleister gleichzeitig raus – an die Agentur, den Hoster, das Steuerbüro, den Logistiker.
Das Unangenehme daran: Die Frage prüft nicht Ihre Sicherheit, sondern Ihre Nachweisfähigkeit. Und das sind zwei verschiedene Dinge. Ein gut betreuter Server kann beides sein – sauber und unbelegbar.
Was in diesen Fragebögen steht
Die Formulierungen unterscheiden sich, die Fragen dahinter kaum. Es sind im Kern fünf:
| Frage | Was wirklich gemeint ist |
|---|---|
| Waren Sie betroffen? | Lief bei Ihnen eine verwundbare Version? |
| Wann haben Sie aktualisiert? | Wie lange stand das Fenster offen? |
| Gab es einen unbefugten Zugriff? | Haben Sie nachgesehen – und womit? |
| Sind Daten abgeflossen, die uns betreffen? | Müssen wir selbst melden? |
| Wie haben Sie das geprüft? | Ist Ihre Antwort belastbar oder geraten? |
Die letzte Frage ist die, an der sich alles entscheidet. „Wir sind nicht betroffen" ohne Angabe, wie man das festgestellt hat, ist keine Auskunft, sondern eine Behauptung.
Die drei Antworten, die Sie geben können
Die belegbare Antwort
„Auf unserem Webserver lief PHP 8.3.31. Das Update auf 8.3.36 wurde am 21.10.2026 um 18:20 Uhr eingespielt, protokolliert in der Paketverwaltung. Die Zugriffsprotokolle vom 17. bis 21. Oktober wurden auf die bekannten Angriffsmuster durchgesehen; Befund negativ. Geprüft wurden außerdem Dateiänderungen, geplante Aufgaben und ausgehende Verbindungen. Der Prüfbericht liegt bei."
Das ist kein Freibrief – aber es ist eine Aussage, mit der die Gegenseite arbeiten kann.
Die ehrliche Antwort mit Lücke
„Das Update wurde am 21.10. eingespielt. Eine Prüfung auf vorherige Zugriffe war nur eingeschränkt möglich, weil unsere Zugriffsprotokolle lediglich sieben Tage zurückreichen. Für den Zeitraum davor können wir keine Aussage treffen. Im geprüften Zeitraum gibt es keine Auffälligkeiten."
Diese Antwort ist besser als ihr Ruf. Sie benennt die Grenze, statt sie zu überspielen. Jeder erfahrene Prüfer weiß, dass Protokolle rotieren. Was ihn misstrauisch macht, ist nicht die Lücke, sondern ihre Verschleierung.
Die Antwort, die Ihnen schadet
„Bei uns ist alles in Ordnung, wir sind nicht betroffen."
Ohne Version, ohne Datum, ohne Prüfumfang. Das liest sich wie eine Abwehrformel, und es ist in zwei Richtungen gefährlich: Der Kunde eskaliert, und falls später doch etwas auftaucht, steht eine schriftliche Zusicherung im Raum, die nicht gedeckt war.
Was Sie tatsächlich belegen können – und was nicht
Belegbar ist der Zeitpunkt des Updates. Unter Linux steht er in der Paketverwaltung, unter Windows im Installationsprotokoll. Das ist der härteste Beleg, den Sie haben, und er lässt sich nicht nachträglich erfinden.
Belegbar ist der Prüfumfang. Welche Quellen wurden angesehen, über welchen Zeitraum, mit welchem Ergebnis. Ein Bericht mit Datum ist auch dann etwas wert, wenn er nichts gefunden hat – weil er zeigt, dass gesucht wurde.
Nicht belegbar ist Abwesenheit. Niemand kann beweisen, dass nichts passiert ist. Wer das zusichert, sichert mehr zu, als er halten kann. Die korrekte Formulierung lautet nicht „es ist nichts passiert", sondern „im geprüften Zeitraum wurden keine Hinweise auf einen unbefugten Zugriff gefunden".
Und eine Besonderheit dieses Vorfalls: Bei dieser Art von Fehler kann Arbeitsspeicher nach außen gelangen, ohne dass eine Datei verändert wird. Ein sauberer Dateibefund sagt deshalb nichts über Sitzungen und Zugangsdaten aus. Warum das so ist und was daraus folgt, steht in Zugangsdaten können weg sein, ohne dass eine Datei angefasst wurde.
Der Zeitstempel, den fast niemand hat
Es gibt eine Frage, an der die meisten Antworten scheitern, und sie ist überraschend banal: Seit wann lief die verwundbare Version?
Nicht „wann haben Sie gepatcht" – das weiß man meistens. Sondern: Wie lange war das Fenster offen? Wer am 21. Oktober aktualisiert hat, war seit der Veröffentlichung einen Tag verwundbar. Wer PHP seit 2023 nicht angefasst hat, war es Jahre. Für die Gegenseite ist das ein Unterschied, und für Ihren Versicherer auch.
Diese Angabe steht in der Paketverwaltung, und zwar im Installationsdatum der vorherigen Version. Sehen Sie heute nach, solange sie noch da ist.
Wer eigentlich antworten muss
Ein Punkt, der regelmäßig für Streit sorgt: Wenn Ihre Website bei einem Hoster liegt und von einer Agentur betreut wird, sind drei Parteien beteiligt – und gefragt werden Sie, weil Sie der Vertragspartner sind.
Sie müssen also einsammeln, was Sie selbst nicht wissen. Fragen Sie beide schriftlich und mit Frist, und übernehmen Sie deren Angaben als deren Angaben, nicht als Ihre eigene Feststellung. Die Formulierung „nach Auskunft unseres Hosters vom 22.10.2026 wurde dort am 21.10. aktualisiert" ist korrekt und schützt Sie. „Unsere Systeme wurden am 21.10. aktualisiert" ist es nicht, wenn Sie es nur gehört haben.
Was zu tun ist, wenn der Hoster gar nicht reagiert, steht in Der Hoster hat nicht gepatcht.
Eine Vorlage, die Sie anpassen können
Kurz halten. Ein Fragebogen wird nicht gelesen, er wird abgehakt.
> Betreff: Rückmeldung zu den PHP-Schwachstellen (CVE-2026-109618 / -109619) > > Sehr geehrte Frau …, > > zu Ihrer Anfrage vom … nehmen wir wie folgt Stellung. > > Betroffenheit: Auf unserem Webserver lief PHP in Version …, die von den genannten Schwachstellen betroffen war. > > Behebung: Die Aktualisierung auf Version … erfolgte am … um … Uhr. Beleg: Protokoll der Paketverwaltung. > > Prüfung auf unbefugten Zugriff: Geprüft wurden Zugriffsprotokolle des Zeitraums … bis …, Dateiänderungen im Webverzeichnis, geplante Aufgaben, hinterlegte Zugänge und ausgehende Verbindungen. Dabei wurden keine Hinweise auf einen unbefugten Zugriff gefunden. > > Grenzen dieser Aussage: Die Zugriffsprotokolle reichen … Tage zurück; für den Zeitraum davor ist keine Aussage möglich. Ein Abfluss von Speicherinhalten lässt sich technisch nicht ausschließen und wäre auf dem System nicht nachweisbar. > > Betroffenheit Ihrer Daten: Nach derzeitigem Kenntnisstand liegen keine Anhaltspunkte dafür vor, dass Daten aus unserer Zusammenarbeit betroffen sind. > > Für Rückfragen stehen wir zur Verfügung.
Der Abschnitt zu den Grenzen ist nicht die Schwäche dieses Schreibens, sondern seine Stärke. Er macht aus einer Behauptung eine Auskunft.
Checkliste: erste Schritte
- Heute nachsehen, wann die vorherige PHP-Version installiert wurde – diese Angabe verschwindet
- Updatezeitpunkt aus der Paketverwaltung sichern, nicht aus dem Gedächtnis
- Zugriffsprotokolle wegkopieren, bevor sie rotieren
- Hoster und Agentur schriftlich mit Frist befragen
- Prüfumfang schriftlich festhalten, auch wenn nichts gefunden wurde
- Keine Abwesenheit zusichern, sondern den Befund beschreiben
- Die Antwort ablegen – dieselbe Frage kommt beim nächsten Vorfall wieder
- Eine Person benennen, die solche Anfragen künftig beantwortet
Wie DAVINCI unterstützt
Wir führen die Prüfung durch und fassen sie so zusammen, dass Sie das Ergebnis weitergeben können: mit Datum, benanntem Prüfumfang und benannten Grenzen – auch dann, wenn das Ergebnis lautet, dass nichts gefunden wurde. Die technische Grundlage dafür können Sie selbst legen, mit dem kostenlosen Prüfwerkzeug für den eigenen Server; den Blick von außen liefert der PHP-Sicherheitscheck. Bei einem bestätigten Vorfall übernimmt unser Incident Response die Aufarbeitung. Für eine schnelle Einordnung gibt es den Quick-Check, erreichbar sind wir über die Kontaktseite.
Häufige Fragen
Muss ich auf so einen Fragebogen überhaupt antworten?
Vertraglich meistens ja. In Auftragsverarbeitungsverträgen nach Artikel 28 DSGVO sind Auskunfts- und Mitwirkungspflichten die Regel, und in Rahmenverträgen größerer Kunden stehen sie fast immer. Unabhängig davon ist Schweigen die schlechteste Variante: Es wird als Eingeständnis gelesen.
Was, wenn ich gar nichts belegen kann?
Dann schreiben Sie genau das – und was Sie stattdessen getan haben. „Protokolle liegen nicht vor, deshalb haben wir den Server neu aufgesetzt und alle Zugänge erneuert" ist eine tragfähige Antwort. Eine Behauptung ohne Grundlage ist es nicht.
Reicht der Bericht eines Prüfwerkzeugs als Nachweis?
Als Beleg für den Prüfumfang ja, als forensisches Gutachten nein. Er zeigt nachvollziehbar, was wann angesehen wurde. Für Fragebögen reicht das in aller Regel; für eine Auseinandersetzung mit der Versicherung oder einer Aufsichtsbehörde braucht es mehr.
Kann ich haftbar werden, wenn meine Auskunft sich später als falsch herausstellt?
Das hängt daran, was Sie zugesichert haben. Eine beschriebene Feststellung mit genannten Grenzen ist etwas anderes als eine Zusicherung ohne Einschränkung. Genau deshalb gehört der Abschnitt zu den Grenzen in jedes solche Schreiben.
Unser Kunde will ein Zertifikat. Gibt es das?
Für einen einzelnen Vorfall nicht. Was es gibt, ist eine datierte Prüfbestätigung mit benanntem Umfang und benanntem Prüfer. Wer Ihnen ein „Sicherheitszertifikat" für PHP2Shell verkaufen will, verkauft Ihnen ein Stück Papier.
Wie lange sollten wir diese Unterlagen aufbewahren?
Mindestens so lange, wie Ansprüche aus der Zusammenarbeit möglich sind – in der Praxis drei Jahre. Der Aufwand entsteht ohnehin nur einmal.
Verwandte Themen: Wer hier weiterdenkt, liest bei PHP2Shell betroffen, PHP2Shell und Akuter Verdacht auf Rechnungsbetrug weiter.
Im Text erwähnt
Quellen
- PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet · Wiz Research
- PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit, Cybersicherheitswarnung 2026-297981-1032, Version 1.1 (21.10.2026) · BSIamtlich
- IT-Grundschutz-Baustein OPS.1.1.5 Protokollierung (Edition 2023) · BSIamtlich
- Auftragsverarbeiter · Art. 28 DSGVO
