Cyberangriff auf die Stadt Wien: 26.000 Dokumente abgeflossen, entdeckt über ein Verkaufsangebot

Eine Einordnung unter Vorbehalt. Die Stadt Wien hat den Vorfall am 30.09.2026 selbst öffentlich gemacht; die Untersuchungen laufen, und die Fehlerklasse der Schwachstelle ist nicht bestätigt. Diese Analyse trennt, was die Stadt belegt hat, was Medien berichten und was wir annehmen. Sie gilt bis zum 31.01.2027.

Der Autor ist Gründer und Geschäftsführer von KaitoSec.

Das Wichtigste in Kürze

• Zwischen dem 3. und dem 11. September 2026 hatte ein Unbekannter über einen Webzugang Zugriff auf Teile einer internen Dokumentationsplattform des Wiener Magistrats und kopierte rund 26.000 Dokumente und Seiten, etwa neun Gigabyte.
• Betroffen sind 5.824 Menschen: 2.885 Bürgerinnen und Bürger, 2.083 Beschäftigte und 856 Auftragnehmer, meist mit Namen und Mailadresse, in einzelnen Fällen mit Krankenstandstagen und Bankverbindung.
• Den ersten Hinweis gab das nationale CERT am 9. September, weil die Lücke in einem Onlineforum zum Verkauf stand. Konten und Systeme wurden nach Angaben der Stadt nicht übernommen, erpresst wurde sie nicht.
• Die Stadt meldete am 10. September freiwillig nach dem NIS-Gesetz und am 15. September an die Datenschutzbehörde. Seit dem 1. Oktober gilt das NISG 2026; für eine Landesverwaltung wäre derselbe Vorfall jetzt meldepflichtig.
• Die Lehre hängt nicht an der Fehlerklasse: Was ohne Anmeldung erreichbar ist, findet der Markt, bevor der angegriffene Betreiber es selbst bemerkt. Und eine Dokumentationsplattform ist ein Datenbestand, sobald Schulungsunterlagen echte Fälle zeigen.

Was passiert ist

Am 9. September 2026 erreicht die Stadt Wien ein Hinweis des österreichischen Computer Emergency Response Teams: In einem Onlineforum wird der Zugang zu einer Schwachstelle in einem System der Stadt zum Kauf angeboten. WienCERT und IT-Abteilung beginnen am selben Tag mit der Analyse, am 10. September geht eine freiwillige Vorfallsmeldung nach dem NIS-Gesetz hinaus. Gemeinsam mit der Direktion Staatsschutz und Nachrichtendienst wird die Lücke identifiziert und geschlossen. Befund: Ein Angreifer hatte vom 3. bis zum 11. September über einen Webzugang Zugriff auf Teile einer internen Dokumentationsplattform und kopierte Testdaten, Schulungsunterlagen und Projektdokumentationen, ohne Kontrolle über Systeme oder Benutzerkonten. Am 15. September meldet die Stadt an die Datenschutzbehörde. [1, 3]

Am 30. September macht die Stadt den Fall öffentlich: rund 26.000 Dokumente und Seiten, darunter Geschäfts- und Infrastrukturinformationen und personenbezogene Daten, in einzelnen Bereichen auch besondere Kategorien. Alle Betroffenen sollen binnen einer Woche verständigt werden. Die IT-Leitung entschuldigt sich öffentlich, die Opposition im Gemeinderat fordert Aufklärung. Hinweise auf eine Veröffentlichung der Daten gibt es nach derzeitigem Stand nicht. [1, 2, 4, 5]

Wie der Angriff gelaufen ist

Zwei Stationen hat die Stadt bestätigt, den Zugriff und den Abfluss. Davor und dazwischen liegen zwei weitere, die wir aus dem Angriffsmuster rekonstruieren.

Am Anfang steht das Absuchen, rekonstruiert. Die Stadt vermutet nach Medienberichten, dass die Lücke mit einem KI-gestützten Scan-Werkzeug gefunden wurde, und schließt Phishing aus. Das Verkaufsangebot passt dazu: Wer Zugänge handelt, sucht nicht nach Wien, er sucht nach allem, was aus dem Internet antwortet, und verkauft, was er findet. [2]

Die zweite Station ist der Zugriff, bestätigt. Die Plattform war über einen Webzugang aus dem Internet erreichbar, was bei 856 Auftragnehmern mit Daten darauf eine bewusste Entscheidung gewesen sein kann. Eine Schwachstelle gab Inhalte heraus, ohne dass der Angreifer ein Konto brauchte oder Systeme übernahm. Das schließt Codeausführung und Kontenübernahme aus und lässt Lesezugriff ohne gültige Sitzung übrig; dafür gibt es drei Fehlerklassen, und daraus folgen drei Lesarten. [1, 3]

Lesart	Woran man sie erkennt	Fällt, wenn
Berechtigungsfehler der Plattform: Seiten, Anhänge oder die Programmierschnittstelle liefern Inhalte an jeden, der die Adresse kennt	Massenabruf über fortlaufende Kennungen oder die Schnittstelle; Behebung durch Codeänderung oder Herstellerkorrektur am Berechtigungsmodell	die Stadt eine Konfigurationsursache nennt oder ein Produkt mit Advisory genannt wird
Freigabe als Konfiguration: Bereiche standen auf „für alle sichtbar“, Suchmaschinen und Scanner haben sie gefunden	Fund über Suchmaschinen oder Massenscan; Behebung ohne Patch durch Rücknahme der Freigabe; die Datenschutzbehörde wertet es als organisatorischen Mangel	ein Advisory, eine CVE oder ein Codefehler genannt wird
Bekannte Produktschwachstelle mit Berechtigungsumgehung, als Ware an Zugangshändler verkauft	dieselbe Lücke taucht bei anderen Betreibern derselben Software auf, ein Herstelleradvisory erscheint, das Forum nennt ein Produkt	kein Produkt und keine CVE auftauchen und die Lücke einzigartig bleibt

Die erste Lesart passt am besten zu allem, was die Stadt gesagt hat; wir rechnen mit ihr. Die dritte passt am besten zum Verkaufsangebot, denn eine Lücke, die sich bei vielen Betreibern wiederholt, ist auf dem Markt mehr wert als eine, die nur in Wien existiert. Ein Produkt nennen wir in keiner Lesart; die Fehlerklasse ist belegbar, der Hersteller wäre eine Beschuldigung.

Die dritte Station ist der Massenabruf, rekonstruiert. Zehntausende Seiten und Anhänge in höchstens acht Tagen von einer Quelle setzen voraus, dass niemand die Menge begrenzt hat und niemand sie gemeldet bekam. Das Muster spricht für ein Werkzeug, das alles nimmt, was erreichbar ist. [1, 4]

Die vierte Station ist der Abfluss, bestätigt. Was dazwischen fehlt, macht den Fall lehrreich: kein Einnisten, keine Seitwärtsbewegung, keine Rechteausweitung. Die Plattform gab die Inhalte heraus, wie sie dort lagen. Die eigene Erkennung hatte sechs Tage lang nichts gemeldet; nach dem Hinweis endete der Zugriff innerhalb von zwei Tagen, sofern die Schließung mit dem letzten Zugriff zusammenfällt, was die Stadt nahelegt, aber nicht datiert. Die Organisation hatte ein Erkennungsproblem, kein Reaktionsproblem.

Wo er zu brechen gewesen wäre

Welche Maßnahme gefehlt hat, steht hier nicht: Die Untersuchungen laufen, und was auf der Plattform an Schutz stand, weiß außerhalb der Aufarbeitung niemand. Beschreibbar ist, was an jeder Station wirkt.

Beim Absuchen wirkt die eigene Außensicht: Wer regelmäßig von außen prüft, was ohne Anmeldung erreichbar ist, findet die Lücke vor dem Markt. Am Zugriff wirkt die billigste Maßnahme der Kette, eine Plattform, die jede Anfrage nach einer gültigen Sitzung fragt, auch bei Anhängen, Suche und Schnittstellen; einem Scan-Werkzeug gibt sie nichts heraus, und der Verkauf im Forum findet nicht statt. Am Massenabruf wirken Mengengrenze und Alarm, gegen jede Lesart gleich, weil sie nur fragen, wie viel jemand liest. Am Abfluss entscheidet sich, was ein Zugriff erbeutet: Wer Testdaten pseudonymisiert und Schulungsbeispiele erfindet, verliert bei demselben Angriff Dokumentation, aber keine Betroffenen. Belegt ist, dass hier Echtdaten lagen; ob es dafür eine Regel gab, die umgangen wurde, oder keine, bleibt offen. [3]

Eines hat belegt gehalten: die Meldewege. Die Stadt meldete einen Tag nach dem Hinweis nach dem NIS-Gesetz, am sechsten Tag an die Datenschutzbehörde, und sie kündigte die Benachrichtigung aller 5.824 Betroffenen an. In einer Lage, die von außen angestoßen wird, ist das der Teil, den die Organisation selbst in der Hand hatte. [1]

Was der Ausfall kostet

Ausgefallen ist nichts, der Betrieb lief weiter. Die Stadt trägt die Aufarbeitung: drei Wochen Analyse, die Ermittlung der Betroffenen aus den kopierten Dokumenten, die Benachrichtigung und die politische Nacharbeit, nichts davon beziffert. [1, 5]

Den eigentlichen Schaden tragen 5.824 Menschen, und 2.885 davon hatten mit der Plattform nie etwas zu tun. Was er kostet, entscheidet sich erst, wenn die Daten irgendwo auftauchen; bis dahin ist er ein Risiko, das die Betroffenen tragen. Ein Teil der Last kehrt zurück: rechtlich als Benachrichtigung, Auskunft und Anspruch gegen denselben Bestand, und als Vorbereitung des nächsten Zugriffs, denn technische Dokumentationen und Infrastrukturinformationen beschreiben, wie die Verwaltung gebaut ist, und die Auftragnehmer stehen mit Rolle und Vorhaben darin. Wer das liest, braucht für einen zweiten Zugriff keine Lücke mehr, nur eine glaubwürdige Mail. [1, 2]

Welche Pflichten galten, und was seit Oktober anders ist

Am 10. September galt in Österreich noch das NIS-Gesetz von 2018. Es verpflichtete im Sektor öffentliche Verwaltung nur Einrichtungen des Bundes; für die übrige Verwaltung sah § 23 eine freiwillige Meldung an das GovCERT vor, und genau die hat die Stadt abgegeben. Seit dem 1. Oktober 2026 gilt das NISG 2026, die österreichische Umsetzung der NIS-2-Richtlinie, kundgemacht als BGBl. I Nr. 94/2025. Es stuft die Bundesverwaltung als wesentliche und die Verwaltung auf Landesebene als wichtige Einrichtung ein, unabhängig von der Größe; Gemeinden und Gemeindeverbände sind nach § 24 Abs. 3 ausgenommen. Wien ist Land und Gemeinde zugleich, und der Magistrat führt die Geschäfte des Landes. Nach unserer Lesart wäre derselbe Vorfall seit Oktober als erheblicher Sicherheitsvorfall meldepflichtig: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen eines Monats. Geldbußen gegen Behörden sieht das Gesetz nicht vor; die Nichteinhaltung wird per Bescheid festgestellt und bei ausbleibender Abhilfe veröffentlicht. Für Kommunen bleibt der Sektor ausgenommen, solange sie nicht selbst Wasser, Energie oder Abfall betreiben. [6, 7, 8, 10]

Die zweite Uhr lief nach der Datenschutz-Grundverordnung und kennt keinen Übergang. Art. 33 verlangt die Meldung an die Aufsicht binnen 72 Stunden ab Kenntnis der Verletzung des Schutzes personenbezogener Daten. Die Stadt meldete sechs Tage nach dem Hinweis; ob das in der Frist lag, hängt daran, ab wann sie wusste, dass personenbezogene Daten betroffen waren, und das sagt sie nicht. Art. 34 verlangt bei hohem Risiko die unverzügliche Information der Betroffenen; die Stadt kündigte sie drei Wochen nach dem Hinweis an. Eine Geldbuße kann die Datenschutzbehörde gegen die Stadt nicht verhängen, denn § 30 Abs. 5 DSG nimmt Behörden aus; Anordnungen und ein Verfahren bleiben möglich. In Deutschland erfasst das BSI-Gesetz nur die Bundesverwaltung, und ob eine Behörde eine Geldbuße bekommen kann, regelt das Landesrecht. [1, 9]

Was andere Organisationen jetzt prüfen können

Der Fall gilt für Organisationen, die interne Wissens-, Dokumentations- oder Kollaborationsplattformen betreiben, auf die auch Auftragnehmer über das Internet zugreifen, und für alle, die Testdaten, Schulungsunterlagen und Projektdokumentation auf derselben Plattform führen wie personenbezogene Echtdaten.

Drei Fragen, ohne Projekt zu beantworten:

1. Welche Seiten, Anhänge, Suchfunktionen und Schnittstellen der eigenen internen Plattformen lassen sich heute ohne Anmeldung aus dem Internet abrufen, und wer hat das zuletzt von außen ausprobiert, statt in der Konfiguration nachzulesen?
2. In welchen Testdaten, Schulungsunterlagen und Projektdokumentationen stehen echte Namen, Bankverbindungen oder Gesundheitsangaben, und wer hat sie dort freigegeben?
3. Würde ein Abruf von 26.000 Seiten durch eine einzelne Quelle innerhalb einer Woche einen Alarm auslösen, und wer bekäme ihn?

Daraus folgt eine Maßnahmenliste, geordnet nach der frühesten Station des Angriffswegs:

1. Die eigenen Adressbereiche regelmäßig von außen prüfen, im Schwachstellenmanagement; sichtbar an den kritischen Befunden über Frist und am Abarbeitungsgrad des Prüfplans.
2. Scan-Muster auf den eigenen Anwendungen erkennen und die Alarme ansehen, in der Sicherheitsüberwachung; messbar an den aktiven Erkennungsregeln.
3. Jede Seite, jeder Anhang, jede Suche und jede Schnittstelle interner Plattformen verlangt eine serverseitig geprüfte Anmeldung, in Anwendungsentwicklung und Plattformbetrieb; messbar an der Zahl nicht öffentlicher Datenbestände, die aus dem Internet erreichbar sind, Zielwert null.
4. Korrekturen des Plattformherstellers fristgerecht einspielen, im Patchmanagement; trägt nur, wenn die Lücke eine Produktschwachstelle war, dann zählt die Zahl offener, nachweislich ausgenutzter Schwachstellen.
5. Ungewöhnlich viele Abrufe von einer Quelle alarmieren, in der Sicherheitsüberwachung; messbar an den aktiven Erkennungsregeln und der Zeit bis zur Erkennung.
6. Eine Mengengrenze je Quelle und Zeitraum an Plattform oder Gateway, im Netz- und Plattformbetrieb; gezählt werden erreichbare Anwendungen ohne Mengengrenze, Zielwert null.
7. Die Melde- und Kommunikationswege benennen und hinterlegen, im Notfallmanagement: wer die NIS-Stelle, die Datenschutzbehörde und die Betroffenen informiert, und ab wann die Fristen laufen; sichtbar daran, ob jede Pflichtmeldung in der Frist war.
8. Keine ungeschützten Echtdaten in Test-, Schulungs- und Dokumentationsmaterial, verantwortet vom Datenschutz mit den Fachbereichen; ein Suchlauf nach Bankverbindungen und Gesundheitsangaben zeigt den Bestand, gezählt werden nicht-produktive Umgebungen mit Echtdaten, Zielwert null.
9. Die Reaktion üben, im Notfallmanagement: Wer darf nach einem Hinweis von außen einen Zugang sofort sperren, und wann wurde das zuletzt geübt?

Die Maßnahmen greifen ineinander: Was die eigene Außensicht nicht findet, muss die Anmeldepflicht abweisen; was trotzdem liest, muss die Mengengrenze bremsen und die Alarmierung melden; was trotzdem abfließt, darf keine Betroffenen enthalten, und was Betroffene enthält, muss in der Frist gemeldet werden. Wer die neun Punkte auf getrennte Abteilungen verteilt, bekommt neun grüne Haken und behält dieselbe Lücke.

Wie wir zu dieser Einschätzung kommen

Wir arbeiten jeden Fall nach demselben Verfahren auf, zuletzt beim Cyberangriff auf das Landesnetz Berlin: Quellenlage, Angriffspfad, wirksame Maßnahmen, Folgen, Übertragbarkeit, Grenzen. Jede Aussage trägt eine Belegstufe. Belegt heißt, eine Behörde, ein Gericht oder die betroffene Organisation selbst hat es veröffentlicht. Berichtet heißt, Medien oder ein Advisory tragen es. Rekonstruiert heißt, aus dem Muster abgeleitet und im Fall nicht bestätigt. Hier sind Zugriff und Abfluss durch die Presseaussendung der Stadt belegt; rekonstruiert sind das Absuchen, der Massenabruf, die Fehlerklasse und das Datum der Schließung.

Vier Annahmen tragen die Einordnung, jede mit der Beobachtung, die sie umstößt. Die Fehlerklasse ist ein Berechtigungsfehler der Plattform; es fällt mit der Nennung einer CVE oder eines Produkts, und dann rückt die Patch-Maßnahme nach vorn. Die Lücke wurde durch automatisiertes Absuchen gefunden; es fällt mit einer Mitteilung der Ermittlungsbehörden über eine gezielte Täterschaft. Der Abzug lief automatisiert und in Masse; es fällt mit einem selektiven Zugriffsmuster in der Aufarbeitung. Die Lücke blieb nach dem Hinweis bis zum 11. September offen; es fällt mit einer Angabe zum Datum der Schließung. Alles zum Abfluss, zu den Echtdaten und zur Rechtslage bleibt in jedem Fall unberührt.

Zur Täterfrage: Der Zugang wurde zum Kauf angeboten, das ist ein Erlösmotiv. Eine Forderung, eine Veröffentlichung, eine Zeitkopplung an einen politischen Vorgang oder ein Cluster vergleichbarer Ziele berichtet keine Quelle. Wir ordnen den Fall keinem größeren Muster zu und benennen keinen Urheber.

Grenzen und offene Fragen

Alle Angaben zum Hergang stammen aus einer Presseaussendung der Stadt und der darauf aufbauenden Agenturmeldung; einen Forensikbericht, eine Entscheidung der Datenschutzbehörde oder eine Anfragebeantwortung gibt es noch nicht. Die drei Lesarten sind Fehlerklassen, keine Produkte. Die Vermutung eines Scan-Werkzeugs ist in den Berichten selbst als Vermutung gekennzeichnet, der Massenabruf ist aus Menge und Dauer abgeleitet, und wann die Lücke geschlossen wurde, sagt die Stadt nicht. Wie viele der Dokumente Echtdaten trugen, geben die Quellen nicht her. Die Einordnung Wiens als Landesverwaltung unter dem NISG 2026 ist unsere Lesart; die Einrichtungen stufen sich selbst ein. Wir prüfen diese Punkte zum Gültigkeitsdatum erneut.

Quellen

1. Stadt Wien, Rathauskorrespondenz: Datensicherheit hat hohen Stellenwert, Sicherheitslücke umgehend geschlossen, 30.09.2026. presse.wien.gv.at
2. ORF Wien, Cyberangriff auf Stadt Wien, 30.09.2026. wien.orf.at
3. heise online, Stadt Wien entdeckt Einbruch in Online-Speicher, 30.09.2026. heise.de
4. Der Standard, Rund 26.000 interne Dokumente bei Cyberangriff auf Stadt Wien kopiert, 30.09.2026. derstandard.at
5. news.at, Cyberattacke auf Stadt Wien: Rund 26.000 interne Dokumente kopiert, 30.09.2026. news.at
6. Unternehmensserviceportal des Bundes, NIS-2: Netz- und Informationssystemsicherheitsgesetz 2026, Stand 08.09.2026. usp.gv.at
7. Österreichischer Gemeindebund, Cybersicherheitsgesetz: Ist meine Gemeinde betroffen?, 27.08.2026. gemeindebund.at
8. Schönherr Rechtsanwälte, Österreich: NISG 2026, alles was Sie wissen müssen, 25.11.2025. schoenherr.eu
9. Rechtsinformationssystem des Bundes, Datenschutzgesetz § 30, Stand 07.10.2026. ris.bka.gv.at
10. Rechtsinformationssystem des Bundes, Netz- und Informationssystemsicherheitsgesetz, BGBl. I Nr. 111/2018, 28.12.2018. ris.bka.gv.at

Stand und Aktualisierungen

Stand: 07.10.2026 · Gültig bis: 31.01.2027

• 07.10.2026, Erstveröffentlichung als Einordnung unter Vorbehalt. Zugriff und Abfluss sind von der Stadt bestätigt, Absuchen, Massenabruf, Fehlerklasse und Schließungsdatum sind Annahmen.

Zum Stichtag prüfen wir vier Punkte: Anfragebeantwortungen im Wiener Gemeinderat, Warnungen des CERT zu einem Auftauchen der Daten, ein Verfahren der Datenschutzbehörde und ein Prüfersuchen des Stadtrechnungshofs. Wir aktualisieren diesen Artikel auch dann, wenn sich unsere Annahmen als falsch erweisen.

---

Wie wir arbeiten: KaitoSec analysiert Cyberangriffe nach einem festen Verfahren und leitet daraus Maßnahmen mit Wirkungsnachweis ab, für Organisationen mit gewachsener IT und regulatorischem Druck. Das Verfahren ist offengelegt, die Fallanalysen sind es auch. Gespräch dazu vereinbaren.