Zwei Einträge, ein Tag im KEV-Katalog, zwei Hersteller mit Symbolkraft in jedem Firmennetz. Die CISA hat am 27. Juli 2026 CVE-2025-68686 in Fortinet FortiOS und CVE-2026-16812 im Arista-VeloCloud-Orchestrator On-Prem als aktiv ausgenutzt eingestuft und in den Known Exploited Vulnerabilities-Katalog aufgenommen. Für Admins heißt das: Der nächste reguläre Wartungstermin kommt zu spät. Wer jetzt noch auf das übliche Patch-Fenster wartet, verwaltet möglicherweise bereits eine kompromittierte Infrastruktur, ohne es zu merken.

Der Clou an beiden Fällen: Sie treffen genau die Systeme, die eigentlich als Schutzschicht gedacht waren. VPN-Gateway auf der einen Seite, SD-WAN-Steuerzentrale auf der anderen. Dass gerade VPN-Gateways immer wieder zum Angriffsziel werden, macht diese Kombination besonders heikel. Wenig überraschend, dass Angreifer dort ansetzen, wo ein einziger erfolgreicher Zugriff gleich die ganze Flotte offenlegt.

Fortinet FortiOS: CVE-2025-68686 ist keine klassische RCE

Fangen wir mit der Entwarnung an, die keine ist. CVE-2025-68686 ist laut CVE-Datenbank eine Schwachstelle vom Typ Exposure of Sensitive Information to an Unauthorized Actor, also Informationsoffenlegung, nicht Remote Code Execution. Angreifer schicken speziell präparierte HTTP-Requests über das SSL-VPN von FortiOS und erreichen damit Zugriff auf sensible Daten. Der offizielle CVE-Eintrag nennt die betroffenen FortiOS-Zweige: die Branches 7.6.0 bis 7.6.1, 7.4.0 bis 7.4.6 sowie ältere 6.4-Versionen sind erfasst.

Das Pikante daran: Die Lücke erlaubt das Umgehen eines früheren Fixes gegen eine Symlink-Persistence-Technik, die bei Post-Exploitation-Fällen bereits beobachtet wurde. Übersetzt heißt das: Ein Angreifer, der vorher schon irgendwie auf das Dateisystem gekommen ist, kann über diese Lücke seinen Zugriff verstecken und weiter Daten abgreifen, obwohl Fortinet den ursprünglichen Persistenz-Trick eigentlich schon geschlossen hatte. Kein Erstzugang also, sondern ein Werkzeug für alle, die schon drin sind. Das macht die Sache nicht harmloser, sondern in bestimmten Konstellationen sogar unangenehmer, weil sie im Verbund mit anderen Schwachstellen zur stillen Dauerpräsenz im Netz wird.

Die CVSS-Bewertung liegt bei 5,9, also im mittleren Bereich. Genau dieser Wert sorgt in vielen Security-Teams für falsche Priorisierung. Fortinet empfiehlt in seinem Advisory das Update auf FortiOS 7.6.2 oder höher beziehungsweise 7.4.7 oder höher im 7.4er-Zweig. Für Admins auf 6.4 oder älteren 7.0/7.2-Ständen gilt: erst prüfen, ob der eigene Build in der aktuellen Advisory-Liste als betroffen markiert ist, dann auf einen unterstützten, gepatchten Branch wechseln.

VeloCloud Orchestrator: Command Injection mit maximalem Score

Wenn CVE-2025-68686 die leise Variante ist, dann ist CVE-2026-16812 der Paukenschlag. Betroffen ist der VeloCloud Orchestrator On-Prem, heute unter Arista VeloCloud geführt, zentrale Steuerungsinstanz für SD-WAN-Umgebungen. Die Schwachstelle ist eine OS Command Injection: Die Web-Oberfläche des Orchestrators neutralisiert Eingaben nicht ausreichend, wodurch ein entfernter, nicht authentifizierter Angreifer eigene Systembefehle einschleusen kann. Sicherheitsanalysten geben für diese Lücke einen CVSS-Wert von 10,0 an, den Maximalwert der Skala.

Der Effekt eines erfolgreichen Angriffs: vollständige Kompromittierung des Orchestrator-Hosts, inklusive Zugriff auf privilegierte interne Funktionen. Und das ist der eigentliche Grund, warum diese Lücke so brisant ist. Ein Orchestrator verwaltet nicht ein Gerät, sondern potenziell Dutzende oder Hunderte Edge-Standorte gleichzeitig. Wer den Orchestrator übernimmt, übernimmt im schlechtesten Fall die Kontrolle über die gesamte SD-WAN-Infrastruktur eines Unternehmens oder eines Managed-Service-Providers, der VeloCloud für mehrere Kunden betreibt. Für MSP-Umgebungen mit zentralem VCO ist das eine besonders unangenehme Rechnung: eine Lücke, viele Mandanten betroffen.

Die Vendor-Guidance ist entsprechend klar formuliert: Upgrade auf die jeweils passende, gepatchte VCO-Release, danach Prüfung auf bereits erfolgte Kompromittierung, Rotation aller Zugangsdaten und ein Blick auf den Zustand der angebundenen Edge-Geräte. Wer nur patcht und den Rest überspringt, behandelt lediglich das Symptom, nicht die mögliche bereits erfolgte Übernahme.

Warum der KEV-Eintrag mehr zählt als der CVSS-Wert

Hier lohnt sich ein kurzer Exkurs, weil er die häufigste Fehleinschätzung in Security-Teams erklärt. CVSS bewertet das theoretische Schadenspotenzial einer Schwachstelle unter Idealbedingungen für den Angreifer. Der KEV-Katalog der CISA bewertet etwas anderes: reale, dokumentierte Ausnutzung im Feld. Eine Lücke mit CVSS 5,9 kann im KEV-Katalog landen, wenn Behörden Beweise für aktive Angriffe vorliegen. Genau das ist bei CVE-2025-68686 der Fall. Diese Logik zeigt sich immer wieder, etwa auch bei der Aufnahme der Langflow-Lücke in den Katalog, bei der ebenfalls nicht der reine Schweregrad, sondern die belegte Ausnutzung den Ausschlag gab.

Für die Priorisierung in der Praxis bedeutet das: Der KEV-Status sollte in jedem Patch-Management-Prozess mit KEV-Priorisierung automatisch die höchste Stufe auslösen, unabhängig vom CVSS-Wert. Viele Ticketing-Systeme sind aber immer noch so konfiguriert, dass sie primär nach CVSS-Schwellenwert filtern. Wer intern eine Regel wie „alles über 7,0 wird priorisiert“ fährt, würde CVE-2025-68686 glatt durchrutschen lassen. Das ist der Moment, in dem Prozesse gegen die eigentliche Bedrohungslage verlieren.

Ein weiterer Aspekt, der oft untergeht: US-Bundesbehörden sind über die Binding Operational Directive 22-01 verpflichtet, KEV-gelistete Schwachstellen innerhalb enger Fristen zu schließen. Für deutsche und europäische Unternehmen gilt diese Vorgabe formal nicht, trotzdem orientieren sich zunehmend auch hiesige IT-Sicherheitsabteilungen an der KEV-Liste als praktischem Frühwarnsystem. Wer den Katalog ignoriert, weil er „nur für US-Behörden“ gilt, verschenkt eine der wenigen Quellen, die tatsächliche Ausnutzung von theoretischem Risiko unterscheidet. Gerade in Zeiten, in denen täglich neue CVEs veröffentlicht werden und kein Team alle im Detail bewerten kann, ist der KEV-Status ein praktikabler Filter, um die wenigen wirklich dringenden Fälle aus der Masse herauszufischen.

Fortinet unter Dauerdruck: Kein Einzelfall 2026

Die beiden neuen KEV-Einträge reihen sich in eine längere Kette ein. Bereits im Januar 2026 warnte das BSI vor einer kritischen Schwachstelle in der FortiCloud-SSO-Anmeldung, CVE-2026-24858, mit einem CVSS-Wert von 9,8 und aktiver Ausnutzung zum Zeitpunkt der Warnung. Zu jenem Stand existierte laut BSI noch kein Patch. Fortinet reagierte, indem der Hersteller die komplette FortiCloud-SSO-Authentifizierung vorübergehend deaktivierte, um weitere Angriffe zu unterbinden. Eine drastische Maßnahme, aber unter den Umständen nachvollziehbar.

Das Muster ist eindeutig: VPN-Gateways, Cloud-Anmeldung und Management-Oberflächen von Fortinet stehen seit Monaten im Fokus von Angreifern, die gezielt nach initialen Zugangspunkten suchen. Für FortiOS-Betreiber bedeutet das, dass ein einzelner Patch-Zyklus selten reicht. Die realistische Erwartung für 2026 ist eine Serie weiterer Advisories, nicht ein einmaliges Aufräumen. Wer FortiGate, FortiOS oder angebundene Fortinet-Produkte betreibt, sollte Advisories des Herstellers als laufenden Prozess einplanen, nicht als Ausnahmefall.

Interessant ist dabei auch die Rolle von Edge-Geräten im Allgemeinen. VPN-Gateways, Firewalls und SD-WAN-Appliances laufen häufig über Jahre ohne größere Aufmerksamkeit, solange sie ihren Dienst tun. Anders als bei klassischen Servern oder Endpunkten fehlt bei vielen dieser Geräte ein durchgängiges Patch-Monitoring, das automatisch auf neue Advisories reagiert. Genau diese blinde Stelle nutzen Angreifer gezielt aus, weil Edge-Geräte oft direkt am Internet hängen, aber seltener im Fokus der täglichen Sicherheitsroutine stehen als etwa Endpoint-Systeme mit EDR-Agenten.

Nach dem Upgrade folgt die Pflicht: Kompromittierung prüfen, Zugangsdaten rotieren, Edge-Geräte kontrollieren. (Symbolbild)

Sofortmaßnahmen für Fortinet- und VeloCloud-Admins

Was heißt das jetzt konkret für den Arbeitsalltag? Zunächst: FortiOS auf einen der von Fortinet als gefixt markierten Stände bringen, also 7.6.2 oder höher beziehungsweise 7.4.7 oder höher im entsprechenden Zweig. Wer noch auf 6.4 oder älteren 7.0/7.2-Releases sitzt, sollte den Wechsel auf einen unterstützten Branch nicht länger aufschieben, unabhängig von dieser konkreten Lücke.

Für VeloCloud Orchestrator gilt die gleiche Logik, nur mit höherer Dringlichkeit angesichts des CVSS-Werts von 10,0. Die Reihenfolge sollte lauten: Zugang zur Orchestrator-Oberfläche kurzfristig einschränken, etwa über IP-Allowlisting für Admin-Zugänge, danach das Upgrade auf die gepatchte Version einspielen. Anschließend eine Prüfung auf Kompromittierungsspuren, weil ein Patch aktive Ausnutzung stoppt, aber keinen bereits erfolgten Einbruch heilt. Zum Schluss die Rotation sämtlicher Zugangsdaten, die über den Orchestrator verwaltet werden, inklusive API-Zugänge und Service-Accounts.

Ein Punkt, der in der Praxis oft übersehen wird: Auch die angebundenen Edge-Geräte gehören auf die Prüfliste. Ein kompromittierter Orchestrator kann theoretisch Konfigurationen an nachgeordnete Edge-Instanzen ausrollen. Wer nur den Orchestrator selbst kontrolliert und die Edge-Flotte außen vor lässt, prüft nur die Hälfte des Problems.

Konkrete Checkliste für die ersten 48 Stunden

Betroffene FortiOS-Version und VCO-Release im eigenen Bestand identifizieren, am besten über eine zentrale Asset-Inventarisierung statt manueller Nachfrage bei einzelnen Standorten.
SSL-VPN-Zugriff auf FortiOS-Geräten temporär auf bekannte IP-Bereiche einschränken, falls das Update nicht sofort möglich ist.
Administrativen Zugang zum VeloCloud Orchestrator auf interne Netzsegmente oder VPN-Tunnel begrenzen.
Patches in einer priorisierten Reihenfolge einspielen: zuerst VCO wegen CVSS 10,0, danach FortiOS.
Nach dem Patch: Logs auf ungewöhnliche Zugriffe, unerwartete Prozessstarts oder verdächtige Symlink-Strukturen prüfen.
Zugangsdaten und API-Schlüssel rotieren, die über die betroffenen Systeme verwaltet wurden.

Was tun, wenn sofortiges Patchen nicht möglich ist?

Nicht jede Organisation kann binnen Stunden ein produktives FortiOS-Update oder einen VCO-Upgrade durchziehen, gerade in Umgebungen mit strengen Change-Prozessen oder Abhängigkeiten zu anderen Systemen. Für diesen Fall gibt es Zwischenschritte, die das Risiko senken, ohne die Lücke vollständig zu schließen.

Bei FortiOS: Wer SSL-VPN aktuell nicht produktiv benötigt, sollte den Dienst deaktivieren oder zumindest den Zugriff auf eine feste Liste vertrauenswürdiger IP-Bereiche begrenzen. Das nimmt Angreifern den primären Vektor für CVE-2025-68686, schließt aber nicht aus, dass SSL-VPN später wieder gebraucht wird und die Lücke dann erneut relevant ist. Eine Notlösung, kein Ersatz für den Patch.

Bei VeloCloud Orchestrator ist die Lage unangenehmer, weil eine zentrale Management-Oberfläche selten komplett abgeschaltet werden kann, ohne den Betrieb der SD-WAN-Umgebung zu beeinträchtigen. Machbar ist meist zumindest die Einschränkung des administrativen Zugriffs auf interne Netzsegmente oder VPN-Tunnel, kombiniert mit zusätzlichem Monitoring auf ungewöhnliche Befehlsausführungen oder Prozessstarts auf dem Orchestrator-Host. Wer dazu Threat-Hunting-Kapazitäten hat, sollte gezielt nach Indikatoren für die bekannten Ausnutzungsmuster suchen, wie sie in den CISA-Advisories zu beiden Lücken beschrieben sind.

Zwei Szenarien aus der Praxis

Um die abstrakte Risikolage greifbarer zu machen, lohnt sich ein Blick auf zwei fiktive, aber realistische Konstellationen. Im ersten Szenario betreibt ein mittelständisches Unternehmen eine Handvoll FortiGate-Appliances an verschiedenen Standorten, gesteuert über eine zentrale Verwaltung, mit SSL-VPN für den Zugriff des Außendienstes. Die IT-Abteilung erfährt vom KEV-Eintrag über einen Newsletter, prüft die eigene Versionsliste und stellt fest, dass zwei Standorte noch auf einem älteren 7.4er-Stand laufen. Weil der Außendienst auf SSL-VPN angewiesen ist, kann der Dienst nicht einfach abgeschaltet werden. Die pragmatische Lösung: Zugriff auf eine Liste bekannter IP-Bereiche der Mitarbeiter einschränken, parallel das Update für die betroffenen Standorte in der nächsten Nacht einspielen. Das Risiko sinkt deutlich, ohne dass der Betrieb leidet.

Im zweiten Szenario betreibt ein Managed-Service-Provider einen zentralen VeloCloud Orchestrator für mehrere Kundenumgebungen. Hier zeigt sich der Ernst der Lage besonders deutlich: Ein einzelner erfolgreicher Angriff auf den Orchestrator würde theoretisch Zugriff auf die SD-WAN-Konfiguration aller angeschlossenen Kunden ermöglichen. Der Provider entscheidet sich, das Update noch am selben Tag außerhalb des regulären Wartungsfensters einzuspielen, informiert die betroffenen Kunden proaktiv über die Maßnahme und führt anschließend eine gezielte Prüfung der Zugriffslogs der vergangenen Wochen durch. Teurer und aufwendiger als im ersten Szenario, aber angesichts des CVSS-Werts von 10,0 und der Vielzahl betroffener Mandanten die einzig vertretbare Reaktion.

Beide Beispiele zeigen, dass es selten eine Blaupause gibt, die für alle Umgebungen gleich funktioniert. Entscheidend ist, dass die Reaktion zur tatsächlichen Kritikalität des betroffenen Systems passt, statt pauschal nach Schema F vorzugehen.

Der Unterschied zwischen Patchen und Bereinigen

Eine Sache, die sich durch beide Fälle zieht: Ein eingespielter Patch beendet die Möglichkeit weiterer Ausnutzung, er beweist aber nicht, dass vorher nichts passiert ist. Gerade bei CVE-2025-68686, die explizit mit einer bereits beobachteten Persistence-Technik in Verbindung steht, ist die Annahme „Patch drauf, Thema erledigt“ riskant. Realistischer ist ein zweistufiges Vorgehen: Erst die Lücke schließen, damit kein neuer Zugriff mehr möglich ist, dann eine forensische Prüfung, ob bereits jemand drin war. Bei kritischen Systemen wie einem zentralen SD-WAN-Orchestrator sollte diese Prüfung nicht optional sein, sondern Standardteil des Incident-Response-Plans.

Meine persönliche Einschätzung: Genau an dieser Stelle scheitern viele Unternehmen, nicht am Patch selbst. Ein Update einzuspielen ist Routine, eine ordentliche Nachprüfung auf Kompromittierung kostet Zeit, Personal und manchmal unangenehme Wahrheiten. Wer diesen Schritt aus Bequemlichkeit auslässt, verschiebt das Problem nur in die Zukunft, meist bis zum nächsten Vorfall, der dann deutlich teurer wird.

Ein Gegenargument, das in Diskussionen häufig auftaucht: Nicht jede Organisation hat die Kapazitäten für eine vollständige forensische Analyse nach jedem Patch, und ein pauschales „immer alles prüfen“ ist in der Realität kaum durchsetzbar, wenn parallel Dutzende andere Advisories eingehen. Das ist ein berechtigter Einwand. Die Antwort darauf ist keine vollständige forensische Untersuchung bei jedem Vorfall, sondern eine risikobasierte Abstufung: Bei einem CVSS-10,0-Fall mit direktem Internetzugriff wie dem VeloCloud-Orchestrator ist die Prüfung Pflicht, bei einer weniger kritischen internen Komponente kann ein reduziertes Monitoring über einen längeren Zeitraum ausreichen. Wichtig ist, diese Abstufung bewusst und dokumentiert zu treffen, statt sie implizit durch fehlende Ressourcen entstehen zu lassen.

Was bleibt?

Zwei KEV-Einträge an einem Tag, ein Hersteller mit Erfahrung im Krisenmodus, ein SD-WAN-Produkt mit maximalem CVSS-Wert. Die eigentliche Frage für Admins ist nicht, ob gepatcht wird, sondern wie schnell und wie gründlich. Reicht Ihr aktueller Patch-Prozess aus, um KEV-Einträge binnen Stunden statt Wochen zu bearbeiten? Oder hängt die Priorisierung noch an starren CVSS-Schwellenwerten, die genau solche Fälle wie CVE-2025-68686 durchrutschen lassen? Wer diese Frage jetzt ehrlich beantwortet, spart sich möglicherweise den nächsten Anruf vom Incident-Response-Team.