Future{hacks}: KI findet Sicherheitslücken. Ihre IT auch?
Trending Topics auf Google als bevorzugte Nachrichtenquelle festlegen.
Künstliche Intelligenz beschleunigt die Entdeckung kritischer Sicherheitslücken und Schwachstellen. Doch viele Unternehmen stehen vor einem ganz anderen Problem: Sie wissen nicht, ob sie betroffen sind und wer das überhaupt beurteilen kann.
Am 21. Oktober 2026 wurde es für zahlreiche IT-Abteilungen ziemlich ungemütlich. Zwei kritische Sicherheitslücken in PHP wurden bekannt (Schweregrad 9,2 von 10). Am selben Tag veröffentlichte das Node.js-Projekt Sicherheitsupdates für zehn Schwachstellen, vier davon mit hohem Schweregrad. Für viele Geschäftsführer:innen klingt das zunächst nach einem technischen Problem, das man guten Gewissens der IT überlassen kann. Schließlich beschäftigt man dafür Spezialist:innen, oder?
Spannend wird die Geschichte, wenn man sich ansieht, welche Rolle künstliche Intelligenz bei der Suche nach diesen Schwachstellen spielte. Die PHP Foundation ließ ihren Code in diesem Jahr unter anderem mit Anthropics KI-Modell Claude Mythos prüfen. OpenAI sowie die Sicherheitsfirmen Wiz und Trail of Bits stießen bei eigenen Prüfungen auf dieselben Lücken. Bei Node.js meldeten Forschende von OpenAI Codex Security, dem KI-gestützten Sicherheitsdienst von OpenAI, die schwerwiegendste Lücke: einen Fehler im Brotli-Dekompressor, der im schlimmsten Fall das Ausführen von Schadcode aus der Ferne ermöglicht. Was früher aufwendige manuelle Untersuchungen erforderte, lässt sich dadurch zunehmend beschleunigen. Und das dürfte erst der Anfang sein: Mit leistungsfähigeren KI-Modellen wächst auch die Zahl der Sicherheitslücken, die innerhalb kurzer Zeit gefunden werden-.
Wie schnell daraus Ernst wird, zeigte sich prompt. Bereits rund um die Veröffentlichung meldeten Cloudflare und Chainguard erste Angriffsversuche auf die PHP-Lücken, Hunderte Websites gingen vorsorglich vom Netz.
„Ein Fix in einer veröffentlichten Version ist noch kein Fix im Produktivbetrieb“,
schreibt Chainguard-CEO Dan Lorenc (übersetzt aus englischem Original).
Entscheidend sei, wie schnell Unternehmen verfügbare Korrekturen testen, freigeben und tatsächlich einsetzen können. Angesichts der beschleunigten Entdeckung von Schwachstellen betont Lorenc deshalb auch die gemeinsame Verantwortung der Branche, kritische Infrastruktur rechtzeitig vor Angriffen zu schützen.
Für Unternehmen entsteht daraus eine unangenehme Frage: Wenn Sicherheitslücken immer effizienter gefunden werden, wer stellt sicher, dass die eigene IT davon erfährt? Und noch wichtiger: Wer kann beurteilen, was eine solche Meldung für das Unternehmen konkret bedeutet?
Kritische PHP-Sicherheitslücken: Sind wir betroffen?
Wie weitreichend die Auswirkungen solcher Schwachstellen sein können, zeigt das niederländische National Cyber Security Centre. Mit Stand 2. November 2026 listet die Behörde in ihrem Verzeichnis 930 Softwareprodukte, die PHP enthalten und damit betroffen sein könnten. 215 davon gelten als verwundbar, für 167 ist bereits eine Behebung verfügbar. Bei 240 hängt die Betroffenheit von der jeweiligen Umgebung ab, 93 werden noch geprüft.
Das bedeutet natürlich nicht, dass automatisch 930 Produkte unsicher sind. Es zeigt aber, wie weit eine einzelne Schwachstelle streuen kann. PHP steckt schließlich nicht nur hinter klassischen Websites, sondern auch in Unternehmensanwendungen und Produkten unterschiedlichster Hersteller. Abgesichert sind die PHP-Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 sowie Node.js 22.23.4, 24.22.1 und 26.12.1.
Aufschlussreich ist auch der Zeitplan: CERT.at warnte schon am Vorabend vor dem bevorstehenden Sicherheitsupdate und empfahl, betroffene Systeme zu identifizieren. Die Information war also öffentlich verfügbar, bevor die Updates überhaupt erschienen. Nur nützt die beste Warnung wenig, wenn sie niemanden erreicht, der damit etwas anfangen kann.
Stellen wir uns einen österreichischen Mittelständler mit knapp 100 Mitarbeiter:innen vor, dessen Kundenplattform von einem externen Entwicklungspartner betreut wird, während die interne IT für die Infrastruktur verantwortlich ist. Jetzt erscheint eine kritische PHP-Sicherheitsmeldung. Wer überprüft, ob die Plattform betroffen ist? Und verfügt die interne IT überhaupt über das notwendige Wissen, um die Auswirkungen beurteilen zu können?
Das Beispiel ist konstruiert, die dahinterliegenden Fragen sind allerdings keineswegs exotisch. In der Praxis erleben wir als Softwaredienstleister immer wieder, dass Zuständigkeiten grundsätzlich geklärt sind, die notwendigen Ressourcen oder das spezifische Know-how für solche Bewertungen aber nicht immer zur Verfügung stehen.
Denn häufig mangelt es nicht am Verantwortungsbewusstsein, sondern an der Fähigkeit, eine technische Warnung schnell genug in eine konkrete Risikobewertung zu übersetzen.
Fachkräftemangel in der IT-Sicherheit: Selbst Expert:innen kommen an ihre Grenzen
Wie schwierig das sein kann, zeigt ausgerechnet die PHP Foundation selbst. In ihrer Stellungnahme vom 21. Oktober beschreibt sie, dass erste Hinweise auf eines der Sicherheitsprobleme bereits 2024 aus einem externen Sicherheitsaudit bekannt waren. Unterschiedliche Lösungsansätze brachten technische Nachteile mit sich, etwa Brüche in der Abwärtskompatibilität, während dem kleinen Kernteam die Ressourcen fehlten, um sämtliche Möglichkeiten ausreichend zu untersuchen.
Die Foundation spricht offen von einem “strukturellen Versagen” verursacht durch ihre Entscheidungsprozesse und fehlende Ressourcen. Erst die zusätzliche Sicherheitsforschung in diesem Jahr machte das volle Ausmaß der Schwachstelle deutlich und erhöhte den Handlungsdruck. Inzwischen hat die Foundation reagiert: Seit Mai gibt es ein eigenes Ecosystem Security Team, Sicherheitsentscheidungen fallen künftig per Mehrheit statt im Konsens.
Das ist vielleicht die wichtigste Erkenntnis der gesamten Geschichte. Selbst jene Expert:innen, die eine weltweit eingesetzte Programmiersprache entwickeln, können bei komplexen Sicherheitsproblemen an ihre Grenzen stoßen. Was erwarten wir dann von einem österreichischen Mittelständler, dessen zweiköpfiges IT-Teamnebenbei noch den laufenden Betrieb sicherstellen muss?
Dass die nötigen Kompetenzen nicht selbstverständlich verfügbar sind, zeigen auch europäische Daten. Laut dem ENISA-Bericht „NIS Investments 2025“ tun sich 76 Prozent der befragten Organisationen schwer, Sicherheitsfachleute zu gewinnen, 71 Prozent fällt es schwer, sie zu halten. Befragt wurden überwiegend große Organisationen aus regulierten Sektoren. Die kleineren Unternehmen in der Stichprobe schätzen ihre Fähigkeit, Sicherheitsvorfälle zu bewältigen, am geringsten ein.Nun wäre es bequem, daraus die Forderung nach mehr Personal und größeren Sicherheitsbudgets abzuleiten. Nur wird die Realität dadurch nicht einfacher. Ein Unternehmen mit 100 Mitarbeiter:innen kann und muss sich nicht dieselbe Security-Organisation leisten wie ein internationaler Konzern. Entscheidend ist vielmehr, ob es auf die passende Kompetenz zugreifen kann, wenn sie gebraucht wird.
Software ist kein Selbstläufer
Genau hier beginnt für mich die Verantwortung des Managements. Nicht darin, selbst PHP-Versionen zu überprüfen oder technische Sicherheitsmeldungen zu interpretieren. Sondern sicherzustellen, dass diese Aufgaben auch erledigt werden können.
Dabei sollten wir uns von einer verbreiteten Annahme verabschieden: Nur weil eine Anwendung von einem externen Dienstleister entwickelt oder betreut wird, ist ihre Sicherheit nicht automatisch vollständig abgedeckt. Zwischen Entwicklung, Hosting, Wartung und laufender Sicherheitsüberwachung liegen unterschiedliche Leistungen. Was davon vereinbart wurde, entscheidet der Vertrag und nicht die Erwartungshaltung beim nächsten Sicherheitsvorfall.
Wer schon einmal an einem größeren Softwareprojekt beteiligt war, kennt das Problem. Während der Entwicklung wird ausführlich über Funktionen, Schnittstellen, Budgets und Liefertermine diskutiert. Beim laufenden Betrieb geht man dagegen erstaunlich schnell davon aus, dass sich schon jemand darum kümmern wird.
Unternehmen investieren viel Zeit in die Auswahl ihrer Software. Erstaunlich wenig Aufmerksamkeit bekommt dagegen manchmal die Frage, wer Jahre später noch versteht, wie sicher sie betrieben wird. Wie konkret das werden kann, zeigen die aktuellen Fälle: Für PHP 8.1 und älter liefert das PHP-Projekt keine regulären Updates mehr, sondern nur noch minimale Quellcode-Patches. Bei Node.js erhalten Version 20 und älter gar keine Korrekturen mehr, hier hilft nur der Umstieg auf eine aktuelle Version. Wer solche Altversionen betreibt, hat ein Wartungsproblem.
Die Antwort darauf muss nicht zwangsläufig eine eigene Security-Abteilung sein. Automatisierte Schwachstellen-Scans erkennen bekannte Sicherheitslücken, ein funktionierendes Patch-Management sorgt dafür, dass Sicherheitsupdates zeitnah eingespielt werden, und interne oder externe Spezialist:innen beurteilen, welche Meldungen relevant sind. Wichtig ist, dass diese Fähigkeiten vorhanden sind und Informationen ohne Umwege bei den richtigen Menschen ankommen. Zusätzliche Freigabeschleifen und umfangreiche Dokumentationspflichten helfen dabei wenig, wenn sie die eigentliche Reaktion nur verzögern.
Denn Angreifer:innen interessiert es herzlich wenig, wie schön der interne Sicherheitsprozess dokumentiert ist.
Schwachstellenmanagement im Mittelstand: Drei Fragen an die eigene IT
Wer wissen will, wie gut das eigene Unternehmen aufgestellt ist, braucht dafür nicht gleich ein Audit. Drei Fragen reichen für den Anfang:
1. Wer verfolgt Sicherheitsmeldungen, etwa von CERT.at, für unsere Systeme?
2. Wer entscheidet, ob wir betroffen sind: die interne IT, der Entwicklungspartner oder der Hoster?
3. Ist das Patch-Management in unseren Wartungsverträgen geregelt, inklusive Reaktionszeiten?
Wer auf eine dieser Fragen nur mit Schulterzucken antworten kann, weiß zumindest, wo anzufangen ist.
Unser Future{hacks} Fazit
Künstliche Intelligenz verändert die Sicherheitsforschung: Sie findet Schwachstellen schneller und erhöht den Druck, bekannte Probleme endlich zu beheben. Auch das ist eine Folge davon, dass die KI längst weiter ist als ihr Sicherheitskäfig. Gleichzeitig wächst damit die Bedeutung einer Fähigkeit, die in vielen Unternehmen zu kurz kommt: zu verstehen, welche Sicherheitsmeldungen für die eigenen Systeme überhaupt relevant sind.
Das Management muss dafür nicht selbst Sicherheitsexpertise aufbauen. Es sollte aber wissen, ob jene Menschen, denen es diese Verantwortung übertragen hat, über die nötigen Ressourcen und Fähigkeiten verfügen. Denn die nächste kritische Sicherheitslücke wird mit hoher Wahrscheinlichkeit nicht auf die nächste Budgetrunde warten.
Vielleicht lohnt sich deshalb schon heute eine kurze Frage an die eigene IT:
„Waren wir von den PHP- und Node.js Lücken vom 21. Oktober betroffen?”
Wer darauf keine belastbare Antwort bekommt, hat möglicherweise ein größeres Problem als die Sicherheitslücke selbst.
Markus Kirchmaier ist Prokurist & Partner bei LEAN-CODERS und beschäftigt sich seit Jahren intensiv mit dem IT-Arbeitsmarkt sowie modernen IT-Systemen und technologischen Entwicklungen. Hier geht es zu den anderen Beiträgen aus der Future{hacks}-Reihe.
