Die Appliance, deren Aufgabe das Zünden von Schadcode ist

Eine Sandbox existiert, um angegriffen zu werden. Sie kaufen FortiSandbox, damit verdächtige Dateien an einer Stelle geöffnet werden, die nicht Ihr Netzwerk ist, damit sie beim Fehlverhalten beobachtet und beurteilt werden. Sie steht konstruktionsbedingt genau dort, wo unvertrauenswürdige Dinge ankommen. Genau das macht eine unauthentifizierte Befehlsinjektion in ihrer Weboberfläche zu einer anderen Kategorie von Problem als denselben Fehler in einem gewöhnlichen Server.

CVE-2026-25089 ist genau das. Die Lücke betrifft die Weboberfläche von FortiSandbox, FortiSandbox Cloud und FortiSandbox PaaS und erlaubt einem unauthentifizierten Angreifer, über speziell gestaltete HTTP-Anfragen unbefugte Befehle auszuführen. Sie trägt einen CVSS-Wert von 9.1. Fortinet hat sie am 9. Juni 2026 veröffentlicht und gepatcht.

Mitte Juni begann die Ausnutzung, Mitte Juli bemerkte es der Katalog

Die Ausnutzung von drei FortiSandbox-Lücken wurde über das Wochenende vom 14. bis 16. Juni in freier Wildbahn beobachtet, und unabhängiges Tracking verzeichnete die Ausnutzung von CVE-2026-39808 bereits ab dem 12. Juni. Die Fachpresse berichtete damals darüber: Help Net Security am 16. Juni, Qualys am Tag darauf, dazu The Hacker News und SecurityWeek. Zwei der drei, CVE-2026-39808 und CVE-2026-39813, hatte Fortinet schon im April offengelegt. Die dritte, CVE-2026-25089, war am 9. Juni gepatcht worden, wenige Tage bevor die Angriffe begannen.

Am 16. Juli 2026 veröffentlichte CISA die Katalogversion 2026.07.16 und fügte drei Einträge hinzu. Zwei davon sind die FortiSandbox-Lücken, CVE-2026-25089 und CVE-2026-39808. Der dritte ist eine Deserialisierungslücke in Microsoft SharePoint, CVE-2026-58644.

Zählen Sie die Tage. Bestätigte, öffentlich berichtete Ausnutzung in freier Wildbahn Mitte Juni. Eintrag im Bundeskatalog am 16. Juli. Rund dreißig Tage liegen dazwischen, bei einer aus dem Internet erreichbaren Appliance mit einer unauthentifizierten Remote-Code-Execution-Lücke, und während dieser dreißig Tage war die Information nicht geheim. Sie stand in Hersteller-Advisories und in der Fachpresse.

Die dritte fehlt immer noch

Drei FortiSandbox-CVEs wurden in dieser Juni-Welle als ausgenutzt gemeldet. Zwei wurden am 16. Juli katalogisiert. CVE-2026-39813, eine Path-Traversal-Lücke in der JRPC-API von FortiSandbox, mit der sich die Authentifizierung umgehen lässt, steht nicht im Katalog.

Das ist der Teil, der ändern sollte, wie der Katalog genutzt wird, und nicht bloß wie schnell. Ein KEV-Eintrag ist ein starkes positives Signal: was dort steht, wird ausgenutzt, und Sie sollten handeln. Das Fehlen eines Eintrags ist ein weit schwächeres Signal, als die meisten Patch-Programme annehmen. CVE-2026-39813 wurde neben den beiden gelisteten als ausgenutzt gemeldet, in derselben Welle, in derselben Produktfamilie, und schaffte es nicht in den Katalog. Wer patcht, was CISA listet, und zurückstellt, was CISA nicht listet, hat gerade eine Lücke zurückgestellt, die Angreifer im Juni verwendet haben.

Eine Drei-Tage-Uhr auf einer Change-kontrollierten Box

Alle drei am 16. Juli aufgenommenen Einträge tragen ein Behebungsdatum vom 19. Juli 2026. Drei Tage.

Für einen europäischen Betreiber ist die US-Bundesfrist selbst nicht bindend, und es liegt nahe, sie als amerikanisches Verwaltungsdetail abzulegen. Nützlicher ist sie als Schweregrad-Lesung. Ein Behebungsdatum nach drei Tagen ist die Art des Katalogs zu sagen, dass er nicht erwartet, dass Sie auf das nächste Fenster warten. Unangenehm wird es beim Zusammenstoß mit der Realität: eine Sandbox-Appliance steht üblicherweise gerade deshalb unter Change-Kontrolle, weil sie Produktivverkehr inspiziert, und drei Tage sind in den meisten Organisationen kein Change-Fenster. Diese Spannung ist das eigentliche operative Problem, und sie löst sich nicht dadurch auf, dass man die Frist genauer liest.

Unter NIS2 liegt das Risiko nicht in der amerikanischen Frist, sondern in der gewöhnlichen Sorgfaltspflicht, und eine unauthentifizierte Remote-Code-Execution-Lücke auf einer Sicherheits-Appliance, einen Monat lang in freier Wildbahn ausgenutzt und mit verfügbarem Hersteller-Patch, lässt sich schwer als akzeptiertes Risiko erklären.

Verdrahten Sie den Auslöser neu

Die Anweisung hier ist klein und konkret. Wenn Ihr Schwachstellenprozess erst startet, sobald etwas im KEV auftaucht, startet er rund einen Monat zu spät und übersieht Positionen vollständig. Das ist keine Kritik am Katalog, der tut, was er ankündigt: er verzeichnet, was nachweislich ausgenutzt wird, sobald die Beweislage die Schwelle erreicht. Es ist eine Kritik daran, einen Bestätigungs-Feed als Frühwarnsystem zu verwenden.

Tun Sie drei Dinge. Abonnieren Sie direkt die PSIRT-Advisory-Feeds jedes Herstellers, dessen Appliances unvertrauenswürdigen Verkehr terminieren, denn Fortinet veröffentlichte dies im Juni, während der Katalog im Juli sprach. Geben Sie internetseitigen Sicherheits-Appliances eine eigene Patch-Spur mit kürzerer Uhr als der übrigen Infrastruktur, denn sie sind zugleich die exponiertesten und die am stärksten Change-kontrollierten Assets, die Sie besitzen. Und prüfen Sie Ihren FortiSandbox-Bestand gegen alle drei Juni-CVEs, nicht gegen die zwei katalogisierten.

Weiterlesen: 430.000 Firewalls wurden zur Ransomware-Zufuhr  |  Ein gefälschtes Token öffnet jeden verwalteten PC