Freitag, 9. Oktober, 16:40 Uhr. Ein fiktives Szenario, aber die Stimmung kennen Sie vermutlich. Die IT-Leiterin eines Mittelständlers – namenlos, erfunden – liest die neue Ergänzung im KEV-Katalog der US-Behörde CISA. Fünf Sicherheitslücken, allesamt in Produkten, die man eher aus dem Archiv kennt als aus dem Tagesgeschäft.

Dann kommt die eigentliche Frage. Nicht „Was ist das?“, sondern: Wo steht eigentlich unser Inventar? In der CMDB, die seit dem Umzug niemand mehr angefasst hat? In einer Excel-Datei? Im Export des eigenen Asset-Scanners? Taucht eines der fünf Produkte dort überhaupt auf? Wer hat die alte Microsite angelegt, wer das Strapi der Agentur – und welche Version läuft darauf? Ist das Ding aus dem Internet erreichbar?

Hand aufs Herz: Es gibt ja auch noch den Server, den „nur noch Klaus kennt“. Klaus, ebenfalls fiktiv, arbeitet längst an anderen Projekten. Der Server läuft trotzdem. Er läuft immer – ohne Vorfall, ohne Beschwerde, ohne Eintrag irgendwo.

Spoiler: Keine dieser fünf Lücken ist ein Patch-Problem. Fixes gibt es seit Jahren. Das Pikante daran: Genau deshalb sind sie heikel, denn sie stecken in Systemen, die aus jedem Patch-Zyklus gefallen sind, weil niemand sie mehr als „eigenes“ System kennt. Alt ist die Lücke, nicht der Patch.

Was CISA am 8. Oktober im KEV aufgenommen hat

Am Donnerstag, 8. Oktober, hat CISA genau fünf Schwachstellen in den Katalog „Known Exploited Vulnerabilities“ übernommen, kurz KEV. Die Katalogversion vom 8. Oktober zählt damit 1.739 Einträge. Den Katalog selbst finden Sie direkt bei CISA. Ein Blick lohnt, auch wenn Sie die Liste nur selten öffnen.

Zur Einordnung: „Aktiv ausgenutzt“ ist CISAs Einstufung. Laut CISA gelten alle fünf Sicherheitslücken als aktiv ausgenutzt; ein Wer, Wann oder Wo nennt CISA dazu nicht. Mehr steht da nicht, und mehr sollten wir nicht hineinlesen.

CISA führt eine Ransomware-Nutzung bei allen fünf Einträgen als „unbekannt“ (Unknown), ausdrücklich nicht als „keine“. Der Unterschied ist nicht kosmetisch.

Bunt gemischt ist die Auswahl: ein FTP-Server, ein DNS-Server, ein Java-Webframework, ein selbst gehosteter Online-Office-Server, ein Headless-CMS. Bei vier von fünf neuen Einträgen verlangt der Katalog im Feld „forensic triage“ eine forensische Triage. Bei ProFTPD, Struts, ONLYOFFICE und Strapi ja, bei BIND nein. Merken Sie sich das, wir kommen darauf zurück.

Die geforderte Maßnahme lautet bei allen fünf gleich, sinngemäß: Mitigationen nach Herstellerangaben anwenden, im Einklang mit BOD 26-04 und CISAs Anforderungen zur forensischen Triage. Gibt es keine Mitigationen, ist die Nutzung des Produkts einzustellen. Betreibende sind außerdem dafür verantwortlich, die Internet-Erreichbarkeit jedes Assets zu bewerten.

Dazu kommt ein allgemeiner Hinweis von CISA, der gern untergeht: Eine Lücke kann auch eine Open-Source-Komponente betreffen, die eingebettet in ganz verschiedenen Produkten steckt. Suchen Sie also nicht nur nach dem Produktnamen, sondern auch in Appliances, Images und fremden Produkten.

Alter der fünf Lücken bei KEV-Aufnahme am 8.10. (volle Jahre seit CVE-Veröffentlichung, dm-Rechnung)

1739Einträge im KEV-Katalog (Version vom 8.10.)
4Neue Einträge mit Pflicht zur forensischen Triage (für US-Bundesbehörden)

Fünf alte Sicherheitslücken im Kurzporträt

Keine Technikvorlesung, versprochen. Sie bekommen nur, was Sie für den Abgleich mit Ihrem Bestand brauchen. Die Klassen nennen wir so, wie CISA sie benennt – mehr Details gibt es hier bewusst nicht. Wer Sicherheitslücken dokumentiert, muss nicht erklären, wie sie funktionieren.

ProFTPD: der FTP-Server

ProFTPD ist ein Open-Source-FTP-Server. CVE-2015-3306, veröffentlicht am 18. Mai 2015, führt CISA als „Improper Access Control“ (CWE-284). Betroffen ist laut Projekt Version 1.3.5. Behoben wurde die Lücke laut Projekt-Changelog in 1.3.5a und 1.3.6rc1, beide vom 27. Mai 2015. Forensische Triage laut Katalog: ja.

ISC BIND: der DNS-Server

BIND ist ein DNS-Server und ein Projekt des Internet Systems Consortium (ISC). CVE-2015-5477, veröffentlicht am 29. Juli 2015, führt CISA als „Data Processing Errors“ (CWE-19); die Folge ist laut CISA ein Denial of Service. Laut ISC-Advisory vom 28. Juli 2015 betroffen sind 9.1.0 bis 9.8.x, 9.9.0 bis 9.9.7-P1 und 9.10.0 bis 9.10.2-P2. Gepatcht sind 9.9.7-P2 und 9.10.2-P3.

Laut ISC trifft es rekursive und autoritative Server, und laut ISC verhindern Zugriffslisten oder Konfigurationsoptionen die Exposition nicht. ISC rät, auf das gepatchte Release zu aktualisieren, das der eigenen Version am nächsten ist. Für 9.1 bis 9.8 nennt ISC keinen Patch; dort bleibt als Weg allein der Umstieg auf eine aktuelle, von ISC unterstützte Version. Forensische Triage laut Katalog: nein.

Apache Struts: das Java-Webframework

Struts stammt von der Apache Software Foundation. CVE-2016-3081, veröffentlicht am 26. April 2016, führt CISA als „Command Injection“ (CWE-77), laut CISA nur bei aktivierter „Dynamic Method Invocation“. Laut Apache-Sicherheitsbulletin S2-032 betroffen sind Struts 2.3.20 bis 2.3.28, ausgenommen 2.3.20.3 und 2.3.24.3. Der Fix steckt in 2.3.20.3, 2.3.24.3 oder 2.3.28.1.

Als Workaround nennt Apache, die Dynamic Method Invocation zu deaktivieren, wenn möglich. Apache stuft die Lücke als „Important“ ein. Forensische Triage laut Katalog: ja.

ONLYOFFICE Docs: der Online-Office-Server

ONLYOFFICE Docs ist ein selbst hostbarer Dokumentenserver. CVE-2021-3199, veröffentlicht am 22. Januar 2021, führt CISA als „Path Traversal“ (CWE-22); laut CISA kann das zu Remote Code Execution führen, also zur Codeausführung aus der Ferne. Der Fix steckt laut ONLYOFFICE-Changelog in Document Server 5.6.3, betroffen sind die Versionen davor. Forensische Triage laut Katalog: ja.

Meine Einordnung am Rand, ohne Zahl und ohne Behauptung über konkrete Behörden oder Betriebe: Selbst gehostete Office-Server passen gut zu Souveränitäts-Setups. Wer sie einmal aufgesetzt hat, vergisst sie gern.

Strapi: das Headless-CMS

Strapi ist ein Open-Source-Headless-CMS. CVE-2023-22894, veröffentlicht am 19. April 2023, führt CISA als „Cleartext Storage of Sensitive Information“ (CWE-312). Laut CISA setzt die Lücke Zugriff auf das Admin-Panel voraus. Laut CISA lässt sie sich mit CVE-2023-22621 verketten; am Ende steht Codeausführung aus der Ferne. Mehr dazu schreibe ich bewusst nicht.

Wichtig: CVE-2023-22621 steht selbst nicht im KEV-Katalog, CISA nennt sie nur als Verkettungspartner. Betroffen sind laut Strapi die Versionen ab 3.2.1 bis vor 4.8.0, der Fix kam ab 4.8.0 im März 2023. Für CVE-2023-22621 nennt Strapi Versionen bis 4.5.5 als betroffen, behoben in 4.5.6. Forensische Triage laut Katalog: ja.

Elf Jahre, zehn Jahre, drei Jahre: Wir haben nachgerechnet

Wir bei digital-magazin.de haben nachgerechnet. Basis sind die vollen Jahre zwischen der Veröffentlichung der CVE beim CVE-Programm und der KEV-Aufnahme am 8. Oktober:

ProFTPD: 11 Jahre
BIND: 11 Jahre
Struts: 10 Jahre
ONLYOFFICE: 5 Jahre
Strapi: 3 Jahre

Bitte lesen Sie das nicht als „elf Jahre ungepatcht“. Die Fixes sind ebenso alt wie die Sicherheitslücken. Bei ProFTPD datiert der Fix laut Projekt-Changelog auf den 27. Mai 2015 – neun Tage nach der CVE-Veröffentlichung, wie unsere Rechnung zeigt. Alt ist die Lücke, nicht der Patch.

Was sagt es also über Patch-Management, wenn eine elf Jahre alte, längst behobene Lücke laut CISA als aktiv ausgenutzt gilt? Meiner Einschätzung nach erstaunlich wenig über den Patch-Prozess und erstaunlich viel über das Inventar. Patch-Management arbeitet eine Liste ab. Was nicht auf der Liste steht, bekommt keinen Patch, keine Mail, kein Ticket.

Ehrlich gesagt: Das ist unbequemer als jede neue Sicherheitslücke. Gegen eine neue Schwachstelle hilft ein Update. Gegen ein System, das niemand mehr kennt, hilft nur Bestandsaufnahme – und die macht keinen Spaß.

Das Muster hinter diesen Sicherheitslücken ist übrigens kein technisches. Es ist ein organisatorisches. Irgendwann wurde ein Dienst eingerichtet, irgendwann ein Projekt abgeschlossen, irgendwann ein Team umgebaut. Der Dienst blieb. Die Erinnerung ging.

Strapi: gepatcht und trotzdem ohne Support

Der Strapi-Eintrag hat einen zweiten Boden. CISA schreibt dort, das betroffene Produkt könnte ohne Support sein („could be end-of-life“), und rät, die Nutzung einzustellen oder auf eine unterstützte Version zu wechseln. Die konkreten Daten kommen vom Projekt selbst.

Laut Strapi ist Strapi v3 seit dem 31. Dezember 2022 ohne Support. Strapi v4 hat laut Strapi-Dokumentation am 30. April 2026 das Ende seiner Lebensdauer erreicht. Version 4.26.2 vom 9. Juni 2026 ist das letzte v4-Release, weitere Updates gibt es nicht. Aktuelle Hauptversion ist Strapi 5. Details zu Ende und Migration finden Sie in der Strapi-Dokumentation zum Wechsel von v4 auf v5.

Das ist der Knackpunkt. Auch eine gepatchte v4 ist seit dem 30. April 2026 ohne Support. Unterstützt ist nur Strapi 5. Wer also brav auf 4.8.0 oder höher aktualisiert hat, steht trotzdem auf einem Stand, den das Projekt nicht mehr pflegt. Gepatcht und trotzdem verwaist – das gibt es.

Besonders heikel ist das bei Agenturprojekten. Das Projekt wurde abgenommen, die Rechnung bezahlt, das Team wurde umgesetzt. Wer pflegt jetzt das CMS? Mein Rat: Klären Sie das mit der Agentur schriftlich, bevor jemand fragt. Und planen Sie die Migration auf Strapi 5 ein, statt sie wegzuschieben.

Die US-Frist und was sie für Sie bedeutet

Das Fälligkeitsdatum aller fünf Einträge ist Sonntag, 11. Oktober – verbindlich nur für US-Bundesbehörden. Grundlage ist die Binding Operational Directive 26-04 („Prioritizing Security Updates Based on Risk“), datiert auf den 10. Juni 2026. Sie ersetzt BOD 22-01, die Richtlinie, mit der 2021 der KEV-Katalog eingeführt wurde, sowie BOD 19-02.

Zur Geltung: Die BOD ist verbindlich für die zivilen Bundesbehörden der US-Exekutive (Federal Civilian Executive Branch). Sie gilt nicht für „national security systems“, für Auftragnehmer nur, wenn der Vertrag es vorsieht. Für Unternehmen und Behörden in der DACH-Region ist sie nicht verbindlich. Orientierung, keine Pflicht.

Die Fristlogik ist dynamischer, als man denkt. Laut BOD hängen die Fristen ab von der Exposition (öffentlich erreichbar oder nicht), vom KEV-Status, von der Automatisierbarkeit der Ausnutzung und von der technischen Auswirkung. Wer ein System vom Internet nimmt, ändert damit die Einstufung und die Frist. Die Kategorie „& forensic triage“ bedeutet laut BOD: Behebung oder Mitigation innerhalb der Frist der Kategorie (drei Tage) und eine forensische Triage des Assets, „to assess whether the system is compromised“ – um zu bewerten, ob das System kompromittiert ist.

Brisant, aber leicht zu überlesen: Laut BOD sollen die Behörden alle von außen erreichbaren Assets fortlaufend identifizieren und taggen, nach Organisation, Umgebung, Exposition und Asset-Typ. Das ist ein Vorbild fürs eigene Inventar. Für DACH keine Pflicht, aber eine ziemlich gute Idee.

Plot Twist: Patchen reicht nicht

KEV: Zwei Administratoren gleichen im Serverraum eine Inventarliste mit dem offenen Rack ab — Inventur statt Überraschung (Symbolbild)

Stellen Sie sich vor, Sie schließen sorgfältig eine Tür. Neues Schloss, gute Arbeit. Nur: Wissen Sie, ob in der Zwischenzeit schon jemand im Haus war? Das Bild soll nichts über konkrete Systeme behaupten – es beschreibt die Lücke im Vorgehen. Wer patcht, ohne zu prüfen, ob etwas passiert ist, bleibt im Ungewissen.

Genau deshalb verlangt der Katalog bei vier von fünf Einträgen die forensische Triage. Nur bei BIND nicht. Für US-Bundesbehörden ist das Pflicht, für Sie eine sehr plausible Richtschnur. Aus meiner Sicht gilt: Wo ein Produkt jahrelang unbeobachtet lief und aus dem Internet erreichbar war, gehört die Prüfung zum Update dazu, nicht als Kür danach.

Wichtig ist die Reihenfolge der Entscheidungen. Ich skizziere sie als Prozess, nicht als Anleitung:

Zuerst klären Sie, ob das System aus dem Internet erreichbar ist, und wer es betreibt. Diese Entscheidung treffen die Verantwortlichen für das System gemeinsam mit der Security-Leitung.
Dann binden Sie Ihr Incident-Response-Team oder einen Dienstleister ein. Wer die Prüfung leitet, sollte vorab festgelegt sein, nicht erst, wenn es eilt.
Danach sichern Sie Zustand und Logs, bevor Sie patchen oder neu aufsetzen.
Anschließend prüfen Sie die Integrität des Systems.
Erst dann folgen Update, Migration oder Abschaltung – und die Rotation der Zugangsdaten.

Warum zuerst sichern? Weil ein Neuaufsetzen den Zustand überschreibt, den Ihr Team oder Ihr Dienstleister später bewerten müsste. Was weg ist, lässt sich nicht mehr beurteilen. Das gilt auch für die Frage, ob Zugangsdaten bereits abgeflossen sein könnten – ohne gesicherte Grundlage bleibt die Antwort Raten.

Ebenso wichtig: Dokumentieren Sie jeden Schritt. Wer entschieden hat, was geprüft wurde, wann und mit welchem Ergebnis – das gehört in ein Protokoll, das auch später noch jemand versteht. Aus meiner Sicht ist das ein oft unterschätzter Teil. Eine saubere Dokumentation hilft bei Rückfragen der Geschäftsleitung, bei Audits und beim nächsten System, das in dieselbe Lage gerät.

Mehr Technik gibt es hier mit Absicht nicht. Wie eine solche Prüfung im Detail aussieht, entscheidet das Team, das sie durchführt. In unserer KEV-Serie auf digital-magazin.de haben wir den Prozess schon mehrfach beschrieben: etwa bei Perimeter-Geräten von Check Point, Arista und F5, wo BOD 26-04 und die Prüfung vor dem Patch im Mittelpunkt stehen, und bei Citrix NetScaler, wo es um die forensische Triage geht.

Und BIND? Dort verlangt CISA keine Triage. Wer einen alten BIND-Server betreibt, spart sich die Prüfung trotzdem nicht aus Prinzip. Es bleibt eine Entscheidung Ihres Teams. Das System hat dann zumindest eine bewusste Antwort verdient, nicht bloß ein Upgrade.

Inventar ist Sicherheitsarbeit

Am 1. Oktober stand es schon in unserem Text zu Cisco SD-WAN im KEV: Ohne Inventar ist der Umgang mit Sicherheitslücken Hoffnung. Die fünf neuen Einträge liefern das Anschauungsmaterial dazu. Hoffnung ist kein Prozess.

Wo verstecken sich die Kandidaten? Die Liste ist kurz, aber unbequem:

Appliances: Ein FTP- oder DNS-Dienst steckt oft in einer Box, die man nie als Server betrachtet hat. Sie steht im Rack, hat eine Seriennummer, aber keinen Eintrag im Patch-Plan.
Container-Images: Ein Image wurde einmal gebaut und seitdem weiterverwendet. Welche Version darin steckt, weiß nur, wer nachsieht.
Agentur-Übergaben: Das CMS aus dem abgeschlossenen Projekt läuft weiter, die Zuständigkeit nicht. Im Übergabeprotokoll steht „Betrieb beim Kunden“, auf Kundenseite fühlt sich niemand zuständig.
Testsysteme: Das „nur mal kurz“ aufgesetzte System mit echten Daten. Es überlebt jeden Projektabschluss.
Self-Hosting: Selbst betriebene Dienste wie ein Dokumentenserver brauchen Pflege, die niemand im Projektplan hatte.
Eingebettete Komponenten: Die Open-Source-Komponente in einem fremden Produkt taucht in keiner Asset-Liste unter ihrem eigenen Namen auf.

Mal ehrlich: Wie viele dieser Systeme haben bei Ihnen eine namentlich benannte verantwortliche Person? Eben. Ohne Verantwortliche gibt es keinen Patch-Zyklus, keine Entscheidung zum Abschalten und keine Ansprechperson, wenn etwas auffällt.

Wer übernimmt Verantwortung? Meiner Einschätzung nach muss die Antwort eine Person sein, kein Team-Postfach und kein „die IT“. Fachbereiche, die ein System angefordert haben, tragen die Entscheidung mit. Die IT-Leitung führt das Inventar. Die Security-Verantwortlichen prüfen, ob es stimmt. Geht ein System bei einer Übergabe an Dritte, gehört der Name der betreuenden Person dazu – und das Datum, bis zu dem sie zuständig ist.

Wer mit der Bestandsaufnahme erst beginnt, findet im Ratgeber zur digitalen Inventarisierung für KMU auf digital-magazin.de einen pragmatischen Einstieg. Perfekt muss das Inventar nicht sein. Es muss existieren und gepflegt werden.

Checkliste für Ihre eigenen Systeme

Alles Folgende betrifft ausschließlich Systeme, für die Sie selbst verantwortlich sind. Keine Scans fremder Systeme, keine Experimente.

Prüfen Sie im Inventar, ob die fünf Produkte in CMDB, SBOM, Container-Images, Appliances oder Agenturprojekten auftauchen – auch eingebettet in andere Produkte.
Gleichen Sie die Version mit den Angaben der Projekte ab, etwa über Paketmanager, Image-Tag, Versionsanzeige oder Abhängigkeitsliste.
Prüfen Sie die Exposition nur mit eigenen Mitteln: Firewall-Regeln, Reverse-Proxy-Konfiguration, Asset-Liste. Keine Internet-Scans, keine Suchdienste für offene Dienste.
Patchen oder aktualisieren Sie nach den Angaben der Projekte. Bei Struts nennt Apache als Workaround, die Dynamic Method Invocation zu deaktivieren, wenn möglich.
Bei Strapi gilt: v3 und v4 sind ohne Support. Mein Rat: Planen Sie die Migration auf Strapi 5 und halten Sie das Admin-Panel bis dahin nicht öffentlich erreichbar.
Ist kein Fix möglich, rät CISA, die Nutzung einzustellen. Mein Rat für alles, was bleiben muss: vom Netz nehmen oder segmentieren.
Planen Sie die Kompromittierungsprüfung als Prozess (bei vier von fünf verlangt CISA sie von US-Behörden): IR-Team oder Dienstleister einbinden, Zustand und Logs vor dem Neuaufsetzen sichern, Integrität prüfen, Zugangsdaten rotieren.
Geben Sie jedem System eine verantwortliche Person. Systeme ohne Verantwortliche sind aus meiner Sicht Abschalt-Kandidaten. Pflegen Sie das Inventar laufend; das BOD-26-04-Tagging ist dafür ein Vorbild, aber keine Pflicht.

Zurück zu 16:40 Uhr

Noch einmal zu unserer fiktiven IT-Leiterin. Es ist inzwischen kurz nach 18 Uhr. Sie hat keinen Vorfall gefunden, sondern etwas Unspektakuläreres: Kandidaten. Ein Dokumentenserver, den ein Fachbereich einmal angefordert hat. Das Strapi der Agentur, Version unklar.

Die Inventur-Lage ist ernüchternd, aber nützlich. Die CMDB kennt den Dokumentenserver nur unter einem Projektnamen, der längst nicht mehr existiert. Die Excel-Liste einer Abteilung nennt ein Testsystem, bei dem als Verantwortlicher ein ausgeschiedener Kollege steht. Im Export des Asset-Scanners tauchen zwei Einträge ohne Beschreibung auf. Und bei der Microsite fehlt schlicht jeder Eintrag.

Sie weist Verantwortliche zu. Sie schreibt der Agentur und fragt nach Version, Betrieb und Zuständigkeit. Sie plant mit dem IR-Dienstleister eine Prüfung, bevor irgendetwas aktualisiert wird, und legt fest, wer was entscheidet. Und sie ruft Klaus an.

Klaus geht beim zweiten Klingeln ran. Er weiß, wo der Server steht. Er weiß nur nicht mehr, wofür.

Was bleibt?

Offen gesagt: Die fünf Einträge sind für mich weniger eine Warnung vor neuer Technik als ein Spiegel. Sie zeigen, was im eigenen Bestand vergessen wurde. Wer die Liste liest und sofort weiß, wo die Systeme stehen, wer sie betreut und ob sie erreichbar sind, hat seine Hausaufgaben gemacht. Wer erst suchen muss, hat die eigentliche Aufgabe gefunden.

Meiner Einschätzung nach wird die nächste KEV-Ergänzung dieselbe Frage stellen, nur mit anderen Produktnamen. Patchen können die meisten. Wissen, was man patchen muss – das ist die Kunst. Und dann prüfen, ob die Tür nicht schon vorher offen stand.

Alt ist die Lücke, nicht der Patch.