Fortinet Patch Management im Mittelstand: Firmware-Updates ohne Produktionsausfall

Ein mittelständisches Produktionsunternehmen betreibt seit Jahren dieselbe FortiGate-Firewall. Die Konfiguration läuft stabil, niemand beschwert sich — also rührt niemand daran. Das ist keine Nachlässigkeit, sondern eine verbreitete Entscheidung: Wer einmal einen ungeplanten Ausfall erlebt hat, weil ein Update schiefging, denkt zweimal nach, bevor er das nächste einspielt.

Das Problem ist nur: Diese Zurückhaltung hat seit September 2026 einen messbaren Preis. CISA hat innerhalb von sechs Wochen drei Fortinet-Schwachstellen in den Katalog aktiv ausgebeuteter Sicherheitslücken aufgenommen. Die Frist für US-Bundesbehörden betrug in jedem Fall drei Tage. Mittelständische Unternehmen in Deutschland unterliegen diesen Fristen zwar nicht — aber die Lücken sind dieselben, und die Angreifer kennen den KEV-Katalog genauso gut wie die Verteidiger.

Dieser Artikel zeigt, wie ein geplanter Firmware-Patching-Prozess für Fortinet-Geräte aussieht: mit Wartungsfenster, Backup, Konfigurationsexport und einem getesteten Rückfallplan — und warum dieser Prozess den Unterschied zwischen einem kontrollierten Update und einem ungeplanten Ausfall macht.

Drei aktiv ausgenutzte Fortinet-Lücken, die Sie jetzt kennen müssen

Stand 25. Oktober 2026 stehen drei Fortinet-Schwachstellen im CISA Known Exploited Vulnerabilities (KEV)-Katalog, alle aufgenommen zwischen September und Oktober 2026. Die Aufnahme bedeutet per Definition: CISA hat Belege für aktive Ausnutzung „in the wild".

CVE-2026-104286 — FortiMail, CVSS 9,8

Die gefährlichste der drei Lücken. Ein Angreifer kann ohne jede Authentifizierung über präparierte HTTP- oder HTTPS-Anfragen beliebige Dateien auf dem System schreiben. FortiMail steht in KMU typischerweise am Perimeter und ist aus dem Internet erreichbar.

Betroffene Versionen und Fixes laut FortiGuard-Advisory FG-IR-26-175 (veröffentlicht 01.10.2026):

• FortiMail 8.0.0–8.0.1 → Update auf 8.0.2 oder höher
• FortiMail 7.6.0–7.6.6 → Update auf 7.6.7 oder höher
• FortiMail 7.4.0–7.4.8 → Update auf 7.4.9 oder höher
• FortiMail 7.2.x → Wechsel auf Branch 7.4 oder höher erforderlich

CVE-2025-25249 — Heap Buffer Overflow, CVSS 8,1

Ein Heap-based Buffer Overflow, der die Ausführung unautorisierten Codes über das Netz ermöglicht. Der cw_acd-Dienst gehört zur Verwaltung von Access Points und Switches — das ist eine Einschätzung, keine offizielle Herstelleraussage. Der Netzwerkzugang macht diese Lücke für exponierte Geräte besonders relevant.

Betroffene FortiOS-Versionen und Fixes laut FG-IR-25-084 (veröffentlicht 13.01.2026):

• FortiOS 7.6.0–7.6.3 → Update auf 7.6.4 oder höher
• FortiOS 7.4.0–7.4.8 → Update auf 7.4.9 oder höher
• FortiOS 7.2.0–7.2.11 → Update auf 7.2.12 oder höher
• FortiOS 7.0.0–7.0.17 → Update auf 7.0.18 oder höher
• FortiOS 6.4.x → Wechsel auf korrigierte Version erforderlich

CVE-2025-61624 — Path Traversal via CLI, CVSS 6,0

Diese Lücke setzt einen bereits vorhandenen Admin-Account mit Schreibrechten voraus. Sie ist also keine klassische „Fremder übernimmt die Firewall"-Lücke, sondern relevant bei gestohlenen Admin-Zugangsdaten, Innentätern oder nach einer Vorkompromittierung. Der Patch existiert seit April 2026 — die KEV-Aufnahme im Oktober 2026 zeigt, dass ungepatchte Geräte inzwischen aktiv ausgenutzt werden.

Betroffene Versionen und Fixes laut FG-IR-26-122:

• FortiOS 7.6.0–7.6.4 → Update auf 7.6.5 oder höher
• FortiOS 7.4.0–7.4.9 → Update auf 7.4.10 oder höher
• FortiOS 7.2 / 7.0 / 6.4 → Versionswechsel erforderlich (kein Fix im selben Branch)
• FortiProxy 7.6.0–7.6.4 → Update auf 7.6.5 oder höher
• FortiProxy 7.4.0–7.4.11 → Update auf 7.4.12 oder höher
• FortiSwitchManager 7.2.0–7.2.7 → Update auf 7.2.8 oder höher
• FortiSwitchManager 7.0.0–7.0.6 → Update auf 7.0.7 oder höher

Wichtige Konsequenz für FortiOS: Wer beide FortiOS-Lücken in einem Schritt schließen will, braucht mindestens 7.6.5 bzw. 7.4.10. Auf den Branches 7.2, 7.0 und 6.4 gibt es für CVE-2025-61624 keinen Patch — dort ist ein Branchwechsel unumgänglich. Fortinet stellt für den Upgrade-Pfad das offizielle Upgrade-Tool unter docs.fortinet.com/upgrade-tool bereit.

Warum „Never change a running system" hier nicht greift

Der Einwand ist verständlich und war lange Zeit vernünftig. Perimeter-Geräte laufen in KMU oft jahrelang stabil, und jede Änderung trägt ein Risiko. Das Problem: Das Risiko hat sich verlagert.

Wer eine FortiGate auf FortiOS 7.4.8 betreibt, hat eine bekannte, öffentlich dokumentierte Schwachstelle (CVE-2025-25249, CVE-2025-61624) mit einem Gerät im Internet. Angreifer kennen den KEV-Katalog und scannen systematisch nach ungepatchen Versionen. Das ist kein theoretisches Risiko mehr — CISA dokumentiert aktive Ausnutzung.

Das eigentliche Argument gegen das Update lautet meistens: „Wir wissen nicht, ob danach alles noch läuft." Das ist ein Planungsproblem, kein gutes Argument gegen das Update selbst. Mit einem strukturierten Prozess lässt sich dieses Risiko auf ein beherrschbares Maß reduzieren — nicht auf null, aber auf ein Niveau, das vertretbar ist.

Der Prozess: Firmware-Update mit Wartungsfenster, Backup und Rückfallplan

Ein Firmware-Update auf einer produktiven Firewall ist kein 20-Minuten-Job. Es ist ein geordneter Ablauf mit fünf Phasen, die vor dem eigentlichen Update beginnen.

Phase 1: Inventar und Versionsprüfung

Bevor ein Update geplant wird, muss klar sein, was überhaupt läuft. Für Fortinet-Geräte bedeutet das:

• Aktuelle Firmware-Version je Gerät (FortiGate, FortiProxy, FortiMail, FortiSwitchManager) dokumentieren
• Abgleich mit den Advisory-Tabellen: Welche Geräte sind betroffen, welche nicht?
• Upgrade-Pfad prüfen: Ist ein direktes Update möglich, oder ist ein Zwischenschritt erforderlich?
• Fortinets Upgrade-Tool auf docs.fortinet.com/upgrade-tool zeigt empfohlene Pfade je Quell- und Zielversion

Dieser Schritt klingt trivial, ist es in der Praxis aber nicht. In mittelständischen Umgebungen laufen oft mehrere Fortinet-Geräte an verschiedenen Standorten, teilweise mit unterschiedlichen Firmware-Ständen. Ein vollständiges Inventar ist die Voraussetzung für alles Weitere.

Phase 2: Konfigurationsbackup und Config-Export

Vor jedem Firmware-Update gehört ein vollständiges Backup der Gerätekonfiguration. Auf FortiGate-Geräten umfasst das:

1. Full Configuration Backup über das Web-GUI (System → Backup) oder per CLI: execute backup full-config management-station <name>
2. Export der Konfigurationsdatei auf einen externen Speicher — nicht nur auf das Gerät selbst
3. Dokumentation des aktuellen Firmware-Stands, der Lizenz-Status und der aktiven Policy-Sätze
4. Bei HA-Clustern: Sicherung der Cluster-Konfiguration und Notiz des aktuellen Primary-Members

Das Backup hat zwei Funktionen: Es ermöglicht die Wiederherstellung nach einem fehlgeschlagenen Update und dient als Nachweis des Ausgangszustands — relevant für die Patch-Historie und für mögliche Compliance-Anforderungen.

Phase 3: Wartungsfenster planen und kommunizieren

Ein Firmware-Update auf einer produktiven Firewall verursacht mindestens einen kurzen Neustart des Geräts. Die tatsächliche Downtime hängt von der Hardware, der Konfigurationsgröße und dem Versionsabstand ab. Realistisch sind einige Minuten pro Gerät — bei HA-Clustern (High Availability) kann der Failover-Betrieb den Ausfall auf Sekunden begrenzen, wenn das Cluster korrekt konfiguriert ist. Keine Versprechen zu konkreten Zeiten: Das hängt von der jeweiligen Umgebung ab.

Ein Wartungsfenster sollte folgende Bedingungen erfüllen:

• Zeitraum außerhalb der Kernarbeitszeit (Nacht, Wochenende)
• Ankündigung an alle Betroffenen mindestens 48 Stunden vorher
• Klarheit darüber, welche Systeme und Standorte betroffen sind
• Helpdesk oder Ansprechpartner für den Zeitraum des Wartungsfensters benennen
• Rückfallplan schriftlich dokumentiert und dem Team bekannt

Phase 4: Das Update durchführen — Schritt für Schritt

Der eigentliche Update-Vorgang folgt einem festen Ablauf:

1. Backup noch einmal bestätigen (Zeitstempel prüfen)
2. Firmware-Image von Fortinets offiziellem Download-Portal herunterladen und SHA-256-Prüfsumme verifizieren
3. Update über das Web-GUI unter System → Firmware einspielen oder per TFTP/SCP
4. Gerät neu starten, Bootvorgang beobachten (Konsolen-Zugang oder IPMI empfohlen)
5. Nach dem Reboot: Konfiguration verifizieren — Policies, Routing, VPN-Tunnel, DNS
6. Konnektivitätstests: Können die wichtigsten Systeme hinter der Firewall noch erreicht werden?
7. Wenn alles grün: Wartungsfenster schließen, Status dokumentieren

Bei HA-Clustern wird üblicherweise zuerst das Secondary-Member aktualisiert, dann ein manueller Failover durchgeführt, und anschließend das (nun Secondary) ursprüngliche Primary-Member aktualisiert. So bleibt der Produktivbetrieb durchgehend auf einem gepatchten Gerät.

Phase 5: Der Rückfallplan — und wann er greift

Ein Rückfallplan ist keine Schwäche, sondern Bestandteil jedes professionellen Änderungsmanagements. Er definiert vorab:

• Welche Kriterien lösen einen Rollback aus? (Konfiguration nicht geladen, kritische Systeme nicht erreichbar, VPN-Tunnel bleiben down)
• Wer entscheidet über den Rollback und innerhalb welcher Zeitgrenze?
• Wie wird die vorherige Firmware wiederhergestellt? (Fortinet unterstützt das Zurückspielen einer älteren Firmware, sofern das Konfigurationsformat kompatibel ist — das muss vorab geprüft werden)
• Wann wird das Wartungsfenster verlängert, und wann wird abgebrochen?

In der Praxis bedeutet das: Der Rollback-Ablauf wird dokumentiert, bevor das Wartungsfenster beginnt — nicht währenddessen, wenn der Druck hoch ist.

Hypothetisches Beispiel: Ein produzierender KMU-Betrieb

Nehmen wir als hypothetisches Beispiel einen mittelständischen Fertigungsbetrieb mit 80 Mitarbeitern, zwei Standorten und einer FortiGate 60F als Hauptfirewall (FortiOS 7.4.7). Der Betrieb ist an Werktagen von 6 bis 22 Uhr aktiv, samstags bis 14 Uhr.

Die Ausgangslage: Beide Lücken CVE-2025-25249 und CVE-2025-61624 betreffen die laufende Firmware. Ein direktes Update auf 7.4.10 ist laut Upgrade-Tool ohne Zwischenstufe möglich.

Der Ablauf in diesem Beispiel:

• Freitag: Config-Backup erstellt, Firmware-Image heruntergeladen und Prüfsumme verifiziert, Team informiert
• Samstag 15:00 Uhr: Wartungsfenster beginnt — nach Produktionsschluss, ein Techniker vor Ort, einer remote
• Update eingespielt, Neustart dauert knapp 4 Minuten
• Konfigurationsprüfung: Policies korrekt, VPN-Tunnel zum zweiten Standort aktiv, ERP-Zugriff funktioniert
• 15:45 Uhr: Wartungsfenster geschlossen, Patch-Stand dokumentiert

Das ist kein Extremfall. Es ist ein realistischer Ablauf für ein Gerät ohne HA, wenn die Vorbereitung sitzt.

Was ein geplanter Prozess gegenüber einem Ad-hoc-Update wirklich kostet

Der häufigste Einwand gegen strukturiertes Patch Management ist der Aufwand. Das ist ein echter Punkt — aber er verdient eine differenzierte Betrachtung.

Der Aufwand für einen strukturierten Prozess ist real. Er ist aber einmalig für die Prozessdefinition und danach Routine. Ungeplante Ausfälle sind selten Routine — sie sind Krisen.

Management-Zugänge absichern: Was parallel zum Update gehört

Das Update schließt die bekannten Lücken. Es löst aber kein strukturelles Problem, wenn der Verwaltungszugang zur Firewall selbst schlecht abgesichert ist — und CVE-2025-61624 macht genau das deutlich: Eine Path-Traversal-Lücke, die Admin-Rechte voraussetzt, wird erst dann ausgenutzt, wenn ein Angreifer an diese Rechte gelangt ist.

Folgende Maßnahmen gehören parallel oder unmittelbar nach dem Update auf die Liste:

• Web-GUI und CLI der Firewall nicht aus dem offenen Internet erreichbar lassen. Verwaltungszugänge gehören in ein separates Management-VLAN oder hinter eine VPN-Verbindung.
• Admin-Konten überprüfen. Gibt es Standard-Konten, inaktive Accounts oder Konten mit unnötig breiten Rechten? Jede nicht benötigte Schreibberechtigung ist eine potenzielle Angriffsfläche.
• Zwei-Faktor-Authentifizierung für Admin-Zugänge. FortiOS unterstützt TOTP und FortiToken — das ist kein großer Konfigurationsaufwand, verringert aber das Risiko durch gestohlene Zugangsdaten erheblich.
• Logging und Alerting aktivieren. Unauthentifizierte Zugriffsversuche auf das Management-Interface sollten sichtbar sein — und idealerweise einen Alert auslösen, bevor sie erfolgreich sind.

Diese Maßnahmen sind kein Ersatz für das Firmware-Update. Sie sind Ergänzungen, die zusammen eine vertretbare Grundlage ergeben.

Wann Sie das selbst machen können — und wann nicht

Firmware-Updates auf Fortinet-Geräten sind technisch nicht übermäßig komplex, wenn die Umgebung überschaubar ist: ein oder zwei Geräte, keine HA-Cluster, direkter Pfad zur Zielversion, bekannte Konfiguration.

Wer intern die Kapazität hat, den oben beschriebenen Prozess vollständig abzubilden — inklusive Backup, Konfigurationsprüfung und dokumentiertem Rückfallplan — kann das in der Regel selbst umsetzen. Dann sind die Voraussetzungen: Zeit im Wartungsfenster, Konsolen- oder Out-of-Band-Zugang zum Gerät und ein zweiter Techniker, der im Notfall einspringen kann.

Der Prozess wird aufwändiger, wenn:

• mehrere Geräte an verschiedenen Standorten gleichzeitig gepatcht werden müssen
• der Firmware-Branch gewechselt werden muss (z. B. FortiOS 7.2 auf 7.4)
• HA-Cluster konfiguriert sind und die Failover-Logik verstanden werden muss
• keine aktuelle Konfigurationsdokumentation vorhanden ist
• niemand intern Erfahrung mit dem Verhalten nach einem Fortinet-Firmware-Update hat

In diesen Fällen ist der Aufwand nicht das eigentliche Problem — das Risiko eines Fehlers ohne funktionierenden Rückfallplan ist es.

Patch Management als laufender Prozess, nicht als Einmalereignis

Ein einzelnes Update behebt die aktuellen Lücken. Es etabliert keinen Prozess. Fortinet veröffentlicht regelmäßig neue Advisories, und der KEV-Katalog wächst kontinuierlich. Zwischen September und Oktober 2026 kamen allein drei Fortinet-Einträge hinzu — der Hersteller-Patch für CVE-2025-61624 lag dabei bereits seit April 2026 vor, sechs Monate, bevor CISA die aktive Ausnutzung bestätigte.

Ein belastbares Patch Management für Netzwerk- und Perimeter-Geräte umfasst mindestens:

• Regelmäßiger Advisory-Check: FortiGuard PSIRT und CISA KEV-Feed mindestens monatlich prüfen
• Versionsinventar aktuell halten: Wer welche Firmware wo betreibt, muss jederzeit abrufbar sein
• Patch-Zyklen definieren: Kritische Lücken (CVSS ≥ 9,0 oder KEV-Eintrag) bekommen Priorität und ein Wartungsfenster innerhalb definierter Fristen
• Patch-Historie dokumentieren: Wann wurde welche Version auf welchem Gerät eingespielt? Wer hat es gemacht? Das ist nicht nur für Audits relevant, sondern auch dann, wenn ein Problem auftritt und jemand wissen muss, was zuletzt geändert wurde.

Für KMU, die keine eigene IT-Abteilung mit dediziertem Netzwerksecurity-Know-how haben, ist dieser laufende Prozess der Punkt, an dem externe Unterstützung tatsächlich Zeit und Risiko spart — nicht das einzelne Update.

Unsere IT-Systembetreuung umfasst genau diesen laufenden Prozess: Inventar, Advisory-Monitoring, geplante Wartungsfenster mit Backup und Rückfallplan sowie eine nachvollziehbare Patch-Historie je Gerät. Wenn Sie wissen möchten, wie das für Ihre Fortinet-Umgebung konkret aussehen würde, sprechen Sie uns an.

Nächster Schritt: Prüfen Sie jetzt Ihre Firmware-Stände

Wenn Sie FortiGate, FortiMail, FortiProxy oder FortiSwitchManager betreiben, lohnt es sich, heute noch die laufenden Versionen gegen die Advisory-Tabellen oben abzugleichen. Der Aufwand dafür beträgt wenige Minuten. Der Aufwand, einen ungeplanten Ausfall nach einer Kompromittierung zu beheben, ist deutlich größer.

Wir unterstützen KMU dabei, Fortinet-Geräte strukturiert zu patchen — mit Wartungsfenster, dokumentiertem Ablauf und getesteten Rückfallplänen. Sprechen Sie uns an, wenn Sie wissen möchten, ob Ihre aktuelle Firmware noch im sicheren Bereich liegt und wie ein Update-Prozess für Ihre Umgebung aussehen würde.

Wartung anfragen →