Vier ausgenutzte Lücken am Netzwerkrand verlangen mehr als einen Patch

Die US-Behörde CISA (Cybersecurity and Infrastructure Security Agency) hat am 22. September vier aktiv ausgenutzte Schwachstellen in Produkten von Check Point, Arista und F5 in ihren Katalog bekannter ausgenutzter Schwachstellen aufgenommen. Die Frist endet am 25. September. Nach der Binding Operational Directive 26-04 verlangt der Katalog jeweils eine forensische Prüfung, die ein Wartungsticket nicht ersetzt.

Alle vier Einträge betreffen Systeme am Netzwerkrand: VPN-Gateways, einen Orchestrator für softwaredefinierte Weitverkehrsnetze (SD-WAN) und einen Access Policy Manager (APM). Wer sie nach einem erfolgreichen Angriff kontrolliert, kontrolliert oft den Rest des Netzes. Das Magazin hat dieses Muster zuletzt in der Berichterstattung über Exploit-Kampagnen gegen VPN-Gateways beschrieben.

Dieser Artikel ordnet die vier Einträge, die Herstellerhinweise und die Reihenfolge der nötigen Arbeiten. Angriffsdetails und Nachbauanleitungen fehlen bewusst.

Vier Einträge teilen sich eine Frist und eine Auflage

Alle vier Schwachstellen tragen im Katalog das Fälligkeitsdatum 25. September und den Vermerk, dass eine forensische Prüfung (Forensic Triage) nach Binding Operational Directive 26-04 erforderlich ist. Die Einträge im Überblick:

• CVE-2026-85102 (Check Point, mehrere Produkte): fehlerhafte Prüfung von Zertifikaten.
• CVE-2026-93616 (Check Point, mehrere Produkte): Pfadumgehung (Path Traversal).
• CVE-2026-93952 (Arista VeloCloud Orchestrator): fehlerhafte Prüfung von Eingaben.
• CVE-2026-94127 (F5 BIG-IP APM): Pufferüberlauf im Heap-Speicher.

CVE steht für Common Vulnerabilities and Exposures, die weltweit genutzte Kennung für Sicherheitslücken. Der Katalog selbst gilt als lebende Quelle. Wer nur die Meldung liest und den Katalog nie öffnet, übersieht die vorgeschriebenen Maßnahmen, die Fristen und die Kennzeichnung der forensischen Prüfung.

Gemeinsamer Nenner der vier Einträge ist der Netzwerkrand. Check Point betrifft den VPN- und Verwaltungsbereich, Arista den Orchestrator für SD-WAN und F5 jene Stelle, an der Zugriffsrichtlinien und das Authentifizierungsprotokoll OAuth zusammentreffen. Wer diese Lücken wie gewöhnliche Einträge einer Schwachstellenliste abarbeitet, setzt die Prioritäten falsch.

Die Betriebsanweisung 26-04 verlangt Prüfung vor und nach dem Patch

Die Binding Operational Directive 26-04 richtet sich an zivile Bundesbehörden der USA, ermutigt aber ausdrücklich alle anderen Organisationen, denselben Maßstab anzulegen. Hochriskante Einträge auf öffentlich erreichbaren Systemen, die nach erfolgreicher Ausnutzung totale Kontrolle ermöglichen können, gehören an die Spitze der Arbeitsliste. Sie dürfen nicht hinter das nächste Wartungsfenster oder das Quartals-Release rutschen.

Für die vier Einträge gilt laut Katalog die Auflage der forensischen Prüfung. Praktisch heißt das: Vor dem Einspielen des Patches ist zu klären, ob das System bereits kompromittiert wurde. Nach dem Patch folgt eine zweite Prüfung. Der Patch schließt die Tür, räumt aber niemanden aus, der schon im Haus steht.

Die Frist am 25. September zeigt, ob eine Organisation den Katalog als Prioritätensystem versteht oder als zusätzliche Spalte im Schwachstellenwerkzeug, die irgendwann grün wird. Die Ausrede, man sei keine US-Bundesbehörde, trägt nicht weit. Die Angriffsfläche am Netzwerkrand unterscheidet nicht nach Behördenstatus, und ein öffentlich erreichbares VPN-Gateway bleibt privilegiert, wem auch immer es gehört.

Check Point, Arista und F5 verweisen auf ihre eigenen Hinweise

Check Point hat die aktive Ausnutzung beider Schwachstellen bestätigt und Korrekturen bereitgestellt. Im Sicherheitshinweis des Herstellers lautet die Botschaft, sofort zu handeln.

CVE-2026-85102 betrifft die Zertifikatsprüfung bei der VPN-Verhandlung. Der Hersteller beschreibt eine Codeausführung aus der Ferne ohne Anmeldung mit einem CVSS-Wert von 9,8. CVSS steht für Common Vulnerability Scoring System, das den Schweregrad einer Lücke bewertet. Genannt werden betroffene Produktlinien im Umfeld von Gateway und Spark. Die Korrektur ist seit dem 9. September verfügbar, Details stehen im Support-Artikel sk1000117.

CVE-2026-93616 ist eine Pfadumgehung im Verwaltungsdienst. Sie lässt sich ohne vorherige Anmeldung ausnutzen und erreicht ebenfalls einen CVSS-Wert von 9,8. Der Support-Artikel sk1000171 führt zur Korrektur. Für Änderungsverantwortliche wichtig: Die LivePatch-Pakete Take 28 und 29 beheben diese Lücke nicht. Wer sich auf LivePatch verlässt, hat CVE-2026-93616 damit nicht erledigt.

Empfohlen sind die Herstellerkorrekturen ohne Verzögerung. Hinzu kommt eine Durchsicht der Protokolle auf auffällige zertifikatsbasierte Anmeldungen am Mobilzugang. Hinweise auf Spuren und die Suche danach liefern die beiden Support-Artikel.

Bei Arista betrifft CVE-2026-93952 den VeloCloud Orchestrator (VCO). Sekundäre Einordnungen deuten darauf hin, dass die fehlerhafte Eingabeprüfung Fernzugriff auf privilegierte interne Funktionen eines selbst betriebenen VCO ermöglichen kann. Gehostete und dedizierte Varianten hat der Hersteller laut verfügbaren Hinweisen bereits gepatcht. Wer den Orchestrator im eigenen Rechenzentrum betreibt, folgt dem Sicherheitshinweis von Arista, der im Umfeld von Advisory 0183 geführt wird, sofern der Hersteller ihn dort ablegt. Versionsnummern aus Zweitquellen sind kein Ersatz. Der Orchestrator steuert Außenstellen, Richtlinien und Tunnel und gehört deshalb in dieselbe Inventarliste wie das VPN-Gateway. Wie sich Muster bei Fortinet und VeloCloud wiederholen, zeigt der Beitrag Zwei KEVs bei Fortinet und VeloCloud.

Bei F5 betrifft CVE-2026-94127 den BIG-IP APM. Die Lücke greift, wenn auf dem virtuellen Server sowohl eine Zugriffsrichtlinie als auch ein OAuth-Profil konfiguriert sind und APM als OAuth-Autorisierungsserver arbeitet. Möglich ist dann eine Codeausführung aus der Ferne ohne Anmeldung. Der Hersteller beschreibt Korrekturen und Zwischenmaßnahmen im Artikel K000162605. Als Übergangslösung für die Zeit der forensischen Prüfung verweist F5 auf temporäre Maßnahmen über den Support, darunter Hinweise zu iRules. Wer APM nicht als OAuth-Autorisierungsserver betreibt, darf anders priorisieren, sollte die Konfiguration aber prüfen und nicht vermuten.

Ein Wartungsticket beantwortet die Frage nach einer früheren Kompromittierung nicht

Ein Ticket mit dem Titel „Patch im nächsten Wartungsfenster“ behandelt die Schwachstelle in der Zukunft, aber nicht die Frage, ob das System schon kompromittiert wurde. Genau diese Frage gehört laut Katalog zur vorgeschriebenen Maßnahme und ist kein Bonus für besonders eifrige Notfallteams.

Was ein Schwachstellenscanner nach dem Patch nicht zeigt, sind Sitzungen, dauerhafte Hintertüren, seitliche Bewegungen im Netz, auffällige Administratorzugriffe, Zertifikatsanomalien und Aufrufe der Orchestrator-Schnittstelle außerhalb der üblichen Muster. Eine Behebung ohne Prüfung vorher ist unvollständig, ebenso eine ohne Prüfung nachher. Wer nur die Kennung der Lücke schließt, ändert einen Status im Werkzeug, aber nicht den Sicherheitszustand.

Gewöhnliche Schwachstellenlisten sortieren nach Schweregrad, Systemklasse, Wartungsfenster und fachlich Verantwortlichen. Das ist im Alltag legitim. Ein Katalogeintrag bedeutet dagegen belegte aktive Ausnutzung, am Netzwerkrand mit der Aussicht auf totale Kontrolle. Aus vier Einträgen in einer Meldung folgt oft der Reflex, die schwerste Lücke zuerst und den Rest nächste Woche zu beheben. Die Betriebsanweisung und die gemeinsame Frist sprechen dagegen: Alle vier gehören in denselben Prioritätskorb, soweit sie im eigenen Inventar vorkommen und erreichbar sind. Die Dynamik solcher Warnungen zeigt auch der Beitrag zu Zero-Day-Exploits und CISA-Warnungen.

Meinung: Wer nach dem Patch nur den grünen Haken im Scanner abnickt, hat das Schloss erneuert und den Einbrecher drinnen gelassen.

Hinzu kommt ein organisatorisches Problem. Schwachstellenmanagement und Incident Response (die Reaktion auf Sicherheitsvorfälle) sind in vielen Häusern getrennte Welten, die der Katalog nun zusammenzwingt. Zuständig für den Betrieb des VPN-Gateways ist oft ein anderes Team als jenes, das die Kompromittierungsfrage beantworten soll. Ohne Abstimmung zwischen beiden fällt die Auflage durch die Lücke.

So gelingt die Abarbeitung bis zum 25. September

Die Reihenfolge ist langweilig und gerade deshalb tragfähig: Inventar, Erreichbarkeit, Herstellerkorrektur, Prüfung vor und nach dem Patch, ehrlicher Umgang mit der Frist.

Dieses Bild wurde 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

1. Systeme am Netzwerkrand erfassen. Welche Check-Point-Gateways und Spark-Instanzen stehen wo, und welche Verwaltungsdienste sind erreichbar? Welche VeloCloud-Orchestratoren laufen im eigenen Betrieb, und wer kann sie erreichen? Welche BIG-IP-APM-Instanzen betreiben OAuth-Autorisierungsserver zusammen mit einer Zugriffsrichtlinie? Wer das nicht beantworten kann, kann die Frist nicht ernsthaft steuern.
2. Den Herstellerhinweisen folgen. Bei Check Point sind das der Sicherheitshinweis vom 22. September sowie sk1000117 und sk1000171, bei Arista das Advisory zu CVE-2026-93952 und bei F5 der Artikel K000162605. Zwischenmaßnahmen von F5 gibt es nur über den Support.
3. Erreichbarkeit verringern, wo die Korrektur noch fehlt. Verwaltungsschnittstellen sollten nicht breiter erreichbar sein als nötig, Administratorpfade sind zu härten. Das ersetzt den Patch nicht, verschafft aber Zeit für die Prüfung.
4. Vor dem Patch auf Kompromittierung prüfen. Dazu gehören Protokolle, Auffälligkeiten bei zertifikatsbasierten Anmeldungen, Orchestrator-Zugriffe außerhalb der üblichen Muster und Auffälligkeiten bei APM und OAuth. Fehlt dem Haus die Kapazität für Notfälle, ist zu eskalieren statt abzuwarten.
5. Patchen und erneut prüfen. Der Wartungsauftrag ist erst erledigt, wenn Korrektur und zweite Prüfung dokumentiert sind.
6. Die Frist ehrlich behandeln. Wer den 25. September reißt, sollte den Grund kennen und das Risiko gegenüber Geschäftsführung und Notfallteam klar benennen. Das nächste Wartungsfenster ist eine Betriebsentscheidung und keine Gleichwertigkeit zur Katalogfrist.

Gegenüber dem Änderungsgremium genügt eine nüchterne Darstellung: Vier aktiv ausgenutzte Schwachstellen am Netzwerkrand stehen im Katalog, die Frist ist der 25. September, der Katalog verlangt eine forensische Prüfung, das Inventar zeigt die betroffenen Systeme, und Kompromittierung wird vor und nach dem Patch geprüft. Das Wartungsticket allein erfüllt die Auflage nicht. Wer stattdessen nur „kritisch, bitte schnell“ meldet, erzeugt Lärm, aber keine Entscheidung.

Zeitdruck verführt zu schlechten Abkürzungen: Patch ohne Datensicherung, ohne Protokollsichtung und ohne Wissen, welche Instanz wirklich betroffen ist. Die bessere Abkürzung beginnt beim Inventar, klärt die Erreichbarkeit, öffnet die Herstellerseiten parallel, plant das Notfallteam für die Prüfung vor und nach dem Patch ein und beschleunigt erst dann die Änderung. Dieselbe Logik gilt für kritische Lücken in VPN-Zugängen, wie der Beitrag zu Zero-Day-Lücken in Homeoffice-VPNs zeigt.

Als Erfolg zählt, wenn betroffene Systeme bekannt sind, die Herstellerkorrekturen eingespielt sind oder Abweichungen dokumentiert und an die Verantwortlichen eskaliert wurden, die Prüfung vor dem Patch gelaufen und die nach dem Patch geplant ist. Ein Scan ohne offene Kennung genügt dafür nicht.