Am 12. August 2026 bestätigte MyDr sp. z o.o., ein polnischer Anbieter von Software für elektronische Patientenakten, auf [der eigenen Vorfallseite](https://pro.mydr.pl/portal-info), man sei „Ziel einer externen, vorsätzlichen kriminellen Handlung“ geworden, die „einen Teil der Daten“ betreffe. Unabhängig davon erklärten die Angreifer gegenüber dem polnischen Sicherheitsportal Zaufana Trzecia Strona, sie besäßen 18.814.422 eindeutige PESEL-Nummern, die polnische Personenkennziffer. MyDr bestätigt weder diese noch eine andere Zahl. Was MyDr mit vier weiteren großen Datenlecks auf drei Kontinenten teilt, ist enger gefasst und leichter zu beheben als jede der Ursachen: Wollte jemand von außen etwas melden, gab es dafür keinen vorgesehenen Weg. Ein Vulnerability Disclosure Program hätte keines dieser fünf Datenlecks verhindert. Es geht hier darum, wer zuerst davon erfährt – und wie lange das dauert. ## Was bei MyDr geschah – und die drei Zahlen, die nicht zusammenpassen MyDr entwickelt Patientenakten- und Praxisverwaltungssoftware für polnische Kliniken; die Docplanner-Gruppe (ZnanyLekarz) gab die Übernahme am 9. Januar 2023 bekannt. Im Umlauf sind inzwischen drei Zahlen, und sie widersprechen einander. - **Von den Angreifern behauptet:** 18.814.422 eindeutige PESEL-Nummern und rund 2,5 TB. Zaufana Trzecia Strona konnte nach eigenen Angaben beides nicht verifizieren. - **Von der Regierung genannt:** Vizeministerpräsident Krzysztof Gawkowski sagte am 12. August, es seien knapp 19 Millionen Datensätze gestohlen worden, „was das Unternehmen selbst bestätigt“ ([Bankier](https://www.bankier.pl/wiadomosc/Cyberatak-na-MyDr-Gawkowski-Mozliwy-wyciek-danych-blisko-19-mln-Polakow-9181057.html), 2026). - **Von MyDr bestätigt:** nichts. Auf der am selben Tag um 18:35 Uhr MEZ aktualisierten Seite heißt es, das Unternehmen könne Menge und Art der offengelegten Daten nicht bestätigen; die betroffenen Daten seien „höchstwahrscheinlich historisch, aus 2024 und früheren Jahren“. Beides sind Primärquellen, im Abstand weniger Stunden veröffentlicht, und sie widersprechen sich im entscheidenden Punkt. Eine bestätigte Zahl an Datensätzen gibt es bis heute nicht. Zaufana Trzecia Strona hat einen Teil der Stichprobe der Angreifer verifiziert, darunter den Datensatz eines hochrangigen Politikers und drei Treffer bei einer Stichprobe von fünf PESEL-Nummern. Das erhärtet, dass die Angreifer echte Daten besitzen, die wie MyDr-Daten aussehen. Es erhärtet nicht die Zahl von 18,8 Millionen. Die Angaben zur Ursache stammen von den Angreifern selbst und sind unbestätigt: eine XXE-Schwachstelle in der Zertifikatsverarbeitung, die zur Codeausführung geführt haben soll, ein gestohlener GitHub-API-Schlüssel, danach AWS. Technische Details hat MyDr nicht veröffentlicht, und die Zuordnung ist bewusst verschleiert – deshalb sollte weder eine Gruppe noch ein Land genannt werden. Wann der Angriff entdeckt wurde, ist unbekannt, denn das Unternehmen erklärt, dazu während der laufenden Untersuchung nichts sagen zu können. Eine Verweildauer lässt sich daraus nicht ableiten. Entscheidend ist die Reihenfolge der Ereignisse. Am 5. August zeigten die Angreifer Journalisten den Screenshot einer Nachricht, die sie nach eigenen Angaben an den CEO des Plattformeigentümers geschickt hatten: einen Link auf ein passwortgeschütztes PDF, dessen Passwort die PESEL-Nummer des CEO selbst war. Am 8. August wandten sie sich an die Presse. Die erste Stellungnahme von MyDr kam am 10. August, dem Tag, an dem eben diese Journalisten veröffentlichten. Polnische Patientinnen und Patienten können bis heute nicht prüfen, ob sie betroffen sind. MyDr ist Auftragsverarbeiter im Sinne der DSGVO, weshalb die Mitteilung der polnischen Datenschutzbehörde UODO vom 12. August die Pflicht zur Benachrichtigung der Betroffenen den Verantwortlichen auferlegt – also den tausenden Kliniken, die die Software einsetzten. Das nationale Portal zur Prüfung von Datenlecks gibt an, dass die MyDr-Daten dort nicht eingespielt wurden. Und wer einen Fehler melden will? Am 12. August 2026 geprüft: `mydr.pl/.well-known/security.txt` leitet auf eine allgemeine Auffangseite weiter, `pro.mydr.pl` liefert 404. Die einzige RFC-9116-Datei der Gruppe liegt auf der Verbrauchermarke `znanylekarz.pl`: 44 Byte, eine `Contact:`-Zeile, kein `Expires`-Feld, obwohl der RFC es vorschreibt. Das ist eine Beobachtung zu einem Kanal, keine Aussage über die Ursache. Es gibt keinen Hinweis darauf, dass je jemand versucht hätte, etwas zu melden. ## Wie erfahren Unternehmen, dass sie kompromittiert wurden? 2025 entdeckten nur **52 %** der Organisationen schädliche Aktivitäten zuerst selbst. **34 %** wurden von außen informiert, etwa durch Strafverfolgungsbehörden oder ein CERT, und **14 %** erfuhren es vom Angreifer, meist in einer Lösegeldforderung ([Mandiant M-Trends 2026](https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026/), 2026). Die mediane Verweildauer lag bei 14 Tagen – nach 11 Tagen im Jahr davor: **9 Tage**, wenn intern entdeckt, **25 Tage**, wenn jemand anderes zuerst fündig wurde. Diese Differenz ist der Preis dafür, dass es keinen Weg gibt, auf dem es Ihnen jemand sagen könnte. ## Change Healthcare: 190 Millionen Menschen, eine unfertige Migration Im 10-K für das Geschäftsjahr 2024 nennt UnitedHealth „rund 190 Millionen“ Personen. Die höhere Zahl von 192,7 Millionen stammt aus dem Meldeportal des HHS OCR und aus der Fachpresse, nicht aus einer SEC-Einreichung; die dort gemeldete Zahl stieg über rund achtzehn Monate von einem Platzhalter mit 500 Personen an. Die Ursache steht in der beeidigten Aussage von CEO Andrew Witty vor dem Senat: Am 12. Februar 2024 nutzten Kriminelle kompromittierte Zugangsdaten, um ein Citrix-Portal zu erreichen, das „keine Multi-Faktor-Authentifizierung hatte“, breiteten sich im Netz aus und exfiltrierten zwischen dem 17. und 20. Februar Daten. Am 21. Februar folgte die Ransomware, neun Tage nach dem Eindringen. Mehrere Medien machten CitrixBleed dafür verantwortlich; keine Primärquelle stützt das. Auf die Frage, warum ein von außen erreichbarer Server ohne MFA lief, teilte UnitedHealth dem Senat mit, „der fragliche Server war ein Altsystem von Change Healthcare, und unser Team arbeitete daran, ihn auf den Standard von UHG zu heben“. Die Übernahme lag zu diesem Zeitpunkt sechzehn Monate zurück. Das Form 8-K nach Item 1.05 folgte einen Tag nach der Entdeckung; die individuellen Schreiben an Betroffene begannen Ende Juli 2024, rund fünf Monate, nachdem die Daten abgeflossen waren. Ein Kanal existierte – und hätte doch nichts genützt. Die Policy von UnitedHealth zur Meldung von Schwachstellen, seit mindestens 2019 online, bot weder Prämie noch Safe Harbor noch ein Reaktions-SLA. Sie untersagte „aktives Scannen oder Testen auf Schwachstellen“, schloss „Verstöße gegen ‚Best Practices‘“ aus und hielt fest, das Unternehmen werde „Sicherheitsprobleme weder offenlegen noch erörtern noch bestätigen“. Ein aus dem Internet erreichbares Gateway ohne MFA fällt Forscherinnen und Forschern genau dann auf, wenn sie aktiv scannen dürfen – und ergibt genau die Art von Meldung, die in der Sichtung als Verstoß gegen Best Practices abgelegt werden kann. ## Salesloft Drift: das Datenleck, das ein Vulnerability Disclosure Program nicht hätte finden können Dieser Fall steht hier, weil er gegen die These spricht. Zwischen März und Juni 2025 hatte ein als UNC6395 geführter Akteur das GitHub-Konto von Salesloft in der Hand, wechselte von dort in die AWS-Umgebung von Drift, in der die OAuth-Token der Kunden lagen, und griff mit diesen legitimen Token auf die Salesforce-Instanzen der Kunden zu. Die Google Threat Intelligence Group hält fest, der Vorfall „geht nicht auf eine Schwachstelle in der Salesforce-Kernplattform zurück“. Wie das GitHub-Konto übernommen wurde, hat Salesloft nie offengelegt. MFA und Login-Überwachung waren strukturell ausgehebelt: Die App war autorisiert, die Token waren echt. Der Akteur hatte es auf Zugangsdaten abgesehen, die in Support-Tickets eingefügt worden waren. Cloudflare fand 104 aktive Cloudflare-API-Token im eigenen abgeflossenen Ticket-Text und rotierte sie allesamt; der gesamte Bestand war in 3 Minuten 22 Sekunden abgeflossen. Zwischen dem ersten GitHub-Zugriff und der Offenlegung am 20. August 2025 lagen rund fünf Monate – zwischen dem Ende der beobachteten Exfiltration und dem Widerruf der Token nur zwei Tage. **Ein Vulnerability Disclosure Program hätte das nicht gefunden.** Eine GitHub-Kontoübernahme und ein zentraler Token-Tresor in der eigenen AWS-Umgebung eines Anbieters sind von außen nicht beobachtbar, und die angrenzenden Schwächen sind Architekturentscheidungen, die die meisten VDP-Geltungsbereiche ausschließen. Zum Vergleich ein Fund, wie ihn ein VDP abdeckt – im selben Ökosystem, im selben Quartal. Noma Security fand ForcedLeak (CVSS 9.4) in Salesforce Agentforce: eine abgelaufene Domain, die noch in einer CSP-Allowlist stand und für rund 5 $ zu kaufen war. Gemeldet am 28. Juli 2025, bestätigt am 31. Juli, behoben am 8. September, offengelegt am 25. September. Von außen gefunden, gemeldet, behoben, veröffentlicht. ## Free Mobile: 42 Mio. € Bußgeld – und vier Millionen Betroffene waren längst keine Kunden mehr Die Entscheidungen der CNIL vom Januar 2026 beziffern das bestätigte Ausmaß auf **24.633.469 Verträge**: 19.460.891 im Mobilfunk und 5.172.577 im Festnetz, samt Namen, Adressen, Geburtsdaten und IBANs jener Kunden, die beide Dienste nutzten ([CNIL](https://www.cnil.fr/en/sanction-free-2026), 2026). Der Angreifer erreichte die Kundenverwaltung über das VPN von Free Mobile, dessen Authentifizierung die CNIL als „nicht hinreichend robust“ einstufte; bemängelt wurden die fehlende Geräteauthentifizierung und die fehlende MFA für Nutzer. Der zweite Befund der CNIL: Das Unternehmen hatte keine ausreichenden Mittel im Einsatz, um verdächtige Aktivitäten auf diesem VPN, im internen Netz oder in der Kundenverwaltung zu erkennen. Logs vorzuhalten ist keine Schutzmaßnahme. Der dritte Befund ist der, den Gründerinnen und Gründer unterschätzen. Free Mobile verstieß zusätzlich gegen Artikel 5 Abs. 1 lit. e, weil über fünfzehn Millionen gekündigte Verträge länger als fünf Jahre gespeichert blieben, drei Millionen davon länger als zehn. Die Rechnung verrät es: 19,46 Millionen offengelegten Mobilfunkverträgen standen zum 31. Dezember 2024 rund 15,51 Millionen aktive Mobilfunkkunden gegenüber. Es waren also rund vier Millionen Verträge mehr betroffen, als das Unternehmen überhaupt aktive Kunden hatte. Die Löschfrist war eine Sicherheitsmaßnahme, und ihr Fehlen vergrößerte den Schadensradius um Millionen Menschen. Der Zugriff lief vom 28. September bis zum 22. Oktober 2024, und die CNIL hält fest, dass das Unternehmen am 21. Oktober von einem Angreifer alarmiert wurde, der in seine Systeme eingedrungen war. Free meldete den Vorfall innerhalb der 72-Stunden-Frist an die CNIL und unterlag dennoch bei Artikel 34, weil die CNIL befand, die Benachrichtigungs-E-Mail habe Millionen Betroffenen nicht die nötige Klarheit verschafft. Bußgelder: 27 Mio. € gegen FREE MOBILE, 15 Mio. € gegen FREE. `free.fr` liefert heute eine PGP-signierte `security.txt` aus, geprüft am 12. August 2026: kanonische URL, zwei Kontakte, ein `Expires`-Datum, ein OpenPGP-Fingerprint. Eine `Policy:`-Zeile fehlt, also kein Geltungsbereich und kein Safe Harbor. Ein Postfach ist noch kein Programm – und dieser Eindringling wandte sich stattdessen an ein kriminelles Forum. ## Tea: Entdeckt hat es 4chan, behoben wurde es nach der Veröffentlichung Tea Dating Advice bestätigte, dass auf 72.000 Bilder zugegriffen wurde, darunter 13.000 Verifizierungs-Selfies und Bilder amtlicher Ausweise ([NBC News](https://www.nbcnews.com/tech/social-media/tea-app-hacked-13000-photos-leaked-4chan-call-action-rcna221139), 2025); der Rest stammt aus Beiträgen, Kommentaren und Nachrichten und betrifft nur Nutzer, die sich vor Februar 2024 registriert hatten ([TechCrunch](https://techcrunch.com/2025/07/26/dating-safety-app-tea-breached-exposing-72000-user-images), 2025). Die Meldung an den Attorney General von Kalifornien fällt enger aus: unbefugter Zugriff am oder um den 24. Juli 2025 auf einen Speicherort mit Verifizierungsunterlagen, mit Hinweisen auf einen Zugriff auf „die meisten oder womöglich alle“ davon, wodurch Namen, Geburtsdaten, Führerschein- und Passnummern offengelegt wurden. Die Ursache passt in den Satz, den 404 Media aus dem 4chan-Beitrag zitierte, mit dem alles begann: „Keine Authentifizierung, gar nichts. Es ist ein öffentlicher Bucket.“ Keine Zugangsdaten, keine Exploit-Kette, nur eine URL. Dann eine zweite Schwachstelle: eine Firestore-Datenbank mit Direktnachrichten, lesbar für alle angemeldeten Tea-Nutzerinnen und -Nutzer. 404 Media berichtete von mehr als 1,1 Millionen Nachrichten, an einer Stichprobe verifiziert; Tea bestätigte nie eine Zahl und sprach nur davon, dass auf einige Nachrichten zugegriffen worden sei. Zwei Schwachstellen, zwei Kanäle – und keiner davon das Unternehmen. Die erste landete an einem Donnerstagabend auf 4chan; die Benachrichtigung der Verbraucher folgte am 28. August 2025, im kalifornischen Register eine Lücke von 35 Tagen. Die zweite ging an einen Journalisten: Der unabhängige Forscher Kasra Rahjerdi fand die Nachrichtendatenbank, entschied sich gegen eine Veröffentlichung und leitete sie über 404 Media an Tea weiter, weil das der Weg war, der funktionierte. Tea schaltete die Direktnachrichten zwei Tage später ab, nach der Veröffentlichung. Öffentlich ist kein aufsichtsrechtliches Verfahren bekannt geworden – das ist eine ausgebliebene Bekanntmachung, kein Beleg für eine ausgebliebene Untersuchung. ## Die fünf im Vergleich | Vorfall | Bestätigtes Ausmaß | Wer es ihnen zuerst sagte | Meldekanal (geprüft am 12. Aug. 2026) | |---|---|---|---| | **MyDr** (PL, Aug. 2026) | keines; Angreifer behaupten 18.814.422 PESEL-Nummern | die Angreifer, dann Journalisten | keine `security.txt`; eine 44 Byte große, nicht konforme Datei auf einer Schwestermarke | | **Change Healthcare** (US, Feb. 2024) | ~190 Mio. (10-K); 192,7 Mio. im HHS-Portal | niemand von außen; die Ransomware war der Alarm | Konzern-Policy verbot aktives Scannen; Seite liefert 404 | | **Salesloft Drift** (SaaS, Aug. 2025) | nicht veröffentlicht | unbekannt; keine öffentliche Quelle nennt einen Erstentdecker | 404, Meta-Refresh, Soft-404; kein öffentliches Programm | | **Free / Free Mobile** (FR, Okt. 2024) | 24.633.469 Verträge (CNIL) | der Angreifer, an Tag 23 eines 24-tägigen Eindringens | PGP-signierte `security.txt`, keine `Policy:`-Zeile | | **Tea** (US, Juli 2025) | 72.000 Bilder, davon 13.000 Ausweise und Selfies | 4chan, dann ein Journalist | 404 auf beiden Domains | ## Was die fünf gemeinsam haben **Ein Anbieter, tausendfacher Schadensradius (3 von 5).** MyDr ist Auftragsverarbeiter für tausende Kliniken, Change Healthcare eine Verrechnungsstelle für einen großen Teil der US-Krankenversicherungsabrechnungen, Drift eine App, die in den Salesforce-Mandanten hunderter anderer Unternehmen steckt. In allen drei Fällen war die kompromittierte Partei nicht die Partei, deren Kunden zu Schaden kamen. Für tausende kleine polnische Kliniken läuft nun die 72-Stunden-Frist nach Artikel 33 – ohne dass sie selbst forensisch etwas sehen könnten. **Daten, die weit über ihren Nutzen hinaus aufbewahrt wurden (3 von 5).** Free ist der von der Aufsicht belegte Fall. Tea ist der Fall Versprechen gegen Praxis: Die Datenschutzerklärung sagte, Verifizierungs-Selfies würden unmittelbar nach Gebrauch gelöscht – 13.000 davon lagen in einem öffentlichen Bucket. MyDr ist der Fall mit dem eingebauten Vorbehalt. „Höchstwahrscheinlich historisch, aus 2024 und früheren Jahren“ ist als Beruhigung gedacht; als Aussage über die Aufbewahrung gelesen heißt es, dass historische Datensätze aus dem Produktivsystem noch erreichbar waren. **Erfahren haben es die Opfer – nur nicht von jemandem, der es melden wollte (4 von 5).** MyDr: Die Angreifer schrieben dem CEO. Free: Der Eindringling beendete dreiundzwanzig Tage Stille. Tea: 4chan, dann ein Journalist. Change Healthcare: die Verschlüsselung selbst. Salesloft: unbekannt, und diese Lücke sollte eine Lücke bleiben. Die Zahlen von Mandiant zeigen, dass das der Normalfall ist und keine Pechsträhne. **Die Kennungen, die sich nicht rotieren lassen (3 von 5).** Ein Passwort, einen API-Schlüssel oder ein OAuth-Token können Sie rotieren; Cloudflare rotierte 104 davon binnen einer Woche. Eine PESEL-Nummer, eine IBAN, eine Passnummer oder ein Geburtsdatum können Sie nicht rotieren. Der Rat des polnischen Staates läuft derzeit darauf hinaus, die eigene PESEL-Nummer in mObywatel zu sperren und darauf zu warten, dass die eigene Klinik sich meldet. Jedes zusätzliche Jahr der Aufbewahrung ist ein weiteres Jahr, in dem unveränderliche Kennungen in einem System liegen, das irgendwann jemand erreicht. **Das geerbte System (2 von 5).** UnitedHealth schloss die Übernahme von Change Healthcare im Oktober 2022 ab, und im Februar 2024 stand das ungehärtete Gateway noch auf der Migrationsliste. MyDr wurde im Januar 2023 übernommen, und die einzige RFC-9116-Datei der Gruppe liegt auf einer anderen Marke mit einer anderen Kontaktadresse. Ein Unternehmen zu integrieren und seine Sicherheitskanäle zusammenzuführen, sind zwei getrennte Projekte, und das zweite zieht meist den Kürzeren. **Es gab keine Adresse für eine Meldung (5 von 5).** Das ist das einzige Merkmal, das auf alle fünf zutrifft, und zwei davon zeigen, warum eine veröffentlichte Seite noch nicht das Ziel ist. Change Healthcare belegt, dass ein Kanal nicht genügt: Eine Policy, die Scannen verbietet und Best-Practice-Funde ausschließt, filtert genau die Art von Meldung heraus, auf die es ankam. Salesloft belegt, dass ein Kanal nicht immer einschlägig ist. Was ein Kanal sehr wohl bringt, steht in Verizons eigenen Worten über offen liegende Datenspeicher: Sie „werden am häufigsten von Sicherheitsforschern entdeckt, die dann versuchen, eine Benachrichtigung abzusetzen, sofern sie feststellen können, wessen Daten es sind. Was wir nicht wissen, ist, wie oft andere, weniger gemeinwohlorientierte Leute auf dieselben Daten gestoßen sind, eine Kopie gezogen haben und still verschwunden sind“ ([Verizon 2026 DBIR](https://www.verizon.com/business/resources/T1ae/reports/2026-dbir-data-breach-investigations-report.pdf), 2026). Der Tea-Bucket ist dieser Absatz mit einem Namen darauf. Ohne Kanal bergen die verbleibenden Optionen ein echtes Risiko für die Entdeckerinnen und Entdecker selbst. Studierende und ein Dozent auf Malta, die im Oktober 2022 ein Unternehmen per E-Mail auf Schwachstellen hinwiesen, erlebten drei Wochen später eine Hausdurchsuchung durch bewaffnete Polizei und wurden erst im Juli 2025 begnadigt. Wenn Ihre einzige Annahmestelle aus einem Support-Postfach und einer Rechtsabteilung besteht, dann haben Sie sehr wohl eine Policy veröffentlicht – nur die falsche. Mehr dazu in [Safe Harbor und rechtliche Drohungen gegen Sicherheitsforscher](/blog/safe-harbor-legal-threats-security-researchers-vdp). ## Wo ein Vulnerability Disclosure Program bereits Pflicht ist – und wo nicht Hier lohnt Präzision, denn die meiste Berichterstattung ist unpräzise. **EU Cyber Resilience Act (Verordnung 2024/2847).** Anhang I Teil II Nr. 5 verpflichtet Hersteller von Produkten mit digitalen Elementen, „eine Strategie für die koordinierte Offenlegung von Schwachstellen festzulegen und durchzusetzen“. Achten Sie auf das Verb: Eine veröffentlichte Seite allein genügt dafür nicht. Die Fristen aus Artikel 14 (24 Stunden Frühwarnung, 72 Stunden Meldung, 14 Tage Abschlussbericht bei aktiv ausgenutzten Schwachstellen) gelten ab dem 11. September 2026, die Verordnung insgesamt ab dem 11. Dezember 2027. Sie bindet Hersteller, die Produkte auf dem EU-Markt in Verkehr bringen; ein reines SaaS-Webunternehmen fällt daher in der Regel nicht darunter. Die Details finden Sie in unserer [Aufschlüsselung der Offenlegungspflichten des CRA](/blog/eu-cyber-resilience-act-mandatory-vulnerability-disclosure). **NIS2 (Richtlinie 2022/2555).** Artikel 12 bindet die Mitgliedstaaten und die ENISA, nicht einzelne Unternehmen. Die polnische Umsetzung, die KSC-Novelle, trat am 3. April 2026 in Kraft, rund siebzehn Monate nach der EU-Frist, mit Registrierungspflicht bis zum 3. Oktober 2026. Der MyDr-Vorfall fällt in dieses Zeitfenster, bevor Compliance- und Sanktionsfristen greifen. **UK PSTI (SI 2023/1007).** Seit dem 29. April 2024 durchsetzbar für vernetzbare Produkte. Anhang 1 verlangt einen veröffentlichten Kontakt plus eine Angabe dazu, wann Meldende eine Bestätigung und Statusaktualisierungen erhalten – abrufbar ohne vorherige Anfrage, kostenlos und ohne Abfrage personenbezogener Daten der meldenden Person. Diese letzte Klausel schließt Formulare hinter Zugangshürden und Kontaktseiten hinter einem Login aus. **CISA BOD 20-01.** Für zivile US-Bundesbehörden seit 2020 verpflichtend: eine Policy unter dem festen Pfad `/vulnerability-disclosure-policy`, mit ausgewiesenem Geltungsbereich, erlaubten Tests und einer klaren Aussage, dass Meldungen anonym erfolgen dürfen. Die VDP-Plattform der CISA meldete bis einschließlich 2023 kumuliert über 12.000 Einreichungen aus 51 Behördenprogrammen, aus denen über 2.400 gültige Offenlegungen wurden. **Keine Pflicht.** NIS2 verpflichtet Unternehmen nicht dazu, ein VDP zu betreiben, PCI DSS 4.0 ebenso wenig; die Leitlinien des PCI SSC sagen, Vulnerability Disclosure Programs „können helfen“, die Anforderungen 6.3.3 und 12.10.1 zu erfüllen. Im US-Bundesbeschaffungsrecht gibt es keine FAR-Pflicht. Der Gesetzentwurf dafür ist H.R. 872, der am 3. März 2025 das Repräsentantenhaus passierte und Stand 12. August 2026 nicht in Kraft ist. Die ökonomische Rechnung wartet nicht auf das Gesetz. IBM beziffert die weltweiten Durchschnittskosten einer Datenschutzverletzung im Jahr 2026 auf einen Rekordwert von 4,99 Mio. $, ein Plus von 12 % ([IBM Cost of a Data Breach 2026](https://www.ibm.com/reports/data-breach)). HackerOne zahlte im Jahr bis zum 30. Juni 2025 81 Mio. $ an Prämien aus, verteilt auf 1.950 Programme, doch die Top 100 nahmen davon 51 Mio. $ ein – für ein typisches Programm bleiben damit rund 16.000 $ pro Jahr. Ein Programm ganz ohne Prämien kostet noch weniger. Und kaum jemand veröffentlicht überhaupt einen Kontakt: Eine begutachtete Untersuchung der Tranco-Liste fand `security.txt` im Januar 2023 auf 34,0 % der Top-100-Domains, aber nur auf 1,0 % der Top-Million (Hilbig et al., ACM DTRAP); bis Januar 2025 waren es gerade einmal 1,25 % der Top-Million, von denen 44 % RFC-konform waren (URIports, 2025). ## Was Sie diese Woche veröffentlichen sollten Nichts davon braucht ein Prämienbudget oder einen Plattformvertrag. Das Minimum, das Entdeckerinnen und Entdeckern in allen fünf Fällen eine Adresse gegeben hätte: 1. **Eine `security.txt` nach RFC 9116** mit funktionierendem `Contact:`, einem `Expires:`-Datum und einer `Policy:`-Zeile. `Expires` ist Pflicht, und an solchen Details scheitern die meisten veröffentlichten Dateien bei der Konformität. 2. **Eine Policy-Seite**, die Geltungsbereich, erlaubte Tests und Safe Harbor in klarer Sprache benennt. Der Mutterkonzern von Change Healthcare untersagte genau das Scannen, das ein Entdecker gebraucht hätte; Free hat ein Postfach ganz ohne Policy. 3. **Eine zugesagte Bestätigungsfrist.** Kein Gesetz, sondern gute Praxis: Sagen Sie, wie schnell Sie den Eingang bestätigen – und halten Sie sich daran. 4. **Eine benannte verantwortliche Person und eine Warteschlange.** Meldungen, die in einem Sammelpostfach landen, sichtet, wer gerade am wenigsten zu tun hat – also niemand. 5. **Eine exportierbare Zeitachse.** Wenn eine Aufsichtsbehörde oder ein Journalist fragt, was Sie wann wussten, ist „wir sind verantwortungsvoll damit umgegangen“ kein Nachweis. Eine Zeitachse je Meldung schon. Die Schritt-für-Schritt-Fassung: [wie Sie ein Vulnerability Disclosure Program aufsetzen](/blog/how-to-set-up-vulnerability-disclosure-program). ## Den Meldeeingang betreiben, ohne ihn zu bauen Einen Kontakt zu veröffentlichen, kostet einen Nachmittag. Unbemerkt scheitert der zweite Teil: die eingehenden Meldungen tatsächlich zu bearbeiten. Denn eine Meldewarteschlange verhält sich wie jede andere Warteschlange: Sie staut sich, die Frist läuft, und niemand merkt es, bis es jemand von außen tut. Das CSIRT-Modul von Kit ist die operative Schicht dafür und nichts darüber hinaus. Es erzeugt die `security.txt` und betreibt ein öffentliches Meldeportal, auf dem Ihr Geltungsbereich gleich mitveröffentlicht ist, sodass Ziele innerhalb und außerhalb des Geltungsbereichs ausdrücklich benannt und nicht bloß angedeutet sind. Eingehende Meldungen werden gegen diesen Geltungsbereich geprüft, dedupliziert und mit SLA-Fristen versehen: einer Bestätigungsfrist und Behebungszielen je Schweregrad, dazu einer Verfolgung gefährdeter Fristen, damit eine verpasste Zusage auffällt, bevor Forscherinnen und Forscher eskalieren. Forscher erhalten dauerhafte Profile und Karma, damit jemand, der wiederholt gehaltvolle Meldungen liefert, nicht im Rauschen untergeht. Prämien sind optional: Schweregradmatrix, Abstimmung über Vorschläge, Hauptbuch und Übergabe zur Auszahlung sind da, wenn Sie zahlen, und ruhen, wenn nicht. Jede Meldung trägt eine exportierbare Zeitachse. Die Grenzen zählen so viel wie die Funktionen. Kit hätte keines dieser fünf Datenlecks verhindert. Es ist kein EDR, keine Segmentierung, keine MFA, und die Übernahme des GitHub-Kontos von Salesloft hätte es nicht sichtbar gemacht. Es reicht nichts bei der Plattform der ENISA ein, übernimmt Ihre Meldungen nach Artikel 33 und 34 nicht und ist keine Rechtsberatung. Der ehrliche Anspruch ist enger: In vier dieser fünf Fälle war das Unternehmen nicht das Erste, das Bescheid wusste – und ein veröffentlichter Kanal ändert, wer es zuerst erfährt.

Veröffentlichen Sie diese Woche einen Kontakt und eine Policy. Das CSIRT-Modul von Kit gibt Ihnen ein öffentliches Meldeportal, eine generierte security.txt, Prüfung des Geltungsbereichs, SLA-Verfolgung und eine exportierbare Zeitachse je Meldung.

Kostenlos testen

Fünf Unternehmen, drei Kontinente, fünf verschiedene Ursachen. Das Einzige, was alle fünf teilten: Wer von außen etwas mitteilen wollte, hatte dafür keinen vorgesehenen Weg. Das ist keine Frage des Reifegrads und kein Budgetproblem. Es ist eine fehlende Schnittstelle – und die billigste auf Ihrer Roadmap.