Wie viele Lücken noch schlummern

Kurze Frage: In welcher Programmiersprache läuft dein ILIAS oder Moodle? Falls du es nicht weißt, bist du in guter Gesellschaft. Die Antwort ist PHP, und genau darin steckte die Lücke, wegen der letzten Mittwoch an vielen Unis diese Systeme offline waren.

PHP

Was PHP ist und warum so viel darauf läuft

PHP ist eine Programmiersprache für Websites. Entstanden ist sie in 1994, ursprünglich um zu zählen, wer seinen Online-Lebenslauf anschaut, ein Jahr später wurde der code freigegeben. PHP läuft auf dem Server: Wenn du eine Seite aufrufst, baut PHP sie zusammen, bevor sie in deinem Browser landet, mit deinen Kursen, Noten oder Mails. (php.net)

Heute läuft damit ein großer Teil des Webs, laut W3Techs rund 69 Prozent aller Websites, deren Programmiersprache bekannt ist. WordPress und Wikipedia sind in PHP geschrieben, und vieles, was du im Studium nutzt, zum Beispiel Moodle und ILIAS. (W3Techs, GitHub)

Warum ausgerechnet PHP? Die Sprache ist kostenlos, gilt als leicht zu lernen und läuft bei fast jedem Webhoster. Und was einmal läuft, bleibt oft jahrelang, an Unis gerade bei Lernplattformen und Websites.

Genau das macht eine Lücke in PHP selbst so heikel: Sie steckt nicht in einer einzelnen Seite, sondern in allen, die eine betroffene Version nutzen. Deshalb haben letzten Mittwoch so viele Hochschulen gleichzeitig abgeschaltet.

Für dich

Deine Uni

Warum ILIAS öfter offline sein könnte

Dass dein ILIAS am Mittwoch weg war, war also Absicht. Freiburg etwa hat Websites, ILIAS, Webmail und Bibliotheksdienste vorsorglich vom Netz genommen, bis das Update da war. Eingebrochen ist dort nach Wissen der Uni niemand. Freiburg rechnet aber damit, dass solche Abschaltungen häufiger werden, weil KI das Finden von Lücken leichter macht. (Uni Freiburg)

Dass es nicht immer so glimpflich ausgeht, zeigt Halle. Dort konnten Unbekannte womöglich auf rund 51.000 Bewerbungen für dieses und das letzte Semester zugreifen, mit Namen, Adressen, Geburtsdaten und Zulassungsstatus. Bemerkt hat die Uni das am 14. Oktober, eine Ursache nennt sie bisher nicht. Wenn du dich dort beworben hast: Sei bei Mails und Anrufen mit Uni-Bezug misstrauisch und gib keine Bank- oder Passwortdaten heraus. (Uni Halle, Forschung & Lehre)

Auch bei der LMU München und beim Hochschulservicezentrum Baden-Württemberg gab es zuletzt echte Angriffe. (Jan-Martin Wiarda)

„Die aktuellen Abschaltungen erfolgten dagegen vorsorglich, um genau das zu verhindern.“

Zahlen

Mehr als 4.000 neue Lücken in einer Woche

Jede bekannte Sicherheitslücke bekommt eine Nummer, eine sogenannte CVE, damit alle von derselben Lücke reden, vom Hersteller bis zur IT deiner Uni. Gesammelt werden die Nummern unter anderem in der US-Datenbank NVD. Dort sind letzte Woche 4.073 neue dazugekommen, fast 600 am Tag. (NVD)

Ein Ausreißer war das nicht. Im September waren es 14.933, mehr als dreimal so viele wie im September 2025. Seit Januar sind es schon 86.515, fast doppelt so viele wie im ganzen letzten Jahr. (NVD)

Warum es so viele sind

Ein großer Teil kommt von wenigen Stellen. Gut ein Viertel der Woche, 1.078 Lücken, hat Oracle eingetragen. Der Konzern bringt alle drei Monate ein großes Sicherheitsupdate heraus, diesmal am Dienstag mit 1.295 Patches. Dahinter folgen die Sicherheitsfirma VulnCheck mit 510, Googles Chrome-Team mit 353 und GitHub mit 315. (NVD, Oracle)

Es wird auch mehr gezählt. Nummern vergeben dürfen inzwischen 556 Organisationen aus 44 Ländern, 28 davon aus Deutschland, etwa SAP, Siemens und Bosch. Der Linux-Kernel vergibt seit 2024 für praktisch jede Fehlerkorrektur eine eigene Nummer, dieses Jahr schon 8.073. Von den rund 5.000 Kernel-Lücken bis August wurde laut Google keine einzige als Zero-Day ausgenutzt, also bevor es ein Update gab. Bei GitHub, wo Open-Source-Projekte ihre Lücken melden, sind es seit Januar 12.056, mehr als viermal so viele wie im ganzen Jahr 2025. (CVE.org, Linux-Kernel, Google Threat Intelligence, cve.icu)

Und jetzt sucht KI mit

PHP2Shell haben gleich drei Teams mit KI-Hilfe gefunden, und das ist kein Einzelfall. Mit KI entdeckt wurden laut IBM von Januar bis September mindestens 10.124 Lücken, fast siebenmal so viele wie im Vorjahreszeitraum. Google hat gezählt, dass sich die Zahl der jeden Monat veröffentlichten Lücken zwischen Januar und August mehr als verdoppelt hat, von 5.045 auf 10.740. (IBM X-Force via heise, Google Threat Intelligence)

Wie sich das anfühlt, beschreibt Daniel Stenberg, der das Programm curl betreut. Das steckt in Autos, Fernsehern und Handys, laut curl in über 20 Milliarden Installationen. KI-Müll komme seit dem Frühjahr praktisch nicht mehr, schreibt er, das neue Problem seien sehr viele, sehr gute Meldungen, bei jeder habe KI mitgeholfen. Ab heute müssen weniger schwere Lücken bei curl öffentlich gemeldet werden, weil die Flut das Team überlastet. (curl)

Gefunden werden dabei oft Lücken, die schon ewig da sind. PHP2Shell steckte mindestens 14 Jahre im Code, Shellshock sogar 22.

Geprüft wird nur ein Bruchteil

Eine Nummer allein sagt noch wenig. Wie gefährlich eine Lücke ist und welche Versionen betroffen sind, trägt die NVD erst nach einer Prüfung ein. Von den 4.073 Lücken der letzten Woche hat sie bisher 403 fertig geprüft, also etwa jede zehnte. 1.181 hat sie zurückgestellt, der Rest wartet noch. (NVD)

Seit April prüft die NVD zuerst Lücken, die nachweislich ausgenutzt werden oder Software betreffen, die US-Behörden nutzen, alles andere hat niedrigste Priorität. Der Rückstand ist laut einem Prüfbericht des US-Handelsministeriums von rund 13.000 Lücken im Juni 2024 auf über 27.000 Ende 2025 gewachsen. (NIST, US-Handelsministerium)

Für die IT deiner Uni und dich heißt das: Sie muss oft selbst einschätzen, was dringend ist.

Ausgenutzt wird wenig, aber immer schneller

Die gute Nachricht: Nur ein winziger Teil der Lücken wird je für echte Angriffe genutzt, 2026 bisher 0,23 Prozent, etwa jede 431. Von den Lücken der letzten 30 Tage stehen bisher 20 auf der Liste der US-Behörde CISA, in der sie nachweislich ausgenutzte Lücken sammelt. (Google Threat Intelligence, CISA)

Die schlechte: Es werden trotzdem mehr, bis August im Schnitt 18 im Monat, 2025 waren es 10,5. Und es geht schneller. 2018/19 vergingen im Schnitt noch 63 Tage vom Bekanntwerden bis zum ersten Angriff, 2023 nur noch 5. Bei PHP2Shell landete der erste Versuch sogar vier Tage vor dem Update in einer Falle von Amazon. (Google Threat Intelligence, Mandiant, AWS)