ICO rügt ACRO: Kompromittiertes CMS gefährdet 10.920 Personen

Veröffentlicht am 16.08.2026

Sieben Monate lang, von August 2022 bis März 2023, hatte ein Angreifer unbemerkten Zugriff auf die Website und das Content-Management-System des britischen ACRO Criminal Records Office – jenes Amtes, das unter anderem polizeiliche Führungszeugnisse und internationale Kinderschutznachweise ausstellt. Am 12. August 2026 hat die britische Datenschutzaufsicht ICO (Information Commissioner's Office) das Amt dafür formell gerügt. Die zentrale Erkenntnis für deutsche Website-Betreiber ist unbequem: Der Vorfall gelang nicht wegen eines raffinierten Zero-Day-Angriffs, sondern weil niemand klar zuständig war, kritische Updates einzuspielen – und weil vorhandene Alarme schlicht ignoriert wurden.

Was ist passiert?

Betroffen war das ACRO-Kundenportal, eine Webanwendung auf Basis des CMS Kentico (ein System zur Verwaltung von Website-Inhalten). Laut ICO-Rüge, die auf den 7. August 2026 datiert ist, hielt ein Angreifer im größten der Vorfälle – von der ICO „Group A“ genannt – zwischen dem 5. August 2022 und dem 14. März 2023 unbefugten Zugriff auf diese Website- und CMS-Umgebung.

Am 15. und 16. Februar 2023 wurden Daten für eine mögliche Exfiltration – also den unbefugten Abfluss aus dem Netzwerk – zwischengespeichert. Diese Daten stammten aus Vorgängen zu Führungszeugnissen, Auskunftsersuchen (Subject Access Requests) und internationalen Kinderschutznachweisen. Ob die Daten tatsächlich das Netzwerk verließen, konnte ACRO im Nachhinein nicht mehr feststellen – weil die Protokolldaten (Logs) nicht ausreichend aufbewahrt worden waren. Genau hier liegt eine der schmerzhaftesten Lehren: Ohne verwertbare Logs bleibt im Ernstfall unklar, was gestohlen wurde.

Potenziell betroffen waren bis zu 10.920 Personen. Die Daten umfassten Identitäts-, Finanz-, biometrische und Strafdaten sowie besondere Kategorien personenbezogener Daten – also hochsensible Informationen. Vorsorglich benachrichtigte ACRO im April 2023 sogar insgesamt 84.048 Personen.

Die ICO stellte Verstöße gegen mehrere Bestimmungen der UK GDPR fest, insbesondere gegen Art. 32 – die Pflicht zu angemessenen technischen und organisatorischen Sicherheitsmaßnahmen.

Der technische Hintergrund – verständlich erklärt

Wichtig zur Einordnung: Dies ist kein bestätigter neuer Kentico-Exploit. Der forensische Untersuchungsbericht konnte die konkret ausgenutzte Schwachstelle nicht benennen. Die ICO hält es lediglich für „highly likely“ – hochwahrscheinlich –, dass der Erstzugriff über eine ungepatchte Kentico-Schwachstelle erfolgte.

ACRO betrieb die Anwendung von September 2019 bis März 2023 auf Kentico CMS 12.0.0. In diesem gesamten Zeitraum wurde kein einziger der vom Hersteller veröffentlichten kumulativen Sicherheits-Hotfixes eingespielt. Das System lief also über Jahre auf einem veralteten Patchstand.

Als öffentlich dokumentierte, zur eingesetzten Versionslinie passende Referenz nennt das Material CVE-2019-10068. Diese Schwachstelle betrifft Kentico 12.0.x vor Version 12.0.15: Eine fehlerhafte Validierung von Sicherheitsheadern im sogenannten Staging-Service kann bei passender Konfiguration eine nicht authentifizierte Remote-Code-Ausführung (RCE) durch Deserialisierung ermöglichen – vereinfacht: Ein Angreifer kann ohne Anmeldung eigenen Schadcode auf dem Server ausführen. Diese CVE ist im CISA-Katalog bekannter, aktiv ausgenutzter Schwachstellen geführt und wurde in Version 12.0.15 behoben. Achtung: Die ICO nennt diese CVE nicht und konnte nicht bestimmen, welche Kentico-Lücke bei ACRO tatsächlich missbraucht wurde. Die bloße Versionsübereinstimmung beweist keinen Angriff.

Nicht die Technik allein war das Problem

Der Vorfall dauerte auch deshalb so lange, weil mehrere organisatorische Kontrollen fehlten:

• Unklare Zuständigkeit: Ein Dienstleister patchte Betriebssysteme und Server, der Webentwicklungsdienstleister sollte Kentico-Patches einspielen – aber niemand war nachweislich dafür verantwortlich, überhaupt zu erkennen, welche CMS-Patches nötig waren.
• Keine dokumentierte Patchrichtlinie: Es wurde keine CMS-Patchrichtlinie vorgelegt.
• Ignorierte Alarme: Die Sicherheitssoftware Trend Micro erkannte und quarantänisierte mehrfach Angreiferwerkzeuge. Am 23. Februar 2023 blockierte sie vier Versuche, das bekannte Passwort-Abgreif-Tool Mimikatz zu installieren. Diese Warnungen wurden laut ICO nicht untersucht oder bearbeitet.

„ACRO did not clearly define who was responsible for monitoring for required security patches. … ACRO itself did not monitor for required security patches, meaning that there was an absence of oversight for this important security control.“ – ICO-Rüge gegen ACRO

Ein Lichtblick: Die Netzwerksegmentierung – also die Aufteilung des Netzwerks in getrennte Zonen – verhinderte nachweislich, dass der Angreifer sich in Kernpolizeisysteme weiterbewegen konnte. Sie begrenzte den Schaden, beseitigte das Risiko aber nicht.

Wer ist betroffen?

Direkt betroffen ist ACRO im Vereinigten Königreich. Für deutsche Unternehmen ist die Lehre aber unmittelbar relevant, wenn Sie ein öffentlich erreichbares CMS mit personenbezogenen Daten betreiben. Besonders erhöht ist das Risiko, wenn:

• ein Kundenportal, Formulare oder Upload-Funktionen personenbezogene Daten verarbeiten,
• ein nicht mehr unterstütztes CMS im Einsatz ist (Kentico 12.x ist inzwischen End-of-Support),
• weder eine belastbare Patch-Verantwortung noch eine funktionierende Log- und Alarmbearbeitung nachweisbar sind,
• Hosting vollständig ausgelagert ist, aber vertraglich nicht klar geregelt ist, wer Sicherheitsupdates identifiziert und einspielt.

Das Risiko ist nicht allein deshalb hoch, weil eine Website öffentlich sichtbar ist. Entscheidend sind der konkrete Datenbestand, die Angriffsfläche, der Patchstand, die Zugriffsrechte, die Segmentierung und die Reaktionsfähigkeit.

So prüfen Sie, ob Sie betroffen sind

1. Inventar erstellen: Erfassen Sie alle öffentlich erreichbaren Websites, Subdomains, Kundenportale, Formulare, Upload-Funktionen sowie deren CMS, Plug-ins, Webserver und Ihre Hosting- und Entwicklungspartner. Ordnen Sie jeder Komponente einen fachlich verantwortlichen Eigentümer zu – genau diese Zuständigkeit war bei ACRO der Kernmangel.
2. CMS-Version bestätigen lassen: Prüfen Sie die Version ausschließlich über berechtigte interne Zugänge oder die Deployment-/Supportunterlagen – nicht durch unautorisierte Tests. Bei Kentico 12 beschreibt die Herstellerdokumentation die Anwendung „System“ und den Reiter „General“ als Stelle für System- und Umgebungsinformationen. Lassen Sie Version und Hotfix-Stand schriftlich von Administration, Entwicklung oder Hosting bestätigen.
3. Lebenszyklus abgleichen: Ordnen Sie den bestätigten Stand dem Hersteller-Lebenszyklus und den Security Advisories zu. Jede Kentico-12.x-Installation ist 2026 nicht mehr unterstützt und sollte als Migrationsrisiko behandelt werden. Für CVE-2019-10068 gilt: 12.0.x vor 12.0.15 ist betroffen.
4. Patch-Historie prüfen: Existieren für CMS, Betriebssystem, Webserver und Drittkomponenten eine lückenlose Patch-Historie, Risikoentscheidung, Testnachweis, Freigabe und Rollback-Möglichkeit? Fehlen diese Nachweise, ist das ein Governance- und Sicherheitsrisiko – auch wenn ein Dienstleister die Updates installiert.
5. Logs auswerten: Durchsuchen Sie Webserver-, WAF-, CMS-, Authentifizierungs-, Antivirus/EDR- und SIEM-Protokolle auf ungewöhnliche Admin-Anmeldungen, neue oder veränderte Dateien, ungewöhnliche Datentransfers und unbehandelte Alerts. Kentico nennt für kompromittierungsverdächtige Instanzen unter anderem unbekannte Dateien, Antivirus-Funde und verdächtige IIS-Logaktivitäten wie SyncServer.asmx als Prüfansätze. Sichern Sie Beweismittel vor jeder Bereinigung.
6. Datenkarte erstellen: Ermitteln Sie, welche personenbezogenen Daten über die Website verarbeitet werden (Formular-, Upload-, Zahlungs-, Supportdaten) und wo sie liegen. Diese Daten- und Risikokarte ist die Grundlage jeder DSGVO-Bewertung.

Das müssen Sie jetzt tun

1. Bei konkreten Angriffszeichen: Incident-Response aktivieren. Legen Sie Zuständigkeiten fest, sichern Sie Beweise und Logs und begrenzen Sie die externe Angriffsfläche kontrolliert. Keine übereilte Bereinigung, die forensische Spuren zerstört – ACRO konnte wegen fehlender Logs später nicht klären, ob Daten abgeflossen sind.
2. Nicht unterstützte CMS-Versionen migrieren. Für Kentico 12.x empfiehlt der Hersteller ausdrücklich den Umstieg. Ein nachgezogener historischer Hotfix behebt das End-of-Support-Risiko nicht.

   „The only solution to secure your website is to upgrade to the latest supported version and apply the latest hotfix.“ – Kentico

3. Patch-Management dokumentieren. Etablieren Sie einen Prozess mit Inventar, Herstellerwarnungen, Risikobewertung, Test in Staging, Freigabe, Rollout, Verifikation und Fristen. Legen Sie eine RACI-Matrix fest, die klar trennt, wer Updates identifiziert, bewertet, einspielt, prüft und eskaliert – auch über Dienstleistergrenzen hinweg.
4. Alarme aktiv behandeln. Zentralisieren Sie Web-, CMS-, Server-, Authentifizierungs- und Endpoint-Logs, definieren Sie Triage- und Eskalationsfristen und testen Sie den Bereitschaftsweg regelmäßig. Die ICO stellt fest, dass ein rechtzeitiges Untersuchen der Trend-Micro-Warnungen wahrscheinlich weitere bösartige Aktivität verhindert hätte.
5. Portal härten und Schaden begrenzen. Sichern Sie administrative Zugänge mit MFA (Mehr-Faktor-Authentifizierung) und minimalen Rechten, trennen Sie Admin- und Produktivkonten, halten Sie getestete Backups vor und segmentieren Sie die Website-Zone von Kernsystemen. Bei ACRO verringerte gerade die Segmentierung den potenziellen Schaden.
6. Datenschutz-Incident-Response vorbereiten. Benennen Sie Verantwortliche, Auftragsverarbeiter und Ansprechpartner der Aufsichtsbehörde und halten Sie eine 72-Stunden-Entscheidungsmatrix samt Meldeentwürfen bereit.

Einordnung und DSGVO-Relevanz

Der ACRO-Bescheid beruht auf der UK GDPR und ist keine unmittelbare deutsche Rechtsentscheidung. Doch Art. 32 DSGVO verlangt in Deutschland genauso risikogerechte technische und organisatorische Maßnahmen – darunter die fortdauernde Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme (Art. 32 Abs. 1 Buchst. b) und ein Verfahren zur regelmäßigen Überprüfung ihrer Wirksamkeit (Buchst. d). Genau die im ACRO-Fall beanstandeten Punkte – fehlende Zuständigkeiten, ungepatchte Komponenten, fehlende Risikodokumentation, unbehandelte Alarme – sind damit auch für deutsche Betreiber unmittelbare Warnsignale.

Führt ein Webvorfall zu einer Verletzung des Schutzes personenbezogener Daten, ist bei voraussichtlichem Risiko die zuständige Aufsichtsbehörde nach Art. 33 DSGVO unverzüglich und möglichst binnen 72 Stunden nach Kenntnis zu informieren. Bei hohem Risiko sind nach Art. 34 DSGVO grundsätzlich auch die Betroffenen zu benachrichtigen. Jede Verletzung ist zu dokumentieren. Für Verstöße gegen Art. 32 sieht Art. 83 Abs. 4 DSGVO einen Höchstrahmen von bis zu 10 Mio. Euro oder bis zu 2 % des weltweiten Jahresumsatzes vor – je nachdem, welcher Betrag höher ist. Das ist kein automatischer Bußgeldbetrag; Sanktionen hängen stets vom Einzelfall ab.

Dass Aufsichtsbehörden bei Website-Vorfällen empfindlich reagieren, zeigt der Vergleichsfall Ticketmaster UK: Am 13. November 2020 verhängte die ICO ein Bußgeld von 1,25 Mio. GBP nach einem Webangriff über eine Drittanbieter-Chatbot-Komponente – potenziell betroffen waren 9,4 Mio. im EWR benachrichtigte Personen. Die Parallele liegt in Drittanbieter- und Website-Risiken sowie in der unzureichenden Reaktion auf Warnhinweise.

Wie ernst die Lage in Deutschland ist, unterstreicht der BSI-Lagebericht 2025: Die Ausnutzung von Schwachstellen in Web-Angriffsflächen stieg gegenüber dem Vorjahr – bereinigt um Sondereffekte – um 38 %, und 80 % der angezeigten Ransomware-Angriffe trafen kleine und mittlere Unternehmen. Das BSI bringt die Lehre auf den Punkt:

„This is why patches are one of the most effective ways to prevent attacks from the internet.“ – Bundesamt für Sicherheit in der Informationstechnik (BSI)

Fazit

Der ACRO-Fall ist keine Geschichte über einen genialen Hacker, sondern über fehlende Grundlagen: Niemand war klar verantwortlich für Patches, das CMS lief jahrelang ungepatcht, Logs fehlten und Alarme wurden ignoriert. Jeder dieser Punkte ist vermeidbar – und jeder einzelne davon kann bei deutschen KMU genauso vorliegen.

„Organisations must ensure there is clear accountability for identifying, assessing and applying security updates. They must also have effective monitoring in place so that warning signs of cyber-attacks are identified, investigated and acted upon promptly.“ – Jonathan Balmforth, Group Manager – Civil and Cyber Investigations, ICO

Prüfen Sie daher jetzt: Wer ist bei Ihnen nachweislich für CMS-Patches zuständig? Läuft Ihr System auf einer noch unterstützten Version? Und würden Sie einen Alarm Ihrer Sicherheitssoftware überhaupt bemerken und bearbeiten? Wer diese drei Fragen klar beantworten kann, hat die wichtigsten Fehler aus dem ACRO-Fall bereits vermieden.