TL;DR: Am 17. Oktober 2026 ging ein externer Audit-Bericht an eine Hochschule: 445 Befunde, konsolidiert zu 9 eigenständigen Höchstrisiken, jede Aussage mit gehashtem Beleg. Fünf Tage lang kam keine Eingangsbestätigung. Am 21. Oktober veröffentlichte das BSI einen Notfallhinweis zu zwei RCE-Lücken in der PHP-Engine, am 22. Oktober waren die Online-Dienste der Hochschule offline — öffentlich erklärt als „IT-Probleme". Dieser Text behauptet keinen Ursachenzusammenhang. Er dokumentiert eine Chronologie und das, was daran strukturell ist: Ein Bericht ohne Empfänger ist kein Risikomanagement, und „IT-Probleme" ist keine Kategorie, aus der eine Organisation lernt.
Worum es geht
Geprüft wurde die öffentlich erreichbare Infrastruktur einer Hochschule — die Hauptdomain und die Alt-Domain aus der Zeit vor der Umbenennung: extern, nicht-intrusiv, ohne Anmeldung, ohne Ausnutzung, ohne Schreibzugriff. Eine Flotte aus 48 Agenten-Units lief in vier Wellen gegen 83 und mehr auflösende Hostnamen auf 27 IPs in sechs Netzen. 5.312 Beweisdateien wurden gehasht und in einem SHA-256-Manifest festgehalten.
Das Ergebnis: 445 Befunde — 28 hoch, 90 mittel, 186 niedrig, 141 informativ — die sich zu 9 eigenständigen Höchstrisiken konsolidieren. Die vierte Welle hat jeden hohen und mittleren Befund auf frischen Artefakten erneut ausgeführt: 15 von 15 waren reproduzierbar. Reproduzierbarkeit ist der Unterschied zwischen einem Verdacht und einem Befund.
Und dann der Satz, der diesen ganzen Text trägt: Ein Bericht ist kein Zustand. Er ist ein Angebot.
Die Chronologie
17. Oktober: Übergabe
Der vollständige Audit-Bericht ging an die verantwortlichen Stellen der Hochschule — mit allen technischen Nachweisen, Risikoeinstufungen und dem Hash-Manifest, damit jede Aussage nachprüfbar bleibt. Der Bericht beschreibt Exposition und Wirkung, nicht die Behebung: Er sagt, was offen steht, wer es erreicht und was ein geduldiger Angreifer damit tun kann. Die Entscheidung darüber, was daraus folgt, liegt beim Betreiber.
17. bis 21. Oktober: Stille
Im Disclosure-Log steht für diesen Zeitraum keine Eingangsbestätigung, keine Rückfrage, kein benannter Ansprechpartner. Fünf Tage sind für eine Behebung keine lange Frist. Für eine Eingangsbestätigung sind sie eine lange Frist — und das ist der entscheidende Unterschied: „nicht gepatcht" ist ein Zustand, „nicht angekommen" ist ein Prozessversagen. Eine automatische Ticket-Antwort hätte gereicht, um beides auseinanderzuhalten.
21. Oktober: eine fremde Uhr
Während der Bericht unbeantwortet war, veröffentlichte das PHP-Projekt Notfall-Patches für zwei Remote-Code-Execution-Schwachstellen in der PHP-Engine selbst: CVE-2026-109618 (OOM-Korruption) und CVE-2026-109619 (verbliebener globaler Zustand, Use-after-free), beide mit CVSS v4.0 9,2, beide ohne Anmeldung ausnutzbar. Korrigierte Releases: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35; ältere Zweige erhalten keine offizielle Korrektur. Der BSI-Hinweis dazu ist BITS-H Nr. 2026-297981-1132 (Version 1.1, Kritikalität 3/Orange, TLP:CLEAR).
Zwei Eigenschaften machen daraus mehr als eine Patch-Notiz. Erstens greift es, bevor Anwendungscode läuft: Im demonstrierten Pfad — Apache mit mod_php — tritt die verwundbare Sequenz beim Request-Start auf, also vor jeder Validierung, jedem Rate-Limit und jedem Logging eines bösartigen Bodys. Zweitens wurde es ausgenutzt, bevor es öffentlich war: Ein Versuch wurde vier Tage vor der Offenlegung beobachtet, nach dem Release stiegen die Versuche stark an.
Für diesen Bestand war das kein Nebenschauplatz. Die Inventarisierung war pro Anwendung sauber — Mail-Plattform, Listen-Host, Dokumentenportal, Monitoring, Lernplattform. Aber nicht pro Laufzeit: Niemand fragte, welchen Interpreter welcher Host ausführt, in welcher Version, und wer ihn besitzt.
22. Oktober: Abschaltung
Am 22. Oktober meldete die Hochschule den Ausfall ihrer Online-Dienste — öffentlich begründet mit „technischen bzw. IT-Problemen". Die gemeldeten Befunde und der Disclosure-Hinweis kamen in dieser Mitteilung nicht vor.
Was belegt ist — und was nicht
Diese Trennung ist der Kern eines seriösen Disclosure-Berichts, deshalb steht sie hier explizit.
Belegt ist: das Datum der Übergabe, der Inhalt des Berichts, die Reproduzierbarkeit der Befunde, der BSI-Hinweis vom 21. Oktober mit seinen CVE-Nummern und der CVSS-Bewertung, der Ausfall am 22. Oktober und die offizielle Begründung dafür.
Nicht belegt ist: dass der Ausfall durch die gemeldeten Lücken verursacht wurde. Ebenso wenig, dass der Bericht gelesen wurde oder die Abschaltung eine Reaktion darauf war. Wer das behauptet, hat mehr Beweise als ich.
Warum dann dieser Text? Weil die Frage, ob beides zusammenhängt, nur eine Stelle beantworten kann: die Hochschule. Transparenz macht sie beantwortbar. Wenn der Ausfall nichts mit dem Bericht zu tun hat, ist die Antwort ein Satz. Wenn er etwas damit zu tun hat, ist dieselbe Antwort der Anfang einer Lernkurve — für die Hochschule, für andere Bildungseinrichtungen und für alle, die solche Berichte schreiben.
Warum die Laufzeit das eigentliche Thema ist
Ein Anwendungsinventar beantwortet die Frage „Welche Software läuft bei uns?". Ein Laufzeitinventar beantwortet die Frage „Was führt unseren Code aus?". Die zweite Frage ist die, die am 21. Oktober plötzlich zählte — und sie stand in keinem der Dokumente, die ich zu sehen bekam.
Das Muster ist nicht hochschulspezifisch. Es ist die normale Folge davon, dass Anwendungen über Jahre wachsen und Laufzeiten mitwandern, ohne dass jemand sie besitzt. Ein Listen-Host, der seit 2010 „einfach funktioniert", ist kein Sicherheitsproblem, solange niemand hinsieht. Er wird eines, sobald eine Lücke im Interpreter veröffentlicht wird, für den es keinen Patch mehr gibt. Dann ist die Frage nicht mehr „Wie schnell patchen wir?", sondern „Wie schnell finden wir überhaupt, was betroffen ist?".
Was 445 Befunde bedeuten
Die neun Höchstrisiken sind keine neun Fehler. Sie sind vier Muster.
| Muster | Was offen stand | Warum es zählt |
|---|---|---|
| Mail- und Identity-Kern | Exchange-Farm zwei Security-Updates zurück, EWS und Autodiscover beantworten anonyme Basic/NTLM-Anfragen außerhalb von SSO und MFA, DMARC auf p=none | Jedes irgendwo erbeutete Passwort erreicht eine Mailbox ohne Identitäts-Gateway und ohne MFA; gebrandete Phishing-Mail wird zugestellt statt abgewiesen |
| Vergessener Listen-Host | Mailman 2.1.14 von 2010 auf einem Apache-2.0.63-Origin, 16 versions-anwendbare CVEs, kein CSRF-Token in irgendeinem Web-Formular | Ein präparierter Link gegen einen eingeloggten Listen-Administrator bedeutet Listenübernahme und Massenmail unter der echten Marke der Hochschule |
| Daten-Endpunkte | Filr-Appliance im 9,8er-Auth-Bypass-Bereich, Grafana-/metrics unauthentisiert, abgekündigtes eLabFTW | Ein Megabyte Metriken inklusive Benutzernamen, Routen und Zählern; ein Auth-Bypass vor dem Dokumentenportal |
| Flaches Substrat | DNS, Identity, VPN und CMS in einem /24, 103 interne Namen in gültigen CT-Zertifikaten, null Rate-Limit und keine WAF in zwei vollen Wellen | Die Landkarte liegt öffentlich und erneuert sich alle 60 bis 90 Tage; nichts hätte einen Angreifer gebremst |
Die vollständige CVE-Zuordnung — unter anderem CVE-2026-70571 und CVE-2026-70279 für die Exchange-Farm — steht im Audit-Steckbrief (passwortgeschützt).
Was nicht das Problem war
Ein ehrlicher Audit nennt auch das, was gut ist — sonst ist er ein Verkaufsgespräch. Auf den Hauptoberflächen gab es null Dritt-Origins und null Pre-Consent-Tracker; die Lernplattform lief auf dem aktuellen Security-Release und schloss genau die RCE, die über die erreichbaren Endpunkte verkettbar gewesen wäre; die Exchange-Edge war hart, außer an ihren zwei By-Design-Oberflächen; Backup-Hygiene und Basis-Hygiene der Hauptseite waren sauber. Das Estate war nicht nachlässig. Es war an genau den Stellen unverteidigt, an denen niemand mehr hinsah.
Responsible Disclosure ist ein Prozess, kein Akt der Höflichkeit
Der Begriff wird oft als Kulisse benutzt: Der Forscher ist großzügig, der Betreiber dankbar. Tatsächlich ist es eine Arbeitsteilung mit beidseitigen Pflichten.
Was die Forschenden-Seite schuldet: keine Ausnutzung über den Nachweis hinaus, keine Datenexfiltration, keine Veröffentlichung von Exploit-Code, Datenminimierung im Bericht, nachvollziehbare Belege statt Behauptungen — und die Bereitschaft, eine Frist zu akzeptieren, die länger ist als die eigene Ungeduld.
Was die Betreiberseite schuldet: eine Eingangsbestätigung innerhalb weniger Werktage, ein benannter Eigentümer für den Fall, eine dokumentierte Triage-Entscheidung — auch ein „wird nicht behoben" mit Begründung ist eine Antwort —, einen erreichbaren Kanal (security.txt, PGP-Key, eine Adresse, die nicht ins Leere läuft) und eine Aussage darüber, ob man den Melder als Verbündeten behandelt oder als Risiko.
Die 90 Tage, die in der Branche als Konvention gelten, sind kein Gesetz. Sie sind eine Erwartung, die sich daran bemisst, ob in dieser Zeit etwas passiert. Eine Frist verstreicht nicht dadurch, dass niemand antwortet.
Die stille Woche ist der Befund
Ein unbeantworteter Bericht ist kein offener Befund. Er ist ein unbewertetes Risiko — und das ist die schlechtere Kategorie, weil niemand es misst.
Drei Kennzahlen genügen, um zu wissen, ob eine Organisation ein Disclosure-Verfahren hat oder nur eine E-Mail-Adresse:
- Time-to-Acknowledge — wie lange bis zur ersten menschlichen Antwort?
- Time-to-Triage — wie lange bis zu einer Entscheidung, mit Schweregrad und Eigentümer?
- Time-to-Patch — wie lange bis zur Behebung, gemessen ab Triage, nicht ab Meldung?
Wer diese drei Zahlen nicht nennen kann, hat keinen Prozess. Und wer bei einem Ausfall nur „IT-Probleme" sagt, nimmt der Öffentlichkeit und anderen Einrichtungen die Möglichkeit, aus dem Fall zu lernen. Die Richtung der Regulierung — NIS2, Cyber Resilience Act — geht ohnehin zu Meldepflichten und nachvollziehbarer Kommunikation. Öffentliche Einrichtungen werden künftig mehr sagen müssen als „technische Probleme". Wer das freiwillig tut, bevor er muss, behält die Deutungshoheit.
Häufige Fragen
Was ist Responsible Disclosure?
Ein Verfahren, bei dem eine Sicherheitslücke vertraulich an den Betreiber gemeldet wird, bevor sie öffentlich wird — mit dem Ziel, dass sie behoben ist, bevor jemand sie ausnutzt. Der Kern ist die Reihenfolge: erst melden, dann beheben, dann erzählen. Wer sie umdreht, betreibt kein Responsible Disclosure, sondern eine Show.
Wie lange darf eine Organisation brauchen?
Für die Eingangsbestätigung wenige Werktage, für die Triage ein bis zwei Wochen, für die Behebung so lange, wie der Schweregrad es rechtfertigt. Entscheidend ist nicht die Zahl, sondern die Sichtbarkeit: Ein Betreiber, der sagt „wir haben es gesehen, wir bewerten bis Freitag, der Patch kommt im nächsten Zyklus", hat den Prozess im Griff. Schweigen hat keinen Zeitplan.
Warum nennt der Audit-Steckbrief das Ziel, dieser Artikel aber nicht?
Weil es zwei verschiedene Textsorten sind. Der Essay Die Tür neben der Eingangstür beschreibt dasselbe Engagement ohne Zielnamen, damit das Muster wiederverwendbar bleibt — er ist eine Lehre, kein Bericht. Der Audit-Steckbrief ist passwortgeschützt und nennt das Ziel, weil er die Befunde am konkreten System belegen muss. Dieser Text bleibt beim Muster: Er trennt, was belegt ist, von dem, was offen ist.
Der technische Deep Dive
- Audit-Steckbrief (passwortgeschützt) — alle Befunde, Schweregrade, Belegpfade, die neun Höchstrisiken und der Nachtrag zum PHP-Notfallhinweis.
- Die Tür neben der Eingangstür — die ausführliche Analyse des Musters: warum die SSO-Ausnahme der eigentliche Perimeter war, wie ein Listen-Host von 2010 zur Übernahme führt und was Zertifikate über ein Estate verraten.
Fazit
- Ein Bericht ist erst dann ein Risiko, wenn ihn jemand bewertet. Die Übergabe ist der Anfang des Verfahrens, nicht sein Abschluss.
- Fünf Tage Stille sind kein Patch-Problem. Sie sind ein Prozessproblem — und Prozessprobleme sind billiger zu beheben als jede CVE.
- Inventarisiere Laufzeiten, nicht nur Anwendungen. Die Komponente, die jeden Request ausführt, ist die, die niemand inventarisiert.
- „IT-Probleme" ist keine Kategorie. Wer sie benutzt, verliert den Lerneffekt — und die Deutungshoheit an die, die später darüber schreiben.
- Transparenz ist keine Schwäche. Eine Hochschule, die sagt „wir hatten einen Sicherheitsvorfall, hier ist der Stand", verliert weniger Vertrauen als eine, die schweigt und später erklären muss, warum.
Quellen
- Audit-Steckbrief einer öffentlichen Hochschule, Prüfdatum 17.10.2026 (5.312 Beweisdateien, SHA-256-Manifest)
- BSI, IT-Sicherheitshinweis BITS-H Nr. 2026-297981-1132, Version 1.1 vom 21.10.2026, Kritikalität 3/Orange, TLP:CLEAR
- PHP-Sicherheitshinweis vom 21.10.2026 (GHSA-w8hw-w9fx-j79w) zu CVE-2026-109618 und CVE-2026-109619, CVSS v4.0 9,2