CVE-2026-35616 in FortiClient EMS, wie der Auth-Bypass funktioniert und was jetzt zu tun ist

CVE-2026-35616 ist eine aktiv ausgenutzte FortiClient EMS-Schwachstelle in einem Teil des Stacks, den Verteidiger bereits als hochwertige Infrastruktur behandeln sollten. Fortinet sagt, dass das Problem FortiClient EMS 7.4.5 bis 7.4.6 betrifft, dass 7.2 nicht betroffen ist, dass FortiClient Cloud und FortiSASE bereits herstellerseitig behoben wurden und dass 7.4.7 den permanenten Fix enthält. Der NVD zeigt die Schwachstelle auch im CISA-Katalog "Known Exploited Vulnerabilities" (Bekannte ausgenutzte Schwachstellen) an, mit einem Abhilfedatum auf Bundesebene bis zum 9. April 2026. (FortiGuard-Laboratorien)

Diese kurze Zusammenfassung zeigt bereits, warum es sich nicht um ein "Patch am Wochenende" Problem handelt. FortiClient EMS ist nicht nur ein Dashboard. Es ist die Steuerungsebene für Endpunktrichtlinien, Fernzugriffskonfiguration, telemetrieverknüpfte Client-Verwaltung und laufende Verwaltung von mit FortiClient verbundenen Systemen. Eine Schwachstelle befindet sich hier auf einer Verwaltungsoberfläche, die Einfluss auf eine große Anzahl von Endpunkten hat, und nicht auf einem Wegwerf-Utility-Knoten mit wenig nachgelagerter Autorität. (docs.fortinet.com)

In den öffentlichen Berichten wird das Problem in etwas anderer Sprache beschrieben. Fortinet und der NVD-Eintrag beschreiben einen Fehler in der Zugriffskontrolle, der es einem nicht authentifizierten Angreifer ermöglichen kann, über manipulierte Anfragen unautorisierten Code oder Befehle auszuführen. Eine unabhängige technische Analyse geht tiefer und zeigt, warum viele Forscher dies als eine praktische Kompromittierung der EMS-Verwaltungsebene vor der Authentifizierung betrachten: Die Anwendung vertraute gefälschten HTTP-Headern, als wären sie vertrauenswürdige TLS-Client-Zertifikatssignale, und die Logik zur Validierung der Zertifikatskette selbst führte String-Prüfungen ohne echte X.509-Signaturprüfung durch. (nvd.nist.gov)

CVE-2026-35616 auf einen Blick

Die bestätigten öffentlichen Aufzeichnungen sind kompakt genug, um sie zusammenzufassen, bevor wir näher darauf eingehen.

Artikel	Derzeitiger bestätigter Status
Schwachstelle	CVE-2026-35616
Produkt	FortiClient EMS
Betroffene Versionen	7.4.5 bis 7.4.6
Nicht betroffen	7.2 Zweigstelle
Cloud-seitiger Status	FortiClient Cloud von Fortinet behoben, keine Kundenaktion; FortiSASE von Fortinet behoben, keine Kundenaktion
Status der Ausbeutung	Fortinet sagt, dass es einen Missbrauch in freier Wildbahn beobachtet hat
Hotfix-Status	Hotfixes des Herstellers für 7.4.5 und 7.4.6 veröffentlicht
Dauerhafte Fixierung	Enthalten in 7.4.7
KEV-Status	In KAG KEV
CISA Fälligkeitsdatum	9. April 2026

Diese Tabelle wurde aus den Hinweisen und Versionshinweisen von Fortinet zusammen mit dem KEV-Eintrag von NVD destilliert. (FortiGuard-Laboratorien)

Es gibt noch einen weiteren Grund, über die Zusammenfassung in der Überschrift hinaus zu lesen. Die öffentlichen Metadaten sind nicht perfekt aufgeräumt. In der Zusammenfassung des Hinweises von Fortinet heißt es, dass das Problem in freier Wildbahn ausgenutzt wurde, doch der Metadatenblock des Hinweises zeigt immer noch "Known Exploited No". Das Advisory zeigt auch einen CVSS-Wert von 9.1 an, während die NVD-Seite den Fortinet CNA-Vektor derzeit als 9.8 kritisch anzeigt. Diese Diskrepanz macht das Problem nicht weniger dringlich. Es unterstreicht jedoch eine immer wiederkehrende operative Lektion: Wenn sich eine Zero-Day-Lücke ausbreitet, sind die Details, die am wichtigsten sind, die betroffenen Versionen, die Annahmen zur Gefährdung, die verfügbaren Abhilfemaßnahmen und die Frage, ob eine aktive Ausnutzung bestätigt wurde. In diesem Fall sind diese Punkte bereits klar genug, um ein sofortiges Handeln zu rechtfertigen. (FortiGuard-Laboratorien)

Die Berichte von WatchTowr enthalten noch einen weiteren Punkt, der für Verteidiger von Bedeutung ist: Die Attacker-Eye-Sensoren von WatchTowr beobachteten den Angriff am 31. März 2026, also noch vor dem öffentlichen Hinweis von Fortinet am 4. April. Das bedeutet, dass einige Umgebungen möglicherweise schon Tage vor dem Beginn der Patching-Aktivitäten in den betroffenen Unternehmen angreifbar waren. Wenn Ihre EMS-Instanz während dieses Zeitfensters erreichbar war, ist die richtige Einstellung die Reaktion auf einen Vorfall mit Abhilfemaßnahmen, nicht die Patch-Verwaltung mit Neugierde. (watchTowr)

Warum eine Kompromittierung des FortiClient EMS schwerwiegender ist als ein normaler Verwaltungsfehler

Die Herstellerdokumentation ist hier nützlich, da sie den Explosionsradius in einfachen, operativen Begriffen definiert. FortiClient EMS ist das zentrale Managementsystem für mehrere Endpunkte, bietet Netzwerkübersicht, weist Sicherheitsrichtlinien zu, stellt FortiClient per Fernzugriff bereit, aktualisiert Benutzerprofile unabhängig vom Standort, verwaltet Endpunktverbindungen und verwaltet Endpunktstatus und Signaturinformationen. Das ist bereits genug, um die Diskussion aus der engen Kategorie "ein böser Web-Bug auf einer Appliance" herauszuholen. (docs.fortinet.com)

Auch die Profiloberfläche unter EMS-Kontrolle ist nicht trivial. Fortinets eigener Administrationsleitfaden zeigt Endpunktprofile für Fernzugriff, ZTNA-Ziele, Webfilter, Videofilter, Schwachstellenscan, Malware-Schutz, Sandbox, Firewall und Systemeinstellungen. Mit anderen Worten: Die Plattform befindet sich in der Mitte zwischen Fernzugriffsverhalten, Content-Control-Verhalten, Malware-Richtlinien, Firewall-Einstellungen und Endpunkt-Systemkonfiguration. Eine Kompromittierung des Verwaltungsservers ist nicht nur eine Kompromittierung des Servers. Es handelt sich auch um ein Problem der Richtlinienintegrität. (docs.fortinet.com)

Das Bereitstellungs- und Updatemodell erhöht diese Hebelwirkung. Fortinet dokumentiert, dass, sobald FortiClient und EMS eine Telemetrie-Verbindung aufgebaut haben, EMS FortiClient-Updates an die Endpunkte senden kann. In der gleichen Dokumentation werden auch mehrere Enrollment- und Rollout-Pfade beschrieben, darunter Deployment-Pakete, MDM-Flows und einladungsbasiertes Onboarding. Sobald ein System zur vertrauenswürdigen Richtlinien- und Update-Autorität für eine große Endgeräteflotte geworden ist, hat die Kompromittierung dieses Systems eine ganz andere betriebliche Bedeutung als die Kompromittierung einer eigenständigen internen Anwendung. (docs.fortinet.com)

Die API ist aus demselben Grund wichtig. In der Dokumentation von Fortinet heißt es, dass die FortiClient EMS-API Konfigurationsvorgänge auf EMS ermöglicht. Aus diesem Grund ist die Umgehung der Authentifizierung auf API-Ebene so schwerwiegend, noch bevor man sich darüber streitet, wie die Auswirkungen nach der Umgehung genau zu bezeichnen sind. Wenn die Verwaltungs-API erreicht werden kann und vertrauenswürdige Kontrollen imitiert oder umgangen werden können, liest der Angreifer nicht nur Daten. Der Angreifer dringt in ein System ein, das zur Konfiguration anderer Systeme dient. (docs.fortinet.com)

Ein weiteres operatives Detail macht die Frage der Gefährdung schmerzhaft konkret. Fortinet dokumentiert eine "Remote HTTPS Access"-Funktion, die, wenn sie aktiviert ist, es Administratoren ermöglicht, sich über einen Browser und HTTPS bei EMS anzumelden. Auf der gleichen Seite wird darauf hingewiesen, dass Administratoren diese Funktion deaktivieren und den Zugriff auf den Server selbst beschränken können. Das bedeutet zweierlei: Erstens gibt es einen unterstützten Pfad für die browserbasierte Fernadministration; zweitens ist die Frage, ob die Schnittstelle auf breiter Basis erreichbar ist, eine Bereitstellungsentscheidung, die sich direkt auf das Risiko in der Praxis auswirkt. (docs.fortinet.com)

Was Fortinet bestätigt hat und was in den öffentlichen Aufzeichnungen immer noch falsch dargestellt wird

Das Advisory von Fortinet ist in den wichtigsten Punkten eindeutig. Es beschreibt CVE-2026-35616 als eine unsachgemäße Zugriffskontrollschwachstelle in FortiClient EMS, die es einem nicht authentifizierten Angreifer ermöglichen kann, nicht autorisierten Code oder Befehle über manipulierte Anfragen auszuführen. Fortinet hat eine Ausnutzung dieser Schwachstelle in freier Wildbahn beobachtet. Es heißt, dass 7.4.5 bis 7.4.6 betroffen sind, 7.2 nicht, dass FortiClient Cloud und FortiSASE vom Hersteller behoben wurden und dass 7.4.7 den Fix enthält, während der veröffentlichte Hotfix in der Zwischenzeit ausreichend ist. Das sind die Fakten, an denen Sie sich orientieren sollten. (FortiGuard-Laboratorien)

Der NVD-Eintrag stimmt mit den betroffenen Versionen, der nicht authentifizierten Natur, der CWE-284-Klassifizierung und der Beschreibung der grundlegenden Auswirkungen überein. Noch wichtiger für die Priorisierung ist, dass die NVD-Seite die Schwachstelle im KEV der CISA anzeigt, wobei das Hinzufügedatum mit 6. April 2026 und das Fälligkeitsdatum mit 9. April 2026 angegeben ist. In der Praxis ist der KEV-Status wertvoller als ein marginales CVSS-Argument, da er Ihnen anzeigt, dass das Problem die Schwelle von "theoretisch schwerwiegend" zu "aktiv relevant für echte Angreifer" überschritten hat. (nvd.nist.gov)

Was die öffentlichen Aufzeichnungen noch verschleiern können, ist die Frage, wie die Verteidiger die Auswirkungen interpretieren sollten. In einigen Artikeln wird das Problem vereinfacht als "Fortinet-Authentifizierungsumgehung" bezeichnet. Andere vereinfachen es zu "unauthentifiziertem RCE". Die genauere Lesart ist folgende: Der offizielle Wortlaut des Herstellers besagt, dass unautorisierter Code oder Befehle über manipulierte Anfragen übermittelt werden, während die unabhängige Reverse-Engineering-Arbeit einen Weg zum authentifizierten API-Zugriff durch gefälschte Zertifikatsauthentifizierungssignale und eine fehlerhafte Validierung der Zertifikatskette aufzeigt. Bei einem Produkt, das für die Konfiguration von Endpunktrichtlinien und damit verbundenen Sicherheitskontrollen entwickelt wurde, ist das bereits genug, um als schwerwiegender Kompromiss auf der Verwaltungsebene behandelt zu werden. Ob Sie den Endzustand als Befehlsausführung, Remotecodeausführung oder Kompromittierung einer privilegierten API bezeichnen, sollte Ihre Reaktionspriorität nicht ändern. (FortiGuard-Laboratorien)

Ein weiterer subtiler Fehler in der frühen Diskussion bestand darin, jede "FortiClient EMS"-Implementierung als gleichermaßen gefährdet zu betrachten. Dies entspricht nicht der Aussage von Fortinet. Selbstverwaltetes EMS 7.4.5 und 7.4.6 sind die betroffenen Versionen. FortiClient Cloud und FortiSASE wurden herstellerseitig behoben und erfordern keine Maßnahmen seitens des Kunden, heißt es in dem Advisory. Diese Unterscheidung ist wichtig, da in übereilten internen Mitteilungen die Namen der Produktfamilien oft in einem einzigen panischen Satz zusammengefasst werden und die Teams dann an den falschen Stellen suchen. (FortiGuard-Laboratorien)

Wie CVE-2026-35616 innerhalb von FortiClient EMS funktioniert

Die bisher stärkste öffentliche technische Erklärung stammt von Bishop Fox' Patch und Code-Analyse, die die Schwachstelle von einem vagen Hinweis in eine konkrete architektonische Lehre verwandelt. FortiClient EMS verwendet Apache mit mod_ssl vor einer Django-Anwendung. In einem normalen TLS-Client-Zertifikat-Design füllt der Apache vertrauenswürdige WSGI-Umgebungsvariablen wie SSL_CLIENT_VERIFY und SSL_CLIENT_CERTund die Anwendung liest diese vertrauenswürdigen Werte. Das Problem dabei war, dass die Django-Middleware auch entsprechende Werte aus benutzergesteuerten HTTP-Headern akzeptierte. (Bischof Fuchs)

Der erste kritische Fehler war das Authentifizierungs-Gate. Nach der Dekompilierung von Bishop Fox behandelte der Code eine Anfrage als zertifikatstragend, wenn entweder der vertrauenswürdige SSL_CLIENT_VERIFY Variable war ERFOLG oder das Django-Mapping HTTP_X_SSL_CLIENT_VERIFY Wert war ERFOLG. Dieser zweite Wert kann direkt von jedem Client kontrolliert werden, der den HTTP-Header X-SSL-CLIENT-VERIFY. Mit anderen Worten: Ein Signal, das nur innerhalb einer vertrauenswürdigen Proxy-Anwendungs-Grenze existieren sollte, wurde von der Außenwelt akzeptiert. (Bischof Fuchs)

Der zweite kritische Fehler war sogar noch schädlicher. Die Logik der Zertifikatsverarbeitung in der Anwendung gab folgenden Dingen Priorität HTTP_X_SSL_CLIENT_CERTdie einfach die Django-Darstellung einer vom Kunden bereitgestellten X-SSL-CLIENT-CERT Header über die vertrauenswürdigen Apache-Variablen, die eigentlich echtes Client-Zertifikatsmaterial enthalten sollten. Sobald die erste Prüfung die Anfrage durch das Tor lässt, könnten die Zertifikatsdaten selbst auch aus einem fälschbaren Header stammen. Das ist nicht nur eine abstrakte "Umgehung der Autorisierung". Es ist ein Zusammenbruch der Vertrauensgrenze zwischen Reverse Proxy und Anwendungslogik. (Bischof Fuchs)

Dann gibt es noch das Problem der Validierung der Zertifikatskette. Bishop Fox stellte fest, dass validate_cert_chain() verglich nur die Distinguished Name Strings des Betreffs und des Ausstellers mit eingebetteten Fortinet Root CAs. Es wurde keine kryptografische X.509-Signaturprüfung durchgeführt. Das bedeutet, dass der Code keine echte Signierbeziehung über die Kette nachweisen konnte. Es wurde lediglich überprüft, ob die Namen richtig aussehen. In Bezug auf die Sicherheit ist das der Unterschied zwischen der Überprüfung einer Vertrauenskette und der Erkennung eines Kostüms. (Bischof Fuchs)

Aus diesem Grund sollte die Ursache als zwei separate Designfehler betrachtet werden, die zufällig zusammenkamen. Der erste Fehler war das Vertrauen in extern gelieferte HTTP-Header, die die internen TLS-Metadaten imitierten. Der zweite Fehler bestand darin, dass die Struktur der Zertifikatskette als ausreichend angesehen wurde, ohne dass die Signatur überprüft wurde. Jede der beiden Korrekturen hätte die Messlatte höher gelegt. Durch ihr gemeinsames Fehlen wurde die zertifikatsbasierte Geräteauthentifizierung zu etwas, das ein nicht authentifizierter Angreifer möglicherweise von der falschen Seite der Vertrauensgrenze aus fälschen könnte. (Bischof Fuchs)

Die Analyse von Bishop Fox erklärt auch, was der Hotfix von Fortinet ist und was nicht. Laut dieser Analyse fügt der Hotfix Apache RequestHeader nicht gesetzt Direktiven zum Entfernen von spoofbaren Headern wie X-SSL-CLIENT-VERIFY und X-SSL-CLIENT-CERT bevor sie Django erreichen. Dies ist eine wirksame Notfallmaßnahme, da sie die Grenze zwischen Proxy und Anwendung wiederherstellt. Bishop Fox weist aber auch darauf hin, dass die Validierung der Zertifikatskette, die nur aus Zeichenketten besteht, bis zur Korrektur auf Code-Ebene in Version 7.4.7 bestehen blieb. Diese Unterscheidung ist wichtig, weil sie den Verteidigern zeigt, was sie dem Hotfix zutrauen. Es handelt sich um eine notwendige und praktische Kontrolle. Es ist nicht dasselbe wie eine saubere Neugestaltung der Voraussetzungen für die Zertifikatsvalidierung in der Anwendung. (Bischof Fuchs)

Warum eine Umgehung der Autorisierung hier zu einem Server- und Flottenproblem wird

Wenn eine Sicherheitslücke in einem Verwaltungsserver auftritt, lautet die richtige Frage nicht nur: "Kann der Angreifer eindringen?" Die nächste Frage lautet: "Welche Befugnisse hat dieses System über alles andere?" FortiClient EMS verfügt über eine Menge. Es kann Endpunktrichtlinien definieren, Profile aktualisieren, Einstellungen für den Remote-Zugriff verwalten, Client-Verbindungen verwalten und über eine API agieren, die Konfigurationsvorgänge durchführt. Damit wird eine anfällige Verwaltungsoberfläche zu einem potenziellen Kraftmultiplikator. (docs.fortinet.com)

Das watchTowr-Papier ist auf der Verteidigerseite nützlich, weil es diese abstrakte Hebelwirkung in betriebliche Belange übersetzt: Endpunkt-Sicherheitsrichtlinien, VPN-Konfigurationsprofile, Anwendungs-Firewall-Regeln, Administratorkonten und Zugriffskontrollen sowie Endpunkt-Compliance-Konfigurationen. All dies sind keine unbedeutenden Knöpfe. Wenn ein Angreifer sie beeinflussen kann, nachdem er das EMS kompromittiert hat, kann das Ergebnis weniger wie ein einzelner Servervorfall aussehen, sondern eher wie ein Ereignis auf der Steuerungsebene, das Misstrauen in der gesamten Flotte verbreitet. (watchTowr)

Das ist auch der Grund, warum die Terminologiedebatte über "RCE versus auth bypass" nicht der Ort ist, an dem sich ernsthafte Antwortende aufhalten sollten. Fortinets eigener Wortlaut besagt, dass die Schwachstelle unautorisierten Code oder Befehle ermöglichen kann. WatchTowr beschreibt das Problem explizit als die Möglichkeit, unauthentifizierten Remote-Code auszuführen, und eine unabhängige Analyse zeigt einen Weg zum authentifizierten API-Zugang, indem Signale gefälscht werden, die die Anwendung niemals von Clients akzeptieren sollte. In Bezug auf die praktischen Unternehmensrisiken weisen diese Beschreibungen alle in dieselbe Richtung: Eine aus der Ferne erreichbare EMS-Instanz in einer betroffenen Niederlassung stellt ein Risiko der Krisenstufe dar. (FortiGuard-Laboratorien)

Die tiefere Lehre betrifft die Verwaltungsebenen im Allgemeinen. Sicherheitsteams modellieren Risiken oft so, als wären Endgeräte die hochwertigen Systeme und Verwaltungskonsolen nur administrative Hüllen um sie herum. Dieses Modell bricht zusammen, sobald die Verwaltungskonsole zum Mechanismus für die Konfiguration, die Einhaltung von Vorschriften, den Fernzugriff, die Bereitstellung und die Durchsetzung von Sicherheitsmaßnahmen wird. In einem System wie EMS befindet sich die Verwaltungsebene nicht neben der Endpunktflotte. Sie ist ihr vorgelagert. (docs.fortinet.com)

Was Sie zuerst prüfen sollten, wenn Sie FortiClient EMS ausführen

Beginnen Sie damit, die einfachsten Fragen mit Beweisen zu beantworten, nicht mit Annahmen. Verwenden Sie selbst verwaltetes FortiClient EMS, oder verwenden Sie FortiClient Cloud oder FortiSASE? Wenn Sie selbstverwaltetes EMS verwenden, welche Version ist genau installiert? Ist die HTTPS-Fernverwaltung aktiviert? War die Schnittstelle aus dem Internet oder aus weiten internen Segmenten erreichbar, wo ein Angreifer sie nach einer Einbruchstelle plausibel erreichen könnte? Diese Fragen sind in der ersten Stunde wichtiger als jede spekulative Jagd nach einem ausgefeilten öffentlichen Exploit. (FortiGuard-Laboratorien)

Ihre Versionseinstufung sollte genau sein, nicht ungefähr. Wenn die Umgebung auf 7.4.5 oder 7.4.6 läuft und der Hotfix noch nicht angewendet wurde, behandeln Sie den Server als gefährdet, wenn er erreichbar ist. Wenn die Umgebung auf 7.2 läuft, ist dieses CVE nicht das Problem, das Sie lösen wollen. Wenn die Umgebung auf 7.4.4 läuft, befinden Sie sich in einer anderen, aber immer noch ernsten Situation, da CVE-2026-21643 diesen Zweig betrifft und auch in freier Wildbahn ausgenutzt wurde. Das FortiClient EMS-Risiko ist derzeit versionsspezifisch, und die Komprimierung benachbarter Schwachstellen zu einer einzigen unscharfen Nachricht ist die Art und Weise, wie Teams unter Druck schlechte Änderungsentscheidungen treffen. (FortiGuard-Laboratorien)

Die nächste Priorität ist die Klassifizierung der Exposition. Aus Fortinets eigenen Unterlagen geht hervor, dass die HTTPS-Fernverwaltung für den browserbasierten Zugriff aktiviert werden kann. Die Anleitung von Bishop Fox zur Schadensbegrenzung weist ausdrücklich darauf hin, dass die Schwachstelle einen direkten HTTPS-Zugang zum EMS-Webinterface auf Port 443 erfordert. Das bedeutet nicht "nur öffentliches Internet". Es bedeutet, dass jeder Pfad, über den ein Angreifer diese Schnittstelle erreichen kann, von Bedeutung ist. Eine von außen erreichbare Schnittstelle ist der offensichtlich schlimmste Fall, aber auch ein flacher interner Pfad von einer kompromittierten Workstation zu EMS ist kein akzeptables Risiko. (docs.fortinet.com)

Trennen Sie danach die Abhilfemaßnahmen von der Reaktion auf Vorfälle, lassen Sie sie aber parallel laufen. Abhilfe bedeutet Hotfixing oder Umstellung auf 7.4.7. Reaktion auf einen Vorfall bedeutet, Protokolle aufzubewahren, auf Konfigurationsabweichungen zu prüfen, administrative Änderungen zu untersuchen und zu entscheiden, ob die Serverintegrität noch vertrauenswürdig ist. Das Patch-Management schließt die Lücke. Es sagt Ihnen nicht, ob jemand die Lücke ausgenutzt hat, bevor Sie sie gefunden haben. Der Zeitplan von watchTowr macht diese Unterscheidung unvermeidlich, da die Ausnutzung vor der Offenlegung durch den Hersteller beobachtet wurde. (watchTowr)

Patching CVE-2026-35616 ohne neue Probleme zu schaffen

Die Notfallanleitung von Fortinet ist direkt: Wenden Sie den Hotfix auf 7.4.5 oder 7.4.6 jetzt an oder wechseln Sie zu 7.4.7, das den permanenten Fix enthält. Auf der Seite mit den behobenen Problemen von 7.4.6 wird CVE-2026-35616 als in FortiClient EMS 7.4.6 GA Hotfix 1, Build 7.4.6.2170.1277073und die Versionshinweise zu 7.4.7 zeigen, dass das CVE diese Version nicht mehr betrifft. Für 7.4.5 und 7.4.6 veröffentlichte Fortinet separate Hotfix-Installationsanweisungen, Beispielpaketnamen und SHA-256-Werte. (docs.fortinet.com)

Die Herstellerdokumente zeigen das gleiche Vorgehensmuster für beide betroffenen Zweige: Laden Sie das richtige Hotfix-Paket vom Fortinet-Support herunter, überprüfen Sie die SHA-256-Prüfsumme, wenden Sie es mit emscliund dann die installierten Hotfixes auflisten und bestätigen, dass der Status angewandt. Die Beispielprüfsummen von Fortinet auf den Hotfix-Seiten mit Versionshinweisen lauten 9f7d4f2c63176c5e766de8d0d6b0977af0b5795362d31ce6da72fcceb025d0c1 für das Beispiel des Hotfix-Pakets 7.4.5 und 3e76dc2b712a2988afd50459022f28e3fbda9a0a29f7f31674026620040cf2f5 für das Beispiel des Hotfix-Pakets 7.4.6. (docs.fortinet.com)

# Wenden Sie den Hersteller-Hotfix auf dem betroffenen EMS-Server an
sudo emscli execute hotfix --apply ./

# Überprüfen Sie, ob der Hotfix-Status angewendet wird
sudo emscli execute hotfix --list

Der exakte Dateiname sollte mit dem verzweigungsspezifischen Paket übereinstimmen, das Sie vom Fortinet-Support erhalten und anhand der veröffentlichten Prüfsumme überprüft haben. Die Hotfix-Anweisungen von Fortinet für 7.4.5 und 7.4.6 zeigen beide Folgendes emscli Durchfluss und Verwendung --Liste um den angewandten Status zu bestätigen. (docs.fortinet.com)

Machen Sie dies nicht zu einer Ausrede für einen schlampigen Upgrade-Sprung. In den Dokumentationen von Fortinet zu 7.4.6 und 7.4.7 werden auch Upgrade-Probleme aufgeführt, die für die Notfallplanung relevant sind. Auf der Seite mit den behobenen Problemen von 7.4.7 heißt es, dass nach dem Upgrade von 7.4.4 oder 7.4.5 auf 7.4.6 in einigen Umgebungen Probleme mit der RADIUS-Konfiguration für die Admin-Anmeldung, OAuth 2 Fabric Connectors und der geplanten Sicherung auf einem Remote-Server auftraten. Die 7.4.6-Upgrade-Dokumentation weist auf das gleiche Problem hin und besagt, dass bestimmte 7.4.4- oder 7.4.5-Umgebungen zunächst ein Hotfix-Paket installieren müssen, bevor sie das Upgrade auf 7.4.6 durchführen können. Unter dem Druck von Notfällen vereinfachen die Teams dies oft zu sehr, indem sie sagen: "Aktualisieren Sie einfach sofort auf den neuesten Zweig". Das mag immer noch die richtige Antwort sein, aber nicht, wenn dadurch die Kontrollen, auf die Sie sich bei der Verwaltung oder Wiederherstellung der Plattform verlassen, zerstört werden. (docs.fortinet.com)

Das sicherste Verhaltensmuster ist in der Regel ganz einfach. Wenn Sie mit 7.4.5 oder 7.4.6 arbeiten, wenden Sie den veröffentlichten Hotfix sofort an, um die aktive Belastung zu beenden. Planen Sie dann eine kontrollierte Umstellung auf 7.4.7, sobald die Umgebung stabil ist und die Validierung nach dem Hotfix abgeschlossen ist. Wenn Ihr Team einen einzigen Satz braucht, um damit zu arbeiten, dann ist es dieser: Hotfix, um sicher zu werden, dann Upgrade, um sauber zu werden. (FortiGuard-Laboratorien)

Validierung des Hotfixes und Suche nach Exploits

Das Schönste an einem Hersteller-Hotfix ist nicht, dass er existiert. Das Beste an einem Hotfix ist nicht, dass er existiert, sondern dass Sie überprüfen können, ob er das Verhalten an den entscheidenden Stellen verändert hat. Die nicht-destruktive Scanner-Logik von Bishop Fox ist nützlich, weil sie sich auf das Verhalten konzentriert, anstatt einen vollständigen Exploit zu versuchen. In ihrer Analyse gibt ein ungepatchtes Ziel eine andere Antwort, wenn eine gefälschte X-SSL-CLIENT-VERIFY: ERFOLGREICH Header vorhanden ist, als wenn er nicht vorhanden ist, weil der gefälschte Header Django erreicht und den Kontrollfluss verändert. Nach dem Hotfix entfernt der Apache den gefälschten Header, bevor er die Anwendung erreicht, und die Antworten stimmen überein. (Bischof Fuchs)

Das ist wichtig, weil es mit dem Design des Hotfixes übereinstimmt. Der Sinn der Notfallentschärfung besteht darin, die Vertrauensgrenze zwischen Proxy und Anwendung wiederherzustellen, indem fälschbare Header zurückgesetzt werden. Ihre Validierung sollte daher beweisen, dass vom Benutzer bereitgestellte Zertifikat-Authentifizierungs-Header das Serververhalten nicht mehr beeinflussen. Wenn Ihr Team eine sichere Prüfung auf eigenen Systemen einsetzt, lautet die Frage nicht: "Können wir das als Waffe einsetzen?" Die Frage lautet: "Kann ein gefälschter Header den Codepfad trotzdem ändern?" Das ist das korrekte Validierungsziel für den Patch, den Fortinet tatsächlich ausgeliefert hat. (Bischof Fuchs)

Hier gibt es auch eine umfassendere Lektion über Arbeitsabläufe. Bei der Behebung von Sicherheitslücken besteht der schwierige Teil normalerweise nicht darin, eine Zusammenfassung zu schreiben. Es geht darum, eine vertrauenswürdige Beweiskette von der Identifizierung der Schwachstelle bis zur Validierung der Abhilfemaßnahmen aufrechtzuerhalten. Das öffentliche Schreiben von Penligent über die KI-Pentest-Berichterstattung macht genau diesen Punkt deutlich: Ein Bericht ist nur dann nützlich, wenn er einen erneuten Test übersteht, und Beweise sind wichtiger als geschliffene Prosa. Dieser Standard passt nahezu perfekt zu CVE-2026-35616. Egal, ob Sie manuell oder mit einem automatisierten Arbeitsablauf validieren, was zählt, ist ein reproduzierbarer Vorher-Nachher-Bericht. (penligent.ai)

Das gleiche Prinzip findet sich in Penligents öffentlichem Schreiben über verifiziertes KI-Pentesting, das einen nützlichen Arbeitsablauf nicht als "das Modell glaubt, etwas gefunden zu haben" definiert, sondern als einen begrenzten, wiederholbaren Prozess, der den Zustand bewahrt und Behauptungen mit inspizierbaren Artefakten beweist. Bei Vorfällen auf der Managementebene wie diesem ist das die richtige Vorgehensweise: die Änderungshistorie, das Validierungsergebnis und der Status der Abhilfemaßnahmen müssen miteinander verbunden werden. Schnelle Schlussfolgerungen ohne nachvollziehbare Beweise führen dazu, dass sich Teams in falscher Sicherheit wiegen. (penligent.ai)

Die öffentlichen Aufzeichnungen über die von den Anbietern zur Verfügung gestellten IOCs sind dürftig, so dass die Erkennung eher auf Hypothesen als auf Signaturen beruhen sollte. WatchTowr weist ausdrücklich darauf hin, dass Fortinet in dem Zeitraum, in dem der Bericht verfasst wurde, keine Indikatoren für eine Kompromittierung veröffentlicht hat, und empfiehlt stattdessen die Überprüfung von Protokollen und die Überprüfung der Konfiguration. Dies sollte Verteidiger zu zwei Kategorien von Überprüfungen drängen: Beweise dafür, dass zertifikatsbezogene Header gefälscht wurden oder ein abnormales API-Verhalten auftrat, und Beweise dafür, dass EMS-kontrollierte Richtlinien oder Verwaltungsobjekte in einer Weise geändert wurden, die das Team nicht erklären kann. (watchTowr)

Hier sind zwei einfache Muster für die Protokollsuche, die sich eindeutig auf die aufgedeckte Grundursache beziehen. Es handelt sich dabei um Beispiele und nicht um vom Hersteller bereitgestellte Regeln, so dass die Feldnamen an Ihre Umgebung angepasst werden müssen.

# Beispiel 1, Suche nach gefälschten Zertifikat-Auth-Headern, die Ihre Web-Ebene erreichen
index=web OR index=proxy
(host="" OR dest="")
("X-SSL-CLIENT-VERIFY" ODER "X-SSL-CLIENT-CERT")
| stats count min(_time) as first_seen max(_time) as last_seen by src_ip, uri_path, http_status

# Beispiel 2, Suche nach plötzlichen Anomalien des EMS-API-Status bei Flüssen mit automatischer Freigabe
index=web OR index=proxy
(host="" OR dest="")
uri_path="/api/*"
(http_status=401 OR http_status=500)
| timechart span=15m count by http_status

Diese Muster ergeben sich direkt aus der Hauptursache und aus der Beobachtung von Bishop Fox, dass das Verhalten vor Hotfix abweichen kann, wenn gefälschte Zertifikatsheader Django erreichen. Wenn Ihre Log-Pipeline Anfrage-Header oder Reverse-Proxy-Normalisierung aufzeichnet, lohnt es sich, diese rückwirkend über das Exposure-Fenster laufen zu lassen. (Bischof Fuchs)

Wie die Reaktion auf Vorfälle aussehen sollte, wenn die IOCs dünn gesät sind

Wenn der Anbieter Ihnen kein ausgefeiltes IOC-Paket übergeben hat, müssen Sie die Untersuchung auf hochwertige Zustände und plausible Missbrauchspfade aufbauen. Die Checkliste von WatchTowr ist ein guter Ausgangspunkt: Überprüfen Sie die Sicherheitsrichtlinien für Endgeräte, die VPN-Konfigurationsprofile, die Regeln der Anwendungsfirewall, die Administratorkonten und Zugriffskontrollen sowie die Konfigurationen für die Endgerätekonformität auf nicht autorisierte Änderungen. Diese Liste ist gerade deshalb nützlich, weil sie nicht auf einer einzigen brüchigen Signatur basiert. Sie basiert auf dem, wofür ein kompromittiertes EMS wertvoll sein könnte. (watchTowr)

Fortinets eigene Diagnosewerkzeuge unterstützen eine stärker evidenzbasierte Reaktion, als vielen Teams bewusst ist. Im EMS-Administrationshandbuch heißt es, dass ein Diagnoseprotokollpaket CPU- und Speicher-Snapshots, PostgreSQL-Protokolle, Leistungsdaten und optional eine partielle Datenbanksicherung enthalten kann. Auf derselben Seite steht, dass das Paket in der GUI oder über EMSCLI erstellt werden kann, indem man Diagnose ausführen. In einem Fall wie CVE-2026-35616 macht das das Diagnosepaket zu einem Teil Ihres Triage-Muskelgedächtnisses und nicht zu einem nachträglichen Gedanken, den Sie nur öffnen, wenn der Support danach fragt. (docs.fortinet.com)

Das bedeutet nicht, dass das Diagnosepaket eine vollständige forensische Antwort darstellt. Es bedeutet, dass es Ihnen eine dokumentierte Möglichkeit bietet, den serverseitigen Zustand zu erhalten, während Sie entscheiden, ob die Integrität noch zu verteidigen ist. Wenn Sie den Verdacht haben, dass ein Angreifer mit EMS als Konfigurationsautorität interagiert hat, ist die frühzeitige Sicherung des datenbankgestützten Konfigurationsstatus und der zugehörigen Protokolle wertvoller, als sich später über Bezeichnungen zu streiten. Die Option der partiellen Datenbanksicherung ist besonders nützlich, um Vergleichspunkte zu erhalten, auch wenn Fortinet darauf hinweist, dass sie kein Ersatz für regelmäßige Sicherungen ist. (docs.fortinet.com)

Die schwierigste Entscheidung ist die, die Teams zu lange aufschieben: ob dem Server nach dem Patching noch vertraut werden kann. Die Anleitung von WatchTowr ist unverblümt und vernünftig. Wenn der Verdacht einer Kompromittierung besteht, sollten Sie nicht versuchen, den Server an Ort und Stelle zu bereinigen, es sei denn, Sie können die Integrität mit Sicherheit überprüfen. Stellen Sie ein Backup wieder her, das vor dem Zeitfenster der wahrscheinlichen Kompromittierung erstellt wurde, oder bauen Sie die EMS-Instanz neu auf und migrieren Sie die Daten. Für eine Verwaltungsebene ist die Wiederherstellung des Vertrauens wichtiger als der Stolz auf die Betriebszeit. Die Kosten für die Aufrechterhaltung eines vielleicht sauberen Controllers sind oft höher als die Kosten für eine einmalige Wiederherstellung. (watchTowr)

In diesem Fall ist der Zeitrahmen von entscheidender Bedeutung. Wenn die Ausbeutung am 31. März beobachtet wurde und der öffentliche Hinweis am 4. April eintraf, dann ist das Mindestzeitfenster für einen Rückblick nicht der Zeitpunkt, an dem wir die E-Mail des Anbieters zum ersten Mal gesehen haben. Es sind die Tage davor. Der richtige Ansatz besteht darin, die Überprüfung von Protokollen und Konfigurationen auf den frühesten plausiblen Zeitraum der Exposition auszurichten, nicht auf das Datum, an dem Sie intern davon erfahren. (watchTowr)

Eine praktische Ereignis-Reaktions-Matrix für dieses CVE sieht wie folgt aus:

Arbeitsbereich	Unmittelbare Frage	Zu bewahrende Beweise	Warum das wichtig ist
Version und Exposition	War EMS auf 7.4.5 oder 7.4.6 und erreichbar?	Versionsaufzeichnungen, Zugriffspfade, Firewall-Status	Stellen Sie fest, ob das CVE relevant und erreichbar war
Sanierung	Wurde der Hotfix angewendet und überprüft?	Ticket ändern, emscli --list Ausgabe, Überprüfung der Prüfsumme	Nachweis, dass die Exposition geschlossen ist
Zustand des Servers	Zeigen die Protokolle abnormales API-Verhalten oder Header-Missbrauch?	Web- und Proxy-Protokolle, Diagnosepaket	Testen Sie die aufgedeckte Ursache am realen Verkehr
Integrität der Steuerungsebene	Hat sich die Richtlinie, das Profil oder der Administratorstatus unerwartet geändert?	EMS-Konfigurationsverlauf, DB-gestützte Objekte, Kontoänderungen	Erkennung der Nutzung von EMS-Befugnissen nach der Kompromittierung
Vertrauen zurückgewinnen	Ist die Vor-Ort-Bereinigung vertrauenswürdig?	Sicherungsreihenfolge, Wiederherstellungsplan, Validierungsergebnisse	Entscheiden Sie, ob Sie wiederherstellen oder neu aufbauen wollen

Die Matrix spiegelt die öffentlichen Leitlinien und die eigenen dokumentierten Diagnosefähigkeiten des Produkts wider. (watchTowr)

Härtung von FortiClient EMS nach dem Notfall-Patch

Patching schließt die heutige Lücke. Die Härtung bestimmt, ob die nächste Schwachstelle in der Verwaltungsebene die gleiche Geschichte ist. Die erste Kontrolle ist die Erreichbarkeit des Netzwerks. In der Anleitung von Bishop Fox zur Schadensbegrenzung heißt es, dass die Schwachstelle einen direkten HTTPS-Zugang zur EMS-Webschnittstelle auf Port 443 erfordert, und Fortinet dokumentiert, dass die HTTPS-Fernverwaltung eine konfigurierbare Funktion ist. Diese Kombination weist auf eine offensichtliche Grundregel hin: Wenn Administratoren keinen breiten browserbasierten Zugriff von außerhalb streng kontrollierter Verwaltungspfade benötigen, sollten sie diesen nicht freigeben. Beschränken Sie die Schnittstelle auf dedizierte Verwaltungsnetzwerke oder gleichwertige eingeschränkte Pfade. (Bischof Fuchs)

Die zweite Kontrolle ist die administrative Integrität bei Richtlinienänderungen. FortiClient EMS ist nicht nur ein Server, der Daten speichert. Es ist ein System zur Verteilung von Richtlinien und zur Kontrolle von Endpunkten. Das bedeutet, dass Änderungen an Endpunktprofilen, Fernzugriffseinstellungen, Firewall-Verhalten und administrativen Konten als erstklassige Sicherheitsereignisse auditierbar sein sollten. Viele Teams protokollieren die Authentifizierung gut genug und die Konfiguration schlecht. In einer EMS-Umgebung ist das genau das Gegenteil. Ein perfektes Anmeldeprotokoll nützt nicht viel, wenn böswillige Abweichungen von den Richtlinien unsichtbar sind. (docs.fortinet.com)

Die dritte Kontrolle ist die Versionsdisziplin. In den letzten Monaten gab es zwei aktiv ausgenutzte, nicht authentifizierte kritische Probleme in benachbarten FortiClient EMS-Versionen. Das sollte die Denkweise der Teams über den Patching-Rhythmus für dieses Produkt ändern. Die Entscheidung sollte nicht lauten: "Wir werden EMS aktualisieren, wenn es ein Wartungsfenster gibt". Vielmehr sollte die Entscheidung lauten: "EMS ist eine hochwertige Verwaltungsebene und gehört auf die gleiche beschleunigte Überprüfungsschiene wie exponierte Identitäts-, VPN- und Admin-Edge-Systeme." Die Rolle des Produkts bei der Endpunktverwaltung rechtfertigt diese Behandlung. (watchTowr)

Die vierte Kontrolle ist die routinemäßige Wiederholungsprüfung. Dies ist der Teil, den die Organisationen überspringen, wenn der Pager verstummt. Ein Hotfix, der angewendet, aber nicht verifiziert wurde, ist besser als nichts, aber es ist keine fertige Reaktion. Zumindest sollten die Teams bestätigen, dass der Patch-Status in EMS sichtbar ist, dass die Schnittstelle nach Möglichkeit nicht mehr allgemein erreichbar ist und dass eine sichere Validierungsmethode zeigt, dass das Header-Spoofing-Verhalten verschwunden ist. In Umgebungen mit mehreren Verwaltungsoberflächen ist ein wiederholbarer Wiederholungstest-Workflow wichtiger als ein weiteres Foliendokument (Bischof Fuchs)

CVE-2026-21643 und warum FortiClient EMS jetzt ein anderes Risikomodell verdient

CVE-2026-35616 ist wichtiger, wenn Sie es als Teil eines Musters verstehen. Fortinets Advisory vom Februar 2026 zu CVE-2026-21643 beschreibt eine nicht authentifizierte SQL-Injektion in FortiClient EMS 7.4.4, die unautorisierten Code oder Befehle über speziell gestaltete HTTP-Anfragen ermöglichen kann. Fortinet sagte auch, dass dieses Problem in freier Wildbahn ausgenutzt wurde, und dass der Lösungsweg darin besteht, 7.4.4 auf 7.4.5 oder höher zu verschieben. Die Zweige 7.2 und 8.0 waren nicht betroffen. (FortiGuard-Laboratorien)

Die technischen Klassen sind unterschiedlich. CVE-2026-21643 war ein SQL-Injektionsproblem. CVE-2026-35616 ist eine unsachgemäße Zugriffskontrolle und ein Fehler in der Vertrauensgrenze zwischen Zertifikat und Authentifizierung. Aber aus der Perspektive des Risikomodells reimen sie sich auf eine Weise, die wichtiger ist als die Bezeichnungen. Beide betrafen die EMS-Verwaltungsebene. Beide waren für nicht authentifizierte Angreifer über das Netzwerk erreichbar. Beide wurden nachweislich ausgenutzt. Beide zwingen Verteidiger dazu, sich Gedanken darüber zu machen, was passiert, wenn die Steuerungsebene des Endpunkts und nicht die Endpunkte selbst zum Einstiegspunkt für den Angreifer werden. (FortiGuard-Laboratorien)

Die Analyse von CVE-2026-35616 durch Bishop Fox macht die architektonische Kontinuität deutlich. Ihr Bericht besagt, dass dieselbe Middleware-Architektur, das OpenApi-Dekorator-System und die PostgreSQL-Verbindungsschicht, die sie für CVE-2026-21643 zurückentwickelt haben, auch bei diesem Fehler eine zentrale Rolle spielen. Das bedeutet nicht, dass die Fehler identisch oder notwendigerweise verkettbar sind. Es bedeutet, dass die Verteidiger aufhören sollten, diese als unverbundene Unfälle zu behandeln, und anfangen sollten, FortiClient EMS als ein System zu behandeln, dessen exponierte Kontrollpfade eine aggressive Prüfung verdienen. (Bischof Fuchs)

Ein praktischer Vergleich hilft:

Kategorie	CVE-2026-21643	CVE-2026-35616
Klasse der Anfälligkeit	Unauthentifizierte SQL-Injektion	Unzulässige Zugriffskontrolle und Umgehung der API-Authentifizierung
Betroffener Versionsbereich	7.4.4	7.4.5 bis 7.4.6
Status der Ausnutzung des Anbieters	Beobachtete Ausnutzung in freier Wildbahn	Beobachtete Ausnutzung in freier Wildbahn
Pfad festlegen	Upgrade auf 7.4.5 oder höher	Wenden Sie den Zweig Hotfix sofort an oder wechseln Sie zu 7.4.7
Lektion für Verteidiger	7.4.4 nicht stehen lassen	Gehen Sie nicht davon aus, dass der "korrigierte" Nachfolgezweig ohne erneute Prüfung sicher ist.

Die Tabelle fasst die offiziellen Fortinet-Advisories und den anschließenden Korrekturpfad für die späteren CVEs zusammen. (FortiGuard-Laboratorien)

Dieses Muster sollte auch Ihre Änderungsplanung prägen. Stellen Sie sich die Verwirrung in einem großen Unternehmen vor, das verschiedene EMS-Versionen in verschiedenen Regionen einsetzt. Ein Team weiß, dass 7.4.4 wegen SQLi schlecht ist, führt ein Upgrade auf 7.4.5 durch und erfährt dann Tage später, dass 7.4.5 selbst in den betroffenen Bereich für eine aktiv ausgenutzte Umgehung der Autorisierung fällt. Das ist kein akademischer Sonderfall. Es ist genau die Art von Situation, in der Sicherheits-, Infrastruktur- und Änderungskontrollteams anfangen, mit veralteten mentalen Modellen zu arbeiten. Der einzige Schutz dagegen ist eine disziplinierte Versionsinventur und die Annahme, dass die Verwaltungsebene bei der Sicherheitsüberprüfung auf die Überholspur gehört. (FortiGuard-Laboratorien)

Fehler, die Teams in den ersten 24 Stunden machen können

Der erste Fehler besteht darin, dieses Problem als ein Problem der Bewertung und nicht als ein Problem der Ausnutzung zu behandeln. Ob Sie sich nun auf 9.1 in der Empfehlung oder 9.8 im angezeigten CNA-Vektor des NVD stützen, das Problem ist bereits in KEV enthalten und wird bereits ausgenutzt. Es bringt nichts, über Dezimalzahlen zu debattieren, während die Verwaltungsebene ungeschützt bleibt. (FortiGuard-Laboratorien)

Der zweite Fehler besteht darin, nur ein Feld auf einer Seite zu lesen. In der Zusammenfassung des Fortinet-Hinweises heißt es, dass eine Ausnutzung in freier Wildbahn beobachtet wurde, obwohl der Metadatenblock immer noch "Known Exploited No" anzeigt. Sicherheitsteams, die auf der Grundlage von ausgewerteten Feldern operieren, ohne den Text des Hinweises zu lesen, sind besonders anfällig für diese Art von Fehlern bei schnelllebigen Ereignissen. (FortiGuard-Laboratorien)

Der dritte Fehler besteht darin, nur Patches zu installieren und damit aufzuhören. Es handelt sich um eine Schwachstelle auf der Verwaltungsebene mit einer dokumentierten Ursache in gefälschten Authentifizierungs-Headern und einem bekannten Expositionsfenster vor der öffentlichen Bekanntgabe. Diese Kombination sollte immer ein zweites Verfahren auslösen: Validierung der Korrektur und Überprüfung der Konfigurationsautorität, die EMS während des anfälligen Zeitraums innehatte. (watchTowr)

Der vierte Fehler besteht darin, dass alle nahe gelegenen FortiClient EMS-Probleme in einem Memo und einem Change Ticket zusammengefasst wurden. CVE-2026-21643 betrifft 7.4.4. CVE-2026-35616 betrifft 7.4.5 bis 7.4.6. Der Behebungspfad und die Dringlichkeit unterscheiden sich je nach Zweig, und der 7.4.6-Upgrade-Pfad hatte seine eigenen operativen Vorbehalte. Schlampiges Versionsdenken führt dazu, dass sich Ausfallrisiko und Sicherheitsrisiko gegenseitig verstärken. (FortiGuard-Laboratorien)

Der fünfte Fehler ist die Annahme, dass Cloud- und selbstverwaltete Implementierungen im Reaktionsplan austauschbar sind. In der Empfehlung von Fortinet heißt es ausdrücklich, dass FortiClient Cloud und FortiSASE vom Anbieter behoben wurden und keine Maßnahmen seitens des Kunden für dieses Problem erforderlich sind. Wenn Sie sowohl vom Anbieter gehostete als auch selbst verwaltete Produkte verwalten, müssen Sie bei der Kommunikation von Vorfällen diese Unterscheidung beibehalten. (FortiGuard-Laboratorien)

CVE-2026-35616 zum Mitnehmen

Die wichtigste Erkenntnis aus CVE-2026-35616 ist nicht nur, dass eine schlechte Umgehung der Autorisierung gefunden und sofort behoben wurde. Es geht darum, dass FortiClient EMS jetzt eindeutig zu den gleichen Risiken gehört wie andere exponierte Steuerungsebenen, die das Vertrauen des Unternehmens, die Endpunktsicherheit und das Fernzugriffsverhalten beeinflussen können. Die Dokumentation von Fortinet selbst macht deutlich, wie viel Autorität EMS besitzt. Die FortiClient EMS-Hinweise der letzten Monate machen deutlich, dass auch Angreifer diese Autorität verstehen. (docs.fortinet.com)

Wenn Sie ein selbstverwaltetes EMS unter 7.4.5 oder 7.4.6 betreiben, sind die unmittelbaren Prioritäten einfach: Wenden Sie den veröffentlichten Hotfix an oder wechseln Sie zu 7.4.7, überprüfen Sie das Verhalten der Abhilfemaßnahmen, sichern und überprüfen Sie serverseitige Beweise, überprüfen Sie hochwertige Konfigurationszustände und entscheiden Sie ehrlich, ob die Instanz noch vertrauenswürdig ist. Wenn Ihre EMS-Schnittstelle während des Ausnutzungszeitraums erreichbar war, behandeln Sie die Reaktion wie einen Sicherheitsvorfall auf der Steuerungsebene und nicht wie eine Routinewartung. (FortiGuard-Laboratorien)

Weiterführende Literatur und Referenzlinks

Fortinet PSIRT-Hinweis für CVE-2026-35616, betroffene Versionen, Erklärung zur Ausnutzung, Hotfix-Anleitung und Cloud-Service-Status. (FortiGuard-Laboratorien)

NVD-Eintrag für CVE-2026-35616, einschließlich KEV-Status, Fälligkeitsdatum, CWE und angezeigtem CNA-Vektor. (nvd.nist.gov)

Fortinet 7.4.5 Hotfix-Anweisungen, einschließlich Prüfsumme und emscli fließen. (docs.fortinet.com)

Fortinet 7.4.6 Hotfix-Anweisungen und Seite mit behobenen Problemen, die den Hotfix-Build identifiziert, der das CVE behebt. (docs.fortinet.com)

Die Seite mit den behobenen Problemen von Fortinet 7.4.7 zeigt, dass das Problem diese Version nicht mehr betrifft. (docs.fortinet.com)

Technische Analyse der Ursache, des Trusted-Header-Problems, der Schwachstelle bei der Validierung der Zertifikatskette und der nicht-destruktiven Validierungslogik durch Bishop Fox. (Bischof Fuchs)

watchTowrs Zeitplan für die Ausnutzung von Sicherheitslücken und Anleitungen für die Reaktion auf Vorfälle, die sich auf die Prüfung der Konfiguration und die Wiederherstellung des Vertrauens konzentrieren. (watchTowr)

FortiClient EMS-Verwaltungsdokumentation für die zentrale Endpunktverwaltung, HTTPS-Remote-Verwaltung, Endpunktprofile, Bereitstellungsverhalten und Diagnosepaketgenerierung. (docs.fortinet.com)

Fortinet PSIRT-Beratung für CVE-2026-21643, die nützlich ist, um zu verstehen, warum EMS jetzt als ein Risiko mit höherer Priorität auf der Verwaltungsebene behandelt werden sollte. (FortiGuard-Laboratorien)

Penligents öffentlicher Artikel über KI-Pentestberichte und beweisgestützte erneute Tests, die für die Post-Patch-Validierung und vertretbare Berichterstattung relevant sind. (penligent.ai)

Penligents öffentlicher Artikel über verifizierte KI-Pentesting-Workflows, der für die wiederholbare Validierung von Abhilfemaßnahmen für exponierte Verwaltungssysteme relevant ist. (penligent.ai)