CISA KEV: Check Point, Arista, F5 – Due Date 25.9. und BOD 26-04 will Pre-Compromise

Vier Perimeter-Schwachstellen landen am 22.9. im CISA-KEV-Katalog – Check Point, Arista VeloCloud, F5 BIG-IP APM –, Due Date 25.9., Forensic Triage laut BOD 26-04: Yes. Der Plot Twist: Ein Ticket „Patch beim nächsten Maintenance“ repariert keine Pre-Compromise.

Wer den Katalog der Known Exploited Vulnerabilities nur als weitere Warteschlange neben dem Scanner-Backlog behandelt, verpasst den Clou. CISA hat am 22.9. vier aktiv ausgenutzte Schwachstellen nachgelegt – allesamt am Netzwerkrand, allesamt mit Evidenz aktiver Ausnutzung, allesamt mit einer harten Frist: 25.9. Und laut KEV-Katalog bzw. den CISA Required Action Notes gilt für diese Einträge unter BOD 26-04: Forensic Triage – Yes.

Das ist wenig überraschend, wenn man die letzten Jahre am Edge verfolgt hat. VPN-Gateways, SD-WAN-Orchestratoren und Access-Policy-Manager sind nicht „noch ein Asset in der CMDB“. Sie sind die Tür. Wer sie nach dem Exploit kontrolliert, kontrolliert oft den Rest. Genau deshalb fordert BOD 26-04 für FCEB-Organisationen – und ermutigt alle anderen Organisationen ausdrücklich dazu –, hochriskante KEV-Einträge auf öffentlich erreichbaren Assets zu priorisieren, die nach erfolgreicher Ausnutzung totale Kontrolle ermöglichen können. Vor dem Patch: Kompromittierung prüfen. Nach dem Patch: wieder prüfen. Der Scanner darf danach grün sein. Die Geschichte ist damit nicht zu Ende.

Wir bei digital-magazin.de haben diese Geschichte schon mehrfach erzählt – und sie endet selten mit dem Ticket-Status „Closed“. Wer die aktuelle Lage einordnen will, findet den roten Faden unter anderem in unserer Spur zu VPN-Gateways unter Beschuss und in der Einordnung, wie CISA den KEV-Katalog immer wieder um Perimeter-Einträge erweitert. Heute geht es um vier konkrete CVEs, um das Due Date 25.9. und um den brisanten Punkt, den viele Change-Kalender systematisch unterschätzen: Pre-Compromise.

Was CISA am 22.9. in den KEV-Katalog gelegt hat

Die offizielle Meldung steht im CISA-Alert vom 22.9.: Vier Known Exploited Vulnerabilities, Evidenz aktiver Ausnutzung, Aufnahme in den Katalog. Die Kurzfassung in Tabellenform – ohne Exploit-Details, ohne Rezepte, ohne „so knacken Sie X“:

Der Katalog selbst ist die lebende Quelle der Wahrheit: CISA Known Exploited Vulnerabilities Catalog (cisa.gov/known-exploited-vulnerabilities-catalog). Wer nur den Alert liest und den Katalog nie öffnet, verpasst Required-Action-Notizen, Due Dates und die Forensic-Triage-Kennzeichnung. Das ist der Unterschied zwischen „wir haben die CVE gesehen“ und „wir behandeln sie als KEV“.

Vier Einträge, ein Alert, ein gemeinsamer Nenner: Perimeter. Check Point am VPN- und Management-Rand. Arista VeloCloud als Orchestrator für SD-WAN. F5 BIG-IP APM dort, wo Access Policy und OAuth zusammentreffen. Wer hier „normale CVE-Queue“ spielt, priorisiert falsch – und das ist die These dieses Textes.

BOD 26-04, Forensic Triage und warum 25.9. keine Suggestion ist

Binding Operational Directive 26-04 richtet sich an Föderal-zivile Executive Branch Agencies. Der Kern, der auch außerhalb der US-Bundesverwaltung brisant bleibt: Hochriskante KEV-Schwachstellen auf öffentlich exponierten Assets, die nach Ausnutzung totale Kontrolle erlauben können, gehören nach vorne. Nicht hinter das nächste Wartungsfenster. Nicht hinter das Quartals-Release. Nicht hinter das Ticket „sobald der Change Board nickt“.

Laut KEV-Katalog bzw. CISA Required Action Notes gilt für diese vier Einträge: Forensic Triage – Yes. Übersetzt in die Sprache derjenigen, die nachts den Pager tragen: Bevor Sie den Patch als „erledigt“ abhaken, prüfen Sie, ob das Asset bereits vor dem Fix kompromittiert wurde. Danach prüfen Sie erneut. Der Patch schließt die Tür. Er räumt niemanden aus, der schon drinnen steht.

Das Due Date 25.9. ist damit kein Marketing-Datum. Es ist die Frist, an der sich zeigt, ob eine Organisation KEV als Prioritätssystem versteht – oder als zusätzliche Spalte im Vulnerability-Management-Tool, die irgendwann grün wird. Wir bei digital-magazin.de sehen in solchen Fristen immer denselben Konflikt: Betriebsstabilität versus Edge-Realität. Stabilität ohne ehrliche Pre-Compromise-Prüfung ist eine Illusion mit schönem Ticket-Status.

BOD 26-04 ermutigt ausdrücklich alle Organisationen, denselben Maßstab anzulegen. Das ist der Clou für Unternehmen, die „wir sind ja keine FCEB“ als Ausrede nutzen wollen. Der Angriffsraum am Perimeter unterscheidet nicht nach Behördenstatus. Ein öffentlich erreichbares VPN-Gateway oder ein SD-WAN-Orchestrator, der privilegierten Zugriff eröffnet, ist privilegiert – Punkt.

Check Point: Zwei KEVs, Vendor-Fixes, keine Exploit-Erzählung

Check Point hat am 22.9. selbst nachgelegt: Im Security-Advisory-Blog von Check Point steht die defensive Kernbotschaft klar – aktive Ausnutzung beider Schwachstellen, Fixes verfügbar, sofort handeln. Was folgt, bleibt bewusst hochlevel und verteidigungsorientiert.

CVE-2026-85102 betrifft laut CISA und Vendor-Kommunikation eine unsachgemäße Zertifikatsvalidierung im Kontext der VPN-Verhandlung. CISA führt den Eintrag als Improper Certificate Validation; der Vendor beschreibt unauthentifizierte Remote Code Execution mit CVSS 9.8 und nennt betroffene Produktlinien im Umfeld Gateway/Spark. Der Fix für 85102 ist laut Check Point seit dem 9.9. verfügbar. Der defensive Zeigefinger zeigt auf die Support-Knowledgebase: SK sk1000117. Installieren Sie die Vendor-Fixes. Punkt. Keine Zertifikat-Subject-Listen hier, keine CN-Wiederholungen, keine Rezepte.

CVE-2026-93616 betrifft laut denselben Quellen eine Path-Traversal-Schwachstelle im Management-Webservice – pre-auth, CVSS 9.8. Der Fix ist mit dem Advisory verfügbar; SK sk1000171 ist der Vendor-Pointer. Ein Detail aus dem Blog ist für Change-Manager pikant und wenig überraschend zugleich: LivePatch Take 28/29 adressiert 93616 nicht. Wer glaubt, „wir haben LivePatch ohnehin“ reiche als Remediierung, hat den Spoiler verpasst.

Defense-First, wie Check Point es skizziert und wie wir es hier wiederholen: Vendor-Fixes unverzüglich einspielen. Logs auf anomale zertifikatsbasierte Mobile-Access-Anmeldungen prüfen – ohne Subject-Listen nachzudrucken. Den SK-Artikeln für IoC-Hinweise und Hunting folgen. Wer tiefer in die Vendor-Dokumente muss, geht über support.checkpoint.com zu sk1000117 und sk1000171 – als Pointer, nicht als Exploit-Anleitung.

Das Szenario am Edge ist greifbar: Ein VPN-Gateway, das Homeoffice und Partnerzugänge trägt, steht öffentlich. Die Management-Ebene ist oft „nur intern“ – bis sie es nicht mehr ist. Path Traversal pre-auth und fehlerhafte Zertifikatsvalidierung in der Verhandlung sind genau die Art Labels, die CISA nicht aus Langeweile in den KEV-Katalog schreibt. Die Überraschung für viele Teams: Das Ticket für den nächsten Maintenance-Slot war schon angelegt, bevor der Alert kam. Der Alert ändert die Priorität. Das Ticket ändert sie oft nicht.

Arista VeloCloud Orchestrator: Vendor-Advisory folgen, keine Versionsfantasie

CVE-2026-93952 betrifft den Arista VeloCloud Orchestrator (VCO). CISA labelt Improper Input Validation. Aus sekundären und intel-nahen Einordnungen – und das bleibt hier bewusst vorsichtig formuliert – kann unsachgemäße Eingabevalidierung Remote-Zugriff auf privilegierte interne Funktionalität eines On-Prem-VCO ermöglichen. Hosted- und Dedicated-Varianten wurden laut verfügbaren Hinweisen bereits durch den Vendor gepatcht. Für On-Prem gilt die klare Linie: Vendor-Advisory folgen.

Wir erfinden hier keine Package-Versionen. Wir zitieren keine Versionslisten, die nicht klar aus dem Vendor-Advisory stammen. Wer konkrete Build-Nummern braucht, öffnet das Arista Security Advisory zu CVE-2026-93952 (u. a. im Umfeld von Advisory 0183, sofern dort vom Vendor geführt) und arbeitet ausschließlich danach. Alles andere ist Gerücht mit CVE-ID.

Der SD-WAN-Orchestrator ist der Plot Twist vieler Netzarchitekturen: Er orchestriert Edges, Policies, Tunnel. Wer den Orchestrator kontrolliert, orchestriert mehr als „nur ein Management-UI“. Deshalb gehört VCO On-Prem in dieselbe Inventarliste wie das VPN-Gateway – öffentlich erreichbar oder über Admin-Pfade erreichbar, privileged by design. Reduce Exposure heißt hier: Management-Pfade härten, Erreichbarkeit prüfen, Vendor-Fix einspielen, vor und nach dem Patch forensisch triageieren.

Wer in den letzten Monaten die KEV-Welle um Fortinet und VeloCloud verfolgt hat, kennt das Muster. Unsere Einordnung dazu liegt unter anderem hier: Zwei KEVs, Fortinet, VeloCloud – Admins nicht wegducken. Heute ist VeloCloud wieder im Katalog – und das Due Date ist 25.9.

F5 BIG-IP APM: Heap Overflow nur im OAuth-Authorization-Server-Setup

CVE-2026-94127 betrifft F5 BIG-IP APM. CISA labelt Heap-based Buffer Overflow. Hochlevel und ohne Reproduktionspfad: Die Schwachstelle greift, wenn eine APM-Access-Policy und ein OAuth-Profil auf dem Virtual Server konfiguriert sind – und zwar dann, wenn APM als OAuth Authorization Server betrieben wird. Unauthentifizierte Remote Code Execution ist laut den verfügbaren Labels möglich. Das Due Date im KEV-Kontext: 25.9.

Remediation-Pointer, nichts weiter: Folgen Sie dem F5-Artikel K000162605. Vendor-Hotfixes sind der Weg. Als Interim für die Forensic-Triage-Phase verweist F5 auf temporäre Maßnahmen über den Support (u. a. iRule-Hinweise) – hier ausdrücklich nur als Vendor-Pointer erwähnt, ohne iRule-Inhalt, ohne Nachbau, ohne technische Reproduktion.

Die Inventarfrage ist hier der Clou: Haben Sie BIG-IP-Instanzen, auf denen APM als OAuth Authorization Server läuft? Wenn nein, priorisieren Sie ehrlich anders – aber verifizieren Sie die Konfiguration, statt sie zu vermuten. Wenn ja, stehen Sie im KEV-Fenster. Scanner-Green ohne Konfigurations-Check ist Theater.

Plot Twist: „Patch next maintenance“ ist keine Pre-Compromise-Remediation

Hier sitzt die Überraschung, die viele Change-Boards nicht auf der Agenda haben. Ein Ticket mit dem Titel „Patch beim nächsten Maintenance-Fenster“ adressiert die Schwachstelle in der Zukunft. Es adressiert nicht die Frage, ob das Asset bereits kompromittiert wurde. KEV mit Forensic Triage = Yes bedeutet: Diese Frage ist Teil der Required Action – nicht optionaler Bonus für besonders motivierte IR-Teams.

Szenario, absichtlich nüchtern: Edge auf dem VPN-Gateway oder dem SD-WAN-Orchestrator. Öffentlich erreichbar. Privilegien nach erfolgreicher Ausnutzung: hoch bis total. Das Wartungsfenster liegt in zehn Tagen. Das Due Date liegt am 25.9. Das Ticket ist „in Progress“. Der Scanner zeigt nach dem geplanten Patch hoffentlich grün. Was der Scanner nicht zeigt: Sessions, Persistenz, laterale Spuren, anomale Admin-Zugriffe, Zertifikatsanomalien, Orchestrator-API-Aufrufe außerhalb der Baseline.

Der Spoiler lautet deshalb: Remediierung ohne Pre-Compromise-Check ist unvollständig. Remediierung ohne Post-Patch-Check ist unvollständig. Remediierung, die nur die CVE-ID schließt und die Kompromittierungsfrage offen lässt, ist ein Statuswechsel im Tool – kein Sicherheitszustand.

Das ist brisant, weil es Organisationskultur trifft. Vulnerability Management und Incident Response sind in vielen Häusern getrennte Welten. KEV mit Forensic Triage zwingt sie zusammen. Wer das ignoriert, priorisiert den Perimeter falsch – und behandelt KEV wie normale CVE-Queues. Genau das ist die Fehleinschätzung, die dieser Text angreift.

Hier wiederholen wir das bewusst: Lifecycle schlägt Scanner-Green. Inventar, Exposure, Vendor-Fix, Triage before/after, ehrliches Due-Date-Handling – in dieser Reihenfolge, nicht in der Reihenfolge „was der Scanner zuerst gefunden hat“.

Warum KEV ≠ normale CVE-Warteschlange

Normale CVE-Queues sortieren nach CVSS, nach Asset-Klasse, nach Patch-Fenster, nach Business Owner. Das ist legitim für den Alltag. KEV ist kein Alltag. KEV bedeutet: Evidenz aktiver Ausnutzung. KEV am Perimeter mit totaler Kontrolle post-exploitation bedeutet: Das Asset ist kein Backlog-Item, sondern ein laufendes Risiko mit Kalenderdatum.

Vier CVEs in einem Alert erzeugen den falschen Reflex „wir nehmen die schwerste zuerst und den Rest nächste Woche“. BOD 26-04 und das gemeinsame Due Date 25.9. sagen etwas anderes: Alle vier gehören in denselben Prioritätskorb, sofern sie in Ihrem Inventar existieren und exponiert sind. Existenz prüfen. Exposure prüfen. Dann fixen. Dann triageieren.

Wer Zero-Day- und Advisory-Dynamik am Edge schon länger beobachtet, sieht die Kontinuität: Zero-Day, Exploit, CISA Advisory – kritisch ist kein Einzelstück, sondern ein Modus. Der Modus heißt: CISA labelt, Vendor patched, Organisationen zögern, Angreifende nicht.

Die pikante Wahrheit für Security-Leads: Ein grüner Scan nach dem Patch ist notwendig und unzureichend. Notwendig, weil ungepatchte KEVs am Edge unverantwortlich sind. Unzureichend, weil der Katalog „Forensic Triage: Yes“ nicht aus Versehen gesetzt wurde.

Defense-Checkliste: Inventar, Vendor, Exposure, Before/After, Due-Date-Ehrlichkeit

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptSecurity operations desk with firmware update checklist paper and closed laptop, pre-compromise review mood, photorealistic, no logos, no brand names, no readable text, 16:9

Kein Playbook zum Angreifen. Kein Overflow-How-to. Keine OAuth-Bastelanleitung. Nur Verteidigung – in einer Reihenfolge, die zum Szenario passt.

1. Perimeter inventarisieren. Welche Check-Point-Gateways/Spark-Instanzen stehen wo? Welche Management-Dienste sind erreichbar? Welche VeloCloud-Orchestratoren laufen On-Prem – und wer kann sie erreichen? Welche BIG-IP-APM-Instanzen betreiben OAuth Authorization Server zusammen mit Access Policy auf dem Virtual Server? Wer diese Fragen nicht beantworten kann, kann das Due Date nicht ernsthaft managen.

2. Vendor-Advisory folgen – nicht Gerüchten. Check Point: Blog vom 22.9., SK sk1000117, SK sk1000171, Fixes unverzüglich. Arista: Security Advisory zu CVE-2026-93952, keine erfundenen Versionen. F5: K000162605, Hotfixes, Interim nur über Vendor-Support-Hinweise. Ein Secondary-Blog ersetzt kein Vendor-Dokument.

3. Exposure reduzieren, wo der Fix noch nicht sitzt. Management-Interfaces nicht breiter exponieren als nötig. Admin-Pfade härten. Temporäre Vendor-Maßnahmen nur nach Vendor-Dokumentation. Reduce Exposure ist kein Ersatz für den Patch – aber es kauft Zeit für ehrliche Triage. Zeit, die am 25.9. knapp wird.

4. Pre-Compromise prüfen – before patch. Logs, Anomalien, zertifikatsbasierte Mobile-Access-Muster (ohne Subject-Listen zu reproduzieren), Orchestrator-Zugriffe außerhalb der Baseline, APM/OAuth-Auffälligkeiten. Den SK- und K-Artikeln für Hunting-Hinweise folgen. Wenn IR-Kapazität fehlt: eskalieren, nicht aussitzen.

5. Patchen – dann erneut prüfen. Post-Patch ist nicht „Ticket schließen“. Post-Patch ist zweite Triage. Persistenzfragen bleiben offen, bis jemand sie bewusst schließt. Der Change ist erst fertig, wenn Fix und Triage dokumentiert sind.

6. Due Date ehrlich behandeln. 25.9. ist die Frist im Katalog. Wer sie reißt, sollte wissen warum – und das Risiko gegenüber Geschäftsführung und IR klar benennen. „Nächstes Maintenance“ ist eine Betriebsentscheidung, keine Sicherheitsäquivalenz zum KEV-Due-Date.

Diese Liste ist absichtlich langweilig. Langweilig ist hier ein Feature. Dramatik gehört in den Alert, nicht in die Ausführung. Die Ausführung braucht Inventarlisten, Vendor-Links, Change-Fenster, die sich dem Due Date beugen, und IR-Slots vor und nach dem Patch.

Das Edge-Szenario ohne Heldengeschichte

Stellen Sie sich kein Hollywood-Skript vor. Stellen Sie sich ein VPN-Gateway vor, das seit Jahren stabil läuft, und einen SD-WAN-Orchestrator, den drei Personen administrieren. Am 22.9. erscheinen vier KEVs. Am 25.9. ist Due Date. Dazwischen liegt ein Wartungsfenster, das „schon immer“ am Monatsende lag.

Die Heldengeschichte wäre: Team patched in 48 Stunden, Triage clean, alles gut. Die reale Geschichte ist oft: Abhängigkeiten, Zertifikats-Chains, Change Freezes, fehlende Testumgebung für den Orchestrator, Unsicherheit, ob APM wirklich als OAuth Authorization Server konfiguriert ist. Genau deshalb zählt Inventar vor Heroismus.

Wer parallel noch die Homeoffice-VPN-Debatte im Hinterkopf hat – Code Execution am Edge, Advisory-Druck, operative Trägheit –, landet bei derselben Moral ohne Moralkeule: Der Perimeter verzeiht Warteschlangen-Denken schlecht. Unsere Spur dazu: Zero-Day-VPN und kritische Code Execution gehören in denselben Reflex wie KEV-Due-Dates, nicht in denselben Backlog wie mittlere Library-CVEs.

Interne Leser:innen-Spur und was wir bewusst weglassen

Dieser Text lässt aus, was viele klicken wollen und was hier verboten ist: Angriffsanleitungen, Reproduktionsdetails und Bastelanleitungen jeglicher Art. Wir drucken keine Zertifikat-Subject-Listen nach. Wir erfinden keine Package-Versionen. Wer das sucht, sucht am falschen Ort – und macht sich angreifbar auf eine Weise, die kein Magazin reparieren sollte.

Was wir liefern: CISA-Labels, Due Date 25.9., BOD 26-04 Forensic Triage Yes, Vendor-Pointer, Inventar- und Exposure-Logik, Pre-/Post-Compromise-Disziplin. Das reicht, um zu handeln. Mehr wäre Angriffshilfe – und die schreiben wir nicht.

Für den roten Faden im Haus: KEV-Erweiterungen, VPN unter Beschuss, Fortinet/VeloCloud-KEVs, Zero-Day-Advisory-Dynamik. Die Links im Fließtext und die nackten URLs dazwischen sind Absicht – Lesepfade, keine Dekoration.

Was Security-Leads ihren Change Boards sagen sollten

Formulieren Sie es ohne Panik und ohne Absolute. Sinngemäß: Vier aktiv ausgenutzte Perimeter-Schwachstellen stehen im KEV-Katalog. Due Date 25.9. Forensic Triage laut Katalog: Yes. Unser Inventar zeigt folgende betroffenen Systeme. Vendor-Fixes sind verfügbar bzw. folgen dem jeweiligen Advisory. Wir prüfen Kompromittierung vor und nach dem Patch. Das Maintenance-Ticket allein erfüllt die Required Action nicht.

Das ist die Sprache, die Boards verstehen: Datum, Scope, Abhängigkeit, Risiko, Nachweis. Nicht: „Es ist kritisch, bitte schnell.“ Kritisch ohne Inventar ist Lärm. Inventar ohne Due-Date-Plan ist Verdrängung.

Pikant bleibt die Organisationsfrage: Wer besitzt das VPN-Gateway betrieblich – und wer besitzt die Kompromittierungsfrage? Wenn beide Antworten auf unterschiedliche Teams zeigen und niemand den Handshake orchestriert, entsteht genau die Lücke, in die KEV-Fristen fallen.

Check Point, Arista, F5 – drei Vendor-Welten, ein Prioritätskorb

Unterschiedliche Produkte, unterschiedliche Fixes, dieselbe KEV-Logik. Check Point liefert Blog plus SK-Artikel und betont aktive Ausnutzung beider CVEs; LivePatch-Takes ersetzen den Fix für 93616 nicht. Arista verlangt Advisory-Treue ohne Versionsfantasie, besonders On-Prem VCO. F5 verlangt Konfigurationswahrheit (APM als OAuth Authorization Server?) und den Weg über K000162605.

Der gemeinsame Nenner ist langweilig und entscheidend: Vendor-Dokumentation schlägt Secondary-Zusammenfassung. Secondary darf warnen und einordnen. Secondary darf keine Versionsnummern erfinden. Secondary darf keine Exploit-Pfade nachzeichnen. Wir halten uns daran.

Und noch einmal der Plot Twist für die Ticket-Queue: Ein grüner Eintrag nach dem Patch beweist den Patch. Er beweist nicht die Abwesenheit einer Pre-Compromise. BOD 26-04 und die Katalognotiz Forensic Triage Yes existieren, weil diese Unterscheidung in der Praxis ständig kollabiert.

Zeitdruck ohne Panikmodus

25.9. ist nah, wenn Sie diesen Text am 23.9. lesen. Nähe erzeugt schlechte Abkürzungen: Patch ohne Backup-Plan, Patch ohne Log-Review, Patch ohne zu wissen, welche Instanz wirklich betroffen ist. Die bessere Abkürzung ist brutal simpel: Zuerst Inventar der vier CVE-Bereiche, dann Exposure-Triage, dann Vendor-Fix-Pfade parallel öffnen, dann IR für Before/After einplanen, dann Change beschleunigen – nicht umgekehrt.

Wer „wir patchen alles am Wochenende“ sagt, ohne die OAuth-APM-Frage und die VCO-On-Prem-Frage und die Check-Point-Management-Erreichbarkeit geklärt zu haben, patcht Theaterkulissen. Theaterkulissen werden in KEV-Postmortems unfreundlich erwähnt.

Wir bei digital-magazin.de schreiben das in Sie-Form, weil die Entscheidung bei Ihnen liegt – bei denjenigen, die Inventarliste und Change-Kalender tatsächlich bewegen. Genderneutrale Partizipien ändern nichts an der Härte der Frist. Die Frist bleibt 25.9.

Was „Erfolg“ in diesem Fenster heißt

Erfolg heißt nicht „keine CVE mehr im Scan“. Erfolg heißt: Betroffene Perimeter-Assets sind bekannt. Vendor-Fixes sind eingespielt oder der Abweichungsgrund ist dokumentiert und risikoführend eskaliert. Pre-Compromise-Checks sind gelaufen. Post-Patch-Checks sind geplant oder gelaufen. Exposure ist reduziert, wo nötig. Das Due Date wurde ernst genommen – auch wenn es wehtut.

Misserfolg trägt oft einen freundlichen Namen: „Scheduled for next maintenance.“ Freundliche Namen sind der Feind ehrlicher KEV-Arbeit. Der Katalog ist nicht freundlich. Aktive Ausnutzung ist nicht freundlich. BOD 26-04 ist nicht freundlich. Ihre Ticket-Betreffzeile sollte das widerspiegeln.

Noch ein Spoiler zum Schluss dieses Abschnitts – keine Schlussformel, nur eine Kante: Wenn Ihr Prozess KEV und normale CVEs in dieselbe Swimlane legt, haben Sie keinen KEV-Prozess. Sie haben eine Swimlane mit einem zusätzlichen Tag.

Lesen, verlinken, handeln – in dieser Reihenfolge

Extern, bewusst begrenzt: der CISA-Alert vom 22.9., der Check-Point-Blog vom 22.9., der F5-Artikel K000162605 – der KEV-Katalog bleibt die Referenzquelle ohne Extra-Tab. Intern: VPN-Gateways unter Beschuss, Fortinet/VeloCloud-KEVs, KEV-Katalog-Erweiterungen, Zero-Day-VPN, CISA-Advisory-Spuren. Drei bis vier Fließtext-Links, nackte URLs als Lesepfade – Absicht, kein Zufall.

Handeln heißt: Inventar öffnen. Vendor-Tabs öffnen. IR anpingen. Change beschleunigen. Triage before/after. Due Date 25.9. nicht schönreden.

Der Clou bleibt stehen, auch ohne Schlussformel: Wer KEV wie normale CVE-Queues behandelt, priorisiert den Perimeter falsch. Pre-Compromise und Lifecycle schlagen Scanner-Green. Das Ticket „patch next maintenance“ ist ein Termin. Es ist keine Remediation einer bereits erfolgten Kompromittierung – und genau dort trennt BOD 26-04 die Sorgfältigen von den Optimistischen.

Optimismus am Edge hat in den letzten Jahren selten die bessere Bilanz geliefert. Sorgfalt schon. Sorgfalt sieht aus wie Listen, Vendor-Links, Log-Reviews und unbequeme Termine vor dem 25.9. Wenig Glamour. Viel Substanz. Genau richtig für vier KEVs, die nicht warten.

Wenn Sie nur eine Sache aus diesem Text mitnehmen: Öffnen Sie den Katalog-Eintrag, lesen Sie Due Date und Forensic Triage, legen Sie Inventar und IR parallel, folgen Sie dem Vendor – und lassen Sie das Maintenance-Ticket nicht die Geschichte erzählen, die nur eine Pre-Compromise-Prüfung erzählen kann.

Vier CVEs. Ein Alert. Ein Due Date. Ein Plot Twist. Der Rest ist Handwerk – verteidigend, inventarisierend, vendor-treu, ohne Exploit-Folklore und ohne die Illusion, dass Grün im Scanner gleich sauber am Edge bedeutet.