Eine Grafik mit rotem Hintergrund, die eine digitale IT-Struktur in einem abstrakten Design darstellt. Geeignet für technische Themen.
Die Ludwig-Maximilians-Universität München hat am 19. September 2026 einen Datenschutzvorfall öffentlich gemacht: Ein Angreifer ist unbefugt in ein IT-System mit Stammdaten zu Immatrikulationen eingedrungen – und hat die Daten nach heutigem Stand auch abgerufen.
Was beim Cyberangriff LMU München passiert ist, welche Daten das Haus verlassen haben und welche fünf Fragen jede Geschäftsführung daraus für den eigenen Betrieb ableiten sollte, lesen Sie hier.
Das Wichtigste in Kürze
- Der Angriff wurde am Mittwoch, dem 16. September 2026, bemerkt; die Öffentlichkeit erfuhr davon am Samstag, dem 19. September - drei Tage später
- Betroffen ist ein einzelnes Fachsystem mit Immatrikulationsstammdaten von Studierenden und Studienbewerbenden, nicht die gesamte Hochschul-IT
- Abgeflossen sind identifizierende Daten, Kontaktdaten, Bankdaten, Krankenversicherungs- und BAföG-Nummern sowie Angaben zu Schul- und Studienabschlüssen, in Einzelfällen auch besondere Kategorien nach Artikel 9 DSGVO
- Nicht betroffen sind nach Angaben der LMU Prüfungs- und Leistungsdaten sowie Passwörter und LMU-Benutzerkennungen
- Es gibt bislang keine Anhaltspunkte für eine Veröffentlichung der Daten; das Bayerische Landeskriminalamt ermittelt, Spezialisten beobachten Darknet-Portale
So lief der Cyberangriff auf die LMU München ab
Nach Darstellung der Universität fiel der Vorfall am Mittwoch, dem 16. September 2026, auf. Ein unbefugter Angreifer hatte Zugriff auf Stammdaten aus einem System, das die Immatrikulation verwaltet. Die LMU formuliert es in ihrer Mitteilung deutlich: Man müsse derzeit davon ausgehen, dass diese Daten auch abgerufen wurden.
Die IT-Abteilung reagierte unmittelbar nach den ersten Anzeichen und nahm das betroffene System vollständig vom Netz, um weiteren Abfluss zu verhindern.
Parallel wurden externe IT-Forensiker eingeschaltet, die Sicherheitsüberwachung erweitert und das Bayerische Landeskriminalamt eingebunden.
Die technische Aufklärung dauert an.
Öffentlich gemacht wurde der Vorfall am Samstag, dem 19. September – drei Tage nach der Entdeckung. Diese Lücke wurde politisch kritisiert: Medienberichten zufolge wurde darauf verwiesen, dass die Datenschutz-Grundverordnung eine unverzügliche Benachrichtigung Betroffener verlange, und forderte Transparenz über Ursache und Ablauf. Die LMU verweist ihrerseits auf die enge Zusammenarbeit mit Ermittlungs- und Aufsichtsbehörden.
Zum Einfallsweg gibt es bislang keine belastbaren Angaben. Weder die Universität noch die Berichterstattung nennen eine ausgenutzte Schwachstelle, kompromittierte Zugangsdaten oder einen konkreten Softwarestand. Wer den Fall bewertet, sollte das im Blick behalten: Alles, was derzeit über das „Wie“ gesagt wird, ist Spekulation.
Diese Daten sind abgeflossen
Die LMU hat die betroffenen Datenkategorien ungewöhnlich sauber aufgeschlüsselt. Nach ihren Angaben sind betroffen:
- Identifizierende Daten - Name, Geburtsdatum, Geschlecht, gegebenenfalls Geburtsort oder Geburtsland
- Kontaktdaten - Semester- und Heimatanschrift, ggf. Telefonnummer, LMU-E-Mail-Adresse und gegebenenfalls eine weitere E-Mail-Adresse
- Bankdaten - unter anderem IBAN und Name des Kontoinhabers
- Sozial- und Verwaltungsdaten - Krankenversicherungsnummern und BAföG-Nummern
- Bildungsdaten - Angaben zu Schul- und Studienabschlüssen sowie zum Studienverlauf
- In Einzelfällen besondere Kategorien nach Artikel 9 DSGVO - etwa hinterlegte Gründe für eine Beurlaubung
Ausdrücklich nicht betroffen sind nach Angaben der Hochschule Prüfungsinformationen, konkrete Angaben zu Studieninhalten und individuellen Leistungen sowie Passwörter und LMU-Benutzerkennungen. Eine generelle Passwortänderung hält die LMU deshalb nicht für zwingend erforderlich.
Die Kombination ist das Problem, nicht die einzelne Angabe
Name, Geburtsdatum, Anschrift und IBAN ergeben zusammen einen vollständigen Identitätsbaukasten – genug für Bestellbetrug, Vertragsabschlüsse und Lastschriftmissbrauch im Namen der Betroffenen. Krankenversicherungs- und BAföG-Nummern machen jede spätere Phishing-Mail glaubwürdig, weil sie Wissen belegen, das ein Fremder nicht haben sollte.
Zahlen zum Cyberangriff auf die LMU München
16.09.2026
Tag der Entdeckung
3 Tage
bis zur öffentlichen Information am 19.09.2026
über 52.000
Studierende im Wintersemester 2025/26
0
bisher bekannte Veröffentlichungen der Daten
Eine offizielle Zahl der Betroffenen gibt es nicht. Die 52.000 sind die Einschreibezahl des vergangenen Wintersemesters und damit eine Größenordnung, keine Betroffenenzahl. Weil auch Studienbewerbende im System stehen und unklar ist, wie weit die Datenhistorie zurückreicht, kann der tatsächliche Kreis größer sein.
Warum ein Datenabfluss ohne Verschlüsselung gefährlich bleibt
Der Fall LMU hat kein Ransomware-Muster: keine verschlüsselten Server, keine Lösegeldforderung, keine Leak-Seite mit Countdown. Genau deshalb wird er unterschätzt.
Ein Verschlüsselungsvorfall ist laut und hat ein Ende. Ein Backup wird eingespielt, der Betrieb läuft wieder, der Schaden ist bezifferbar. Ein reiner Datenabfluss ist leise und hat kein Ende. Die Daten sind kopiert, sie lassen sich nicht zurückholen, und sie verlieren über Jahre kaum an Wert. Ein Geburtsdatum ändert sich nicht, eine IBAN selten, eine Anschrift nur beim Umzug.
Hinzu kommt die Verwertungskette. Zwischen Abfluss und Missbrauch liegen oft Monate:
- Daten werden gebündelt und mit Material aus anderen Lecks angereichert.
- Dann folgt personalisiertes Phishing – mit echten Namen, echten Vorgangsdaten, echtem Bezug.
- Parallel laufen Identitätsmissbrauch und vorbereitete Anrufe bei Banken und Dienstleistern.
Wie stark echte Namen, echte Zuständigkeiten und echte Vorgangsdaten die Glaubwürdigkeit eines Angriffs erhöhen, zeigt der Beitrag zum Datenleck im Berliner Landesnetz.
Dass bisher nichts veröffentlicht wurde, ist deshalb kein Entwarnungssignal. Es bedeutet nur, dass der Angreifer bislang keinen Anlass hatte, Druck aufzubauen oder einen anderen Verwertungsweg gewählt hat.
Was Unternehmen aus dem Fall mitnehmen
1
Ein einzelnes Fachsystem reicht
Gehackt wurde nicht die zentrale IT, sondern ein System für einen einzelnen Prozess. In Unternehmen sind das die Bewerbermanagement-Lösung, das Zeiterfassungssystem, das Kundenportal, die Lohnbuchhaltung – Anwendungen, die außerhalb des Kernbetriebs laufen und selten im Fokus stehen. Sie enthalten trotzdem Stammdaten, Bankverbindungen und Sozialdaten.
2
Alte Daten wiegen schwer
Der wahrscheinlichste Grund, warum der Kreis der Betroffenen größer sein könnte als die aktuelle Studierendenzahl: Es stehen noch Bewerbungs- und Altdaten im System. Dasselbe gilt für abgelehnte Bewerber, ausgeschiedene Mitarbeitende und beendete Kundenbeziehungen. Jeder Datensatz ohne Löschfrist ist eine Verbindlichkeit, die nur im Schadensfall sichtbar wird.
3
Erkennung entscheidet über den Umfang
Die LMU hat den Zugriff bemerkt und das System innerhalb desselben Tages isoliert. Das ist der Unterschied zwischen einem begrenzten Vorfall und einem, der über Wochen läuft. Wer Exfiltration nicht sieht, erfährt davon erst aus der Presse oder von der Aufsichtsbehörde.
4
Kommunikation ist Teil der Abwehr
Die drei Tage bis zur Information sind der Punkt, an dem der Fall öffentlich angreifbar wurde – nicht der Angriff selbst. Wer erst im Ernstfall klärt, wer was wann sagt, verliert genau diese Zeit.
Empfehlungen für IT-Admins
Eine Universität mit 52.000 Studierenden wirkt weit weg vom Mittelstand. Das Muster ist es nicht. Die folgenden Punkte adressieren genau die Stellen, an denen der Fall LMU übertragbar ist – warum gestohlene Zugangsdaten dabei der meistgenutzte Einstieg bleiben, zeigt der Beitrag zu Identity Threats.
- Fachsysteme inventarisieren: Welche Anwendung hält welche personenbezogenen Daten, wer betreibt sie, wie wird sie gepatcht? Schattenanwendungen ohne benannten Verantwortlichen sind der häufigste Startpunkt
- Segmentieren: Ein System mit Stammdaten braucht keinen Weg zu jedem anderen System. Isolation ist das, was aus einem Vorfall einen begrenzten Vorfall macht
- Zugriffe auf Datenbestände protokollieren und auswerten: nicht nur Anmeldungen, sondern Massenabfragen und Exporte. Ein ungewöhnlich großer Datenabzug ist das Signal, das den Unterschied macht
- Löschkonzept tatsächlich anwenden: Aufbewahrungsfristen definieren, automatisiert durchsetzen und regelmäßig prüfen. Nicht vorhandene Daten müssen nicht geschützt werden
- Zugänge absichern: Multifaktor-Authentifizierung auch für Fachanwendungen und Fernzugriffe, keine geteilten Dienstkonten
- Phishing-Nachlauf einplanen: Nach einem Datenabfluss steigt die Qualität der Angriffe auf die Betroffenen. Mitarbeitende und Kunden gezielt vorwarnen - das Muster beschreibt der Beitrag zu Phishing und Spam im Unternehmen
- Meldeweg vorbereiten: Die 72-Stunden-Frist nach Artikel 33 DSGVO läuft ab Kenntnis, nicht ab abgeschlossener Forensik. Eine Erstmeldung mit unvollständigem Bild ist zulässig und richtig
Bedeutung für Geschäftsführung und Entscheider
Der Cyberangriff LMU München ist kein Ausfallszenario. Es gab keinen Stillstand, keine Erpressung und keine bezifferbare Betriebsunterbrechung – und trotzdem einen dauerhaften Schaden, der sich nicht mehr einsammeln lässt.
Diese Art von Vorfall taucht in den meisten Notfallplanungen nicht auf, weil dort die Verfügbarkeit im Mittelpunkt steht und nicht die Vertraulichkeit.
Rechtlich ist die Lage klar. Artikel 33 DSGVO verlangt die Meldung an die Aufsichtsbehörde binnen 72 Stunden ab Kenntnis, Artikel 34 die Benachrichtigung der Betroffenen bei hohem Risiko. Bei Bankdaten und Sozialdaten ist dieses hohe Risiko schwer zu bestreiten. Dazu kommt die Nachweispflicht aus Artikel 32: Wer nicht dokumentiert hat, welche Schutzmaßnahmen bestanden, kann sie im Nachgang nicht belegen.
- In welchen Systemen liegen Bankverbindungen, Sozialdaten und Ausweisdaten unserer Mitarbeitenden, Bewerber und Kunden?
- Wie lange bewahren wir diese Daten auf - und wer prüft, ob die Löschung tatsächlich stattfindet?
- Würden wir einen Massenexport aus einem dieser Systeme bemerken, und woran?
- Wer entscheidet innerhalb von 72 Stunden über eine Meldung an die Aufsichtsbehörde, und wer vertritt diese Person im Urlaub?
- Wer informiert Betroffene, Kunden und Presse - mit welchem Text, freigegeben von wem?
Wer bei mehr als einer Frage passen muss, hat keine Technik-, sondern eine Organisationslücke. Sie ist deutlich günstiger zu schließen als ein Vorfall, der sie sichtbar macht. Einen kompakten Einstieg bietet der Beitrag mit 10 IT-Sicherheitstipps für Unternehmen.
FAQ zum Cyberangriff auf die LMU München
Eine offizielle Zahl nennt die LMU nicht. Im Wintersemester 2025/26 waren über 52.000 Studierende eingeschrieben. Da auch Studienbewerbende im betroffenen System gespeichert sind, kann der Kreis größer sein.
Nach Angaben der LMU: Name, Geburtsdatum, Geschlecht, gegebenenfalls Geburtsort, Semester- und Heimatanschrift, Telefonnummer, E-Mail-Adressen, IBAN und Kontoinhaber, Krankenversicherungs- und BAföG-Nummern sowie Angaben zu Schul- und Studienabschlüssen. In Einzelfällen auch besondere Kategorien nach Artikel 9 DSGVO.
Nein. Die LMU gibt an, dass Passwörter, LMU-Benutzerkennungen sowie Prüfungs- und Leistungsdaten nicht betroffen sind. Ein regelmäßiger Passwortwechsel bleibt trotzdem sinnvoll.
Es gibt keine Hinweise darauf. Systeme wurden nicht verschlüsselt, eine Lösegeldforderung ist nicht bekannt, und die Daten wurden bislang nicht veröffentlicht. Spezialisten beobachten einschlägige Darknet-Portale.
Kontoauszüge und Lastschriften engmaschig prüfen, bei unbekannten Abbuchungen sofort widersprechen. E-Mails, Anrufe und Nachrichten mit LMU-Bezug kritisch behandeln, keine Anhänge oder Links ungeprüft öffnen und weder Bankdaten noch Passwörter herausgeben. Die LMU hat für Rückfragen die Adresse cybersicherheit@lmu.de eingerichtet.
Ja. Kompromittiert wurde ein einzelnes Fachsystem mit Stammdaten. Bewerbermanagement, Lohnbuchhaltung, Zeiterfassung und Kundenportale sind in Unternehmen die direkte Entsprechung - mit denselben Datenkategorien und oft mit weniger Aufmerksamkeit.
Fazit
Der Cyberangriff LMU München zeigt den Vorfall, den niemand einplant: keine Verschlüsselung, kein Stillstand, keine Erpressung – und trotzdem ein Schaden, der bleibt. Ein einzelnes Fachsystem mit Stammdaten hat gereicht, um Namen, Anschriften, Bankverbindungen und Sozialdaten Zehntausender Menschen aus dem Haus zu tragen.
Gut gelaufen ist die Reaktion: bemerkt, isoliert, forensisch untersucht, Behörden eingebunden, Datenkategorien offen benannt. Angreifbar wurde der Fall dort, wo Organisation statt Technik gefragt war – bei der Frage, wie schnell und wie offen kommuniziert wird.
Für Unternehmen ist die Übertragung unbequem einfach: Jedes System, das Bankdaten und Sozialdaten hält, ist ein lohnendes Ziel, auch wenn es nur einen Nebenprozess bedient. Wer heute nicht sagen kann, wo diese Daten liegen, wie lange sie bleiben und wer im Ernstfall binnen 72 Stunden entscheidet, sollte genau dort anfangen – nicht beim nächsten Sicherheitsprodukt.