{"schema_version":"1.0","service":"Publicasta","type":"article","id":788,"slug":"fortimail_cve_2026_104286_active_exploitation_response","title":"FortiMail CVE-2026-104286 wird aktiv ausgenutzt: Gateway patchen und anschließend prüfen, was geschrieben werden konnte","excerpt":"CVE-2026-104286 ermöglicht unauthentifizierten Angreifern das Schreiben beliebiger Dateien auf betroffenen FortiMail-Systemen. Jetzt zählen schnelle Absicherung, Beweissicherung und eine Untersuchung auf mögliche Kompromittierung.","language":"de","default_language":"en","canonical_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response?lang=de","image":{"url":"https://publicasta.com/storage/projects/9/pages/788/2026/10/94af6eb5-e126-4a6e-a51f-e704f9bc2b66.webp","alt":"Redaktionelle Illustration eines Unternehmens-Mail-Sicherheitsgateways bei der Reaktion auf eine aktiv ausgenutzte Schwachstelle, mit kritischer Warnung, Patch-Anzeigen und forensischen Netzwerkspuren."},"publisher":{"id":9,"slug":"cybersecurity","name":"Cybersicherheit ohne Panik","url":"https://publicasta.com/cybersecurity"},"author":{"name":"Anton R"},"published_at":"2026-10-08T13:38:57+00:00","updated_at":"2026-10-08T13:38:57+00:00","content_markdown":"Eine kritische Fortinet-FortiMail-Schwachstelle gehört inzwischen zu den Problemen, bei denen Verzögerungen ein zweites Risiko schaffen. CVE-2026-104286 wird nach Angaben der Cyber Security Agency of Singapore aktiv ausgenutzt. Die Schwachstelle ermöglicht es einem nicht authentifizierten Angreifer, über präparierte HTTP- oder HTTPS-Anfragen beliebige Dateien auf dem zugrunde liegenden System zu schreiben. Nach CVSS v3.1 ist sie mit 9,8 von 10 Punkten bewertet.\n\n ![Redaktionelle Illustration eines Unternehmens-Mail-Sicherheitsgateways bei der Reaktion auf eine aktiv ausgenutzte Schwachstelle, mit kritischer Warnung, Patch-Anzeigen und forensischen Netzwerkspuren.](https://publicasta.com/storage/projects/9/pages/788/2026/10/94af6eb5-e126-4a6e-a51f-e704f9bc2b66.webp)\n\n Das ist besonders relevant, weil FortiMail kein gewöhnlicher Anwendungsserver ist. Das System liegt an einer Vertrauensgrenze rund um den E-Mail-Verkehr, verarbeitet sensible Nachrichten und ist häufig über internetfähige Management- oder Service-Schnittstellen erreichbar. Ein erfolgreicher Dateischreibvorgang kann nur ein Schritt eines größeren Einbruchs sein. Deshalb sollten Verteidiger nicht annehmen, dass ein Patch allein beweist, dass das Gerät nie berührt wurde.\n\n Die praktische Reaktion hat daher zwei Spuren: Die Exposition muss sofort reduziert werden, anschließend ist zu klären, ob das Gerät Anzeichen einer Ausnutzung zeigt. Der erste Teil ist eine Produkt- und Konfigurationsaufgabe. Der zweite ist eine Incident-Response-Aufgabe, auch wenn die erste Beweislage nicht eindeutig ist.\n\n ## Was CVE-2026-104286 betrifft\n\n Die Schwachstelle wird als unzureichende Begrenzung eines Pfadnamens auf ein eingeschränktes Verzeichnis beschrieben, üblicherweise als Path Traversal bezeichnet. Vereinfacht gesagt kann eine Anfrage dazu führen, dass das System eine Datei außerhalb des von der Anwendung vorgesehenen Bereichs anspricht. Als konkrete Auswirkung wird das Schreiben beliebiger Dateien auf dem zugrunde liegenden FortiMail-System genannt.\n\n Wichtige Einschränkungen werden leicht übersehen:\n\n - Der Angreifer benötigt laut der veröffentlichten Behördenwarnung keine Authentifizierung.\n- Der Angriff kann über HTTP- oder HTTPS-Anfragen erfolgen.\n- Die Folge ist das Erstellen oder Ändern von Dateien auf dem zugrunde liegenden System des Geräts, nicht lediglich ein harmloser Fehler in einer Weboberfläche.\n- Es wurde eine aktive Ausnutzung gemeldet.\n\n Die von der Cyber Security Agency of Singapore genannten betroffenen Bereiche sind FortiMail 7.2.0 bis 7.4.8, 7.6.0 bis 7.6.6 sowie 8.0.0 bis 8.0.1. Diese Bereiche sind ein Ausgangspunkt für die Triage, ersetzen aber nicht die Prüfung des aktuellen Produkt-Hinweises von Fortinet. Fortinet kann im Verlauf der Untersuchung weitere betroffene Zweige, korrigierte Builds oder an bestimmte Zweige gebundene Anweisungen veröffentlichen.\n\n Administratoren sollten den exakt laufenden Build erfassen und sich nicht auf die Hauptversion in einem Beschaffungsdatensatz verlassen. Ein Cluster, eine virtuelle Appliance, ein Standby-Knoten oder ein Disaster-Recovery-Image kann eine andere Version als das Primärsystem verwenden. Zum Bestand gehören auch zentral verwaltete Appliances, übernommene Umgebungen und Systeme, die als intern gelten, aber über einen Reverse Proxy, Load Balancer, VPN oder ein Sicherheitsgerät Datenverkehr empfangen können.\n\n ## Warum ein E-Mail-Gateway eine Incident-Response verdient\n\n Eine E-Mail-Sicherheits-Appliance ist für Angreifer aus Gründen wertvoll, die über das Gerät selbst hinausgehen. Sie kann Netzwerkpfade zu Mailservern, Verzeichnisdiensten, Administrationsnetzen, Quarantänespeichern, Protokollierungsinfrastruktur, Update-Diensten und Identitätssystemen besitzen. Außerdem sieht sie große Mengen an Kommunikation und kann Nachrichtenmetadaten oder gespeicherte Inhalte enthalten.\n\n Eine Dateischreibschwachstelle bedeutet nicht automatisch, dass ein Angreifer auf Postfächer, Zugangsdaten oder die gesamte Domäne zugreifen konnte. Solche Aussagen brauchen Belege. Sie bedeutet jedoch, dass die Appliance bis zur Bewertung ihrer Exposition und Protokolle als möglicherweise kompromittierte Sicherheitskontrolle behandelt werden sollte.\n\n Mehrere getrennte Fragen müssen beantwortet werden:\n\n 1. War die FortiMail-Instanz während des verwundbaren Zeitraums für einen Angreifer erreichbar?\n2. Erreichten sie Anfragen, die zu Ausnutzungsmustern passten?\n3. Wurden unerwartete Dateien erstellt oder verändert?\n4. Baute die Appliance ungewöhnliche ausgehende Verbindungen auf oder führte sie auffällige Authentifizierungsversuche aus?\n5. Vertraute ein anderes System den von der Appliance erzeugten Daten, übernahm sie oder führte sie aus?\n\n Diese Fragestellung hält die Reaktion präzise. Sie verhindert beide Extreme: jedes verwundbare Gerät als nachweislich kompromittiert zu behandeln und einen erfolgreichen Patch als Beweis zu sehen, dass keine Untersuchung nötig ist.\n\n ## Die ersten betrieblichen Entscheidungen\n\n Zuerst sollte eine verantwortliche Person benannt werden, die Netzwerk, FortiMail-Administration, Identität und Incident Response koordinieren kann. Die Aufgabe darf nicht ohne namentlich zuständige Entscheidungsperson in einer Warteschlange liegen. Schützt das Gerät eine besonders wichtige oder regulierte Mailumgebung, sollten die Leitung für Incident Response sowie relevante Rechts- und Compliance-Ansprechpartner früh eingebunden werden.\n\n Danach wird das Expositionsfenster festgelegt. Zu dokumentieren sind der Zeitpunkt, an dem die Instanz auf eine betroffene Version aktualisiert wurde, der Zeitpunkt einer Außerbetriebnahme und die Frage, ob sie irgendwann aus dem Internet erreichbar war. Fehlt eine verlässliche Historie, sollte das früheste Datum verwendet werden, an dem der verwundbare Build erreichbar gewesen sein könnte. Diese Annahme muss klar gekennzeichnet werden.\n\n Bevor Änderungen möglicherweise nützliche Beweise löschen, sollten die für eine Rekonstruktion des Zustands erforderlichen Fakten erfasst werden: laufende Version, Systemzeit und Zeitzone, Rolle in einem Cluster, Netzwerkschnittstellen, Management-Exposition, jüngste administrative Änderungen und verfügbare Protokolle. Dabei gelten die Beweissicherungsregeln der eigenen Organisation. Ziel ist nicht, den Geschäftsbetrieb unbegrenzt einzufrieren, sondern genug Kontext zu bewahren, um ein verdächtiges Ereignis einordnen zu können.\n\n Ist die Appliance aktiv exponiert und gibt es einen sicheren Isolationsweg, sollte der Zugriff eingeschränkt werden, während der tatsächlich benötigte Mailfluss erhalten bleibt. Eine vorübergehende administrative Allowlist, eine Einschränkung der Management-Ebene oder ein kontrollierter Servicepfad kann das Risiko senken, bis das Update vorbereitet ist. Jede Containment-Änderung sollte mit Zeitpunkt, Umfang und erwarteten Nebenwirkungen dokumentiert werden.\n\n ## Prioritäten für Patch und Mitigation\n\n Fortinets PSIRT-Hinweis ist die maßgebliche Quelle für behobene Versionen und mögliche Übergangsmaßnahmen. Dieser Hinweis sollte zusammen mit der aktuellen FortiMail-Releasedokumentation verwendet werden. Eine Version darf nicht allein deshalb ausgewählt werden, weil sie im Download-Portal als neueste Datei erscheint. Zu prüfen ist, ob sie der korrigierte Build für den betroffenen Zweig und den konkreten Bereitstellungstyp ist.\n\n Die Reihenfolge sollte bewusst geplant werden:\n\n - Bestätigen, welche FortiMail-Knoten und Images betroffen sind.\n- Den korrigierten Release oder die vom Hersteller vorgeschriebene vorläufige Mitigation beschaffen.\n- Nicht erforderlichen Internetzugriff auf die Appliance bis zur geplanten Änderung einschränken.\n- Die Konfiguration gemäß der Wiederherstellungsrichtlinie sichern und dieses Backup als sensible Information schützen.\n- Update oder Workaround auf dem vorgesehenen Knoten anwenden.\n- Mailfluss, Richtliniendurchsetzung, Quarantäneverhalten, Authentifizierung, Protokollierung und Managementzugriff validieren.\n- Den Vorgang für Standby-, Cluster- und Disaster-Recovery-Komponenten wiederholen.\n- Den finalen Build sowie die zur Verifikation der Behebung verwendeten Nachweise dokumentieren.\n\n Ein Workaround ist keine abgeschlossene Behebung. Wenn eine Übergangsmaßnahme den verwundbaren Anfragepfad blockiert, kann sie die unmittelbare Exposition reduzieren. Sie beseitigt aber möglicherweise weder eine bereits veränderte Datei noch einen separaten Zugangspunkt. Das Gerät bleibt daher auf der Untersuchungsliste, bis die korrigierte Software installiert und die Prüfungen nach der Änderung abgeschlossen sind.\n\n ## Was vor und nach dem Update geprüft werden sollte\n\n Die genauen Indikatoren und Speicherorte der Protokolle sollten aus Fortinets Hinweis und der Appliance-Dokumentation stammen. Verteidiger sollten keine lokale Erkennungsregel aus einer allgemeinen Path-Traversal-Signatur ableiten. Angreifer können Kodierung, Anfragepfade, Header, zeitliche Abläufe und Zustellinfrastruktur variieren. Ein enges Muster kann dadurch falsche Sicherheit erzeugen.\n\n Mindestens folgende Daten sollten gesammelt und geprüft werden:\n\n - Web-, Administrations-, System- und Ereignisprotokolle für das gesamte Expositionsfenster.\n- Reverse-Proxy-, Firewall-, Load-Balancer- und Intrusion-Prevention-Daten vor der Appliance.\n- DNS-, Proxy- und Egress-Telemetrie zu unerwarteten Zielen.\n- Authentifizierungsdaten für Administrator- und Servicekonten sowie für mit FortiMail verbundene Integrationen.\n- Verfügbare Informationen zur Dateiintegrität oder zum Systemzustand der Appliance.\n- Konfigurationsänderungen, neue Konten, geänderte Zertifikate, veränderte Richtlinien und unerwartete geplante Aktivitäten.\n- Aufzeichnungen zur Clustersynchronisierung und zur zentralen Managementkonsole.\n\n Gesucht werden sollten Anfragen, die nicht zum üblichen Verhalten eines Mail-Gateways passen. Dazu gehören insbesondere nicht authentifizierte Anfragen an Management- oder Web-Endpunkte, ungewöhnliche Häufungen, Quelladressen außerhalb der erwarteten Benutzer oder Systeme und Aktivitäten außerhalb normaler Wartungsfenster. Eine verdächtige Quelladresse ist allein kein Beweis: Proxies, Scanner, gemeinsam genutzte Infrastruktur und verfälschte Meldedaten können die Zuordnung erschweren. Das Ereignis sollte mit der Antwort der Appliance und mit anderen Netzwerkdaten korreliert werden.\n\n Ebenso wichtig sind Auswirkungen, nicht nur Exploit-Zeichenfolgen. Unerwartete ausgehende Verbindungen, Änderungen an Richtlinien oder Routing, neue administrative Sitzungen, veränderte Zertifikate, geändertes Startverhalten oder unerklärliche Neustarts können aussagekräftiger sein als ein einzelner Anfrageeintrag. Sind Protokolle unvollständig, muss diese Lücke dokumentiert werden. Keine Beweise gefunden und keine Beweise aufbewahrt sind unterschiedliche Schlussfolgerungen.\n\n Nach dem Patch werden die relevanten Prüfungen wiederholt. Zu bestätigen ist, dass die verwundbare Version nicht mehr läuft, dass die vorläufige Kontrolle nicht zu früh entfernt wurde und dass derselbe Expositionsweg nicht auf einem anderen Knoten vorhanden ist. Eine neue Prüfung der externen Erreichbarkeit aus Sicht des internetfähigen Dienstes ist sinnvoll; sie muss innerhalb autorisierter defensiver Verfahren bleiben.\n\n ## Zugangsdaten und angrenzende Systeme\n\n Eine Rotation von Zugangsdaten sollte sich nach den Untersuchungsergebnissen richten. Teams müssen aber schnell handeln können, falls die Appliance Authentifizierungsmaterial gespeichert, verarbeitet oder darauf zugreifen konnte. Vorrang haben privilegierte FortiMail-Konten, lokale Administratorkennungen, API-Tokens, Zugangsdaten für Verzeichnisdienste, Geheimnisse für SMTP-Relays, Monitoring- und Backup-Zugangsdaten sowie Zertifikate oder Schlüssel, die an anderer Stelle verwendet werden könnten.\n\n Nicht jedes Geheimnis sollte reflexartig ohne Kenntnis der Abhängigkeiten rotiert werden. Ein unkoordinierter Reset kann den Mailfluss unterbrechen und die zeitliche Einordnung erschweren. Stattdessen sollte erfasst werden, welche Zugangsdaten vorhanden waren, welche Dienste sie akzeptierten und ob Hinweise auf ihre Nutzung existieren. Ist eine Kompromittierung plausibel, sollte die Rotation über einen vertrauenswürdigen Administrationsweg erfolgen. Alte und neue Zugangsdaten sind anschließend auf Nutzungsversuche zu überwachen.\n\n Angrenzende Systeme sollten im selben Zeitraum auf Auffälligkeiten bei Authentifizierung und Datenverkehr geprüft werden. Die Appliance kann das ursprüngliche Ziel, ein Zwischenpunkt oder nur ein Bestandteil einer größeren Kampagne sein. Zu prüfen sind Ereignisse des Identitätsanbieters, Verzeichnisprotokolle, Mailserver-Authentifizierung, administrative VPN-Zugriffe und Änderungen an Transportregeln. Besonders wichtig ist Aktivität, die kurz nach einem verdächtigen FortiMail-Ereignis begann.\n\n ## Was Organisationen kommunizieren sollten\n\n Die interne Mitteilung sollte so konkret sein, dass sie Maßnahmen unterstützt, ohne die Fakten zu überdehnen. Sie sollte das betroffene Produkt, die CVE, die gemeldete aktive Ausnutzung, den Expositionsstatus der Organisation, den Zeitpunkt von Containment oder Patch sowie den Stand der Untersuchung nennen. Außerdem sollte sie ankündigen, was sich ändern kann, etwa eine kurze Unterbrechung des Maildienstes oder eine erneute Anmeldung.\n\n Aussagen wie alle E-Mails wurden gestohlen sind zu vermeiden, solange die Untersuchung das nicht trägt. Ebenso ungenau wäre die Behauptung, nach dem Patch bestehe kein Risiko, obwohl das Gerät zuvor exponiert war. Häufig lautet die belastbare Zwischenbilanz: Das Gerät war verwundbar, eine Behebung wurde eingespielt, und Protokolle sowie angrenzende Systeme werden auf Hinweise einer Ausnutzung geprüft.\n\n Bestehen gesetzliche, regulatorische, vertragliche oder branchenspezifische Meldepflichten, sollte der Incident-Response-Prozess klären, ob eine Meldeschwelle erreicht ist. Die Schwachstelle selbst löst nicht automatisch eine Meldung eines Datenschutzvorfalls aus. Bestätigter unbefugter Zugriff auf geschützte Informationen kann Pflichten begründen, die bei einem verwundbaren, aber nicht kompromittierten Gerät nicht entstehen.\n\n ## Ein praktischer Entscheidungsbaum\n\n Die folgende Abfolge hilft, Zeit nicht durch Streit über Bezeichnungen zu verlieren.\n\n **Ist die Instanz nicht betroffen:** Die Versionsnachweise dokumentieren, bestätigen, dass alle zugehörigen Knoten geprüft wurden, und den Schwachstelleneintrag mit Quelle und Prüfdatum schließen.\n\n **Ist sie betroffen, war aber nie aus einem nicht vertrauenswürdigen Netz erreichbar:** Den korrigierten Release anwenden, interne Zugriffswege und Protokolle prüfen und festhalten, warum die Expositionsbewertung begrenzt ist. Nicht aus dem Internet erreichbar bedeutet nicht automatisch nicht erreichbar; Segmentierung und Administrationswege müssen validiert werden.\n\n **War sie erreichbar, gibt es aber keine Hinweise auf Ausnutzung:** Patch oder vorläufige Maßnahme anwenden, relevante Protokolle sichern, die Indikatoren des Herstellerhinweises prüfen und einen Folgetermin für Erkennung und Versionskontrolle setzen.\n\n **Gibt es verdächtige Anfragen oder Systemänderungen:** Die Appliance als möglichen Sicherheitsvorfall behandeln. Beweise sichern, Zugriff einschränken, die Incident-Response-Funktion einbinden und Zugangsdaten sowie verbundene Systeme untersuchen, bevor der Fall als abgeschlossen gilt.\n\n **Kann der Appliance nicht vertraut werden:** Den Mail-Schutz gemäß Business-Continuity-Plan auf eine genehmigte Alternative oder einen kontrollierten Fallback verlagern. Eine neue ungepatchte Dienstinstanz darf nicht improvisiert exponiert werden.\n\n Dieses Vorgehen trennt Fakten von Annahmen. Zugleich entsteht ein prüfbarer Datensatz, der erklärt, warum die Organisation nur patchte, zusätzliche Eindämmung einsetzte oder eine vollständige Untersuchung einleitete.\n\n ## Was vermieden werden sollte\n\n Die Management-Schnittstelle sollte nicht ins Internet gestellt werden, nur damit die Notfalladministration einfacher wird. Exploit-Payloads gehören nicht gegen eine produktive FortiMail getestet, sofern die Organisation diese Aktivität nicht ausdrücklich genehmigt, die betrieblichen Auswirkungen versteht und einen kontrollierten Plan besitzt. Das Problem ist ernst genug, dass eine vermeidbare Betriebsunterbrechung nicht zur defensiven Prüfung werden sollte.\n\n Ein grünes Ergebnis eines Schwachstellenscanners darf nicht der einzige Nachweis der Behebung sein. Ein Scanner kann die neue Version erkennen und trotzdem eine Standby-Appliance, eine alternative Adresse, einen Reverse-Proxy-Pfad oder Hinweise auf eine frühere Kompromittierung übersehen.\n\n Verdächtige Dateien oder Protokolle sollten nicht gelöscht werden, bevor sie im Rahmen des Beweisprozesses gesammelt wurden. Das Entfernen kann das Gerät scheinbar sauber machen und gleichzeitig die Informationen zerstören, die zur Rekonstruktion des Geschehens benötigt werden. Erfordert die sofortige Eindämmung einen Neuaufbau, muss der Zustand zuerst dokumentiert und die verfügbare Konfiguration sowie Telemetrie gesichert werden.\n\n Der CVSS-Wert ist keine Vorhersage des konkreten Schadens für die eigene Organisation. Die Bewertung 9,8 beschreibt die technische Schwere nach einem standardisierten Modell. Die geschäftliche Auswirkung hängt von Erreichbarkeit, Konfiguration, Netzposition, Datenzugriff, Qualität der Überwachung und dem weiteren Vorgehen des Angreifers ab.\n\n ## Die größere Lehre für Mail-Infrastruktur\n\n FortiMail erinnert daran, dass Sicherheits-Appliances dieselbe Bestandsdisziplin verdienen wie öffentlich erreichbare Anwendungen. Sie erhalten häufig erst dann dringende Aufmerksamkeit, wenn ein Hersteller eine kritische Schwachstelle ankündigt. Ihre normale Position im Betrieb macht sie jedoch zu wertvollen Zielen. Ein Gateway kann privilegierte Integrationen, umfassende Sichtbarkeit und Zugriffe auf Systeme besitzen, die in einem einfachen Softwarebestand nicht auffallen.\n\n Organisationen sollten einen Bestand führen, der Produktfamilie, exakten Build, Exposition, Eigentümer, Administrationsweg, verbundene Identitäten, Clusterzugehörigkeit, Speicherort des Backups und Aufbewahrungsdauer der Protokolle erfasst. Der Datensatz muss sich im Vorfall nutzen lassen und darf nicht nur einem quartalsweisen Audit dienen.\n\n Die zweite Lehre lautet, dass Behebung und Untersuchung getrennte Kontrollen sind. Ein Softwareupdate senkt die Wahrscheinlichkeit einer fortgesetzten Ausnutzung. Es sagt aber nicht, ob ein Angreifer die Schwachstelle am Vortag verwendet hat. Eine belastbare Reaktion beantwortet beide Fragen: Kann das jetzt passieren? Und ist es passiert, bevor wir die Lücke geschlossen haben?\n\n Die dritte Lehre ist, die Beweissicherung zu einem normalen Prozess zu machen. Werden Proxy-Protokolle sieben Tage aufbewahrt, empfiehlt der Hersteller aber die Prüfung eines längeren Ausnutzungsfensters, sollte die Organisation das vor dem Notfall wissen. Können Appliance-Protokolle nicht zuverlässig exportiert werden, ist das ein Resilienzproblem, das nach dem Vorfall behoben werden sollte.\n\n ## Fazit\n\n CVE-2026-104286 hat Priorität, weil unauthentifizierter Zugriff, beliebiges Dateischreiben, eine kritische Schwerebewertung und gemeldete aktive Ausnutzung zusammenkommen. FortiMail-Betreiber sollten betroffene Builds identifizieren, unnötige Exposition einschränken, Fortinets aktuellen Fix oder Workaround anwenden und jeden zugehörigen Knoten verifizieren.\n\n Danach muss der verwundbare Zeitraum untersucht werden. Die Indikatoren des Herstellers und lokale Telemetrie sind zu prüfen, Beweise zu sichern, Aktivitäten mit Identitäts- und Netzwerkprotokollen zu korrelieren und Zugangsdaten bei entsprechender Faktenlage zu rotieren. Das richtige Ergebnis lautet nicht automatisch kompromittiert, aber ebenso wenig gepatcht, also erledigt. Ein vertrauenswürdiger Behebungsnachweis erklärt, was exponiert war, was geändert wurde, was geprüft wurde und welche Unsicherheiten verbleiben.\n\n Quellen und weiterführende Informationen:\n\n - [Cyber Security Agency of Singapore: Active Exploitation of Vulnerability in Fortinet FortMail](https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-133/)\n- [Fortinet-PSIRT-Hinweis FG-IR-26-175](https://fortiguard.fortinet.com/psirt/FG-IR-26-175)\n- [Eintrag der National Vulnerability Database zu CVE-2026-104286](https://nvd.nist.gov/vuln/detail/CVE-2026-104286)\n- [CISA-Katalog bekannter ausgenutzter Schwachstellen](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-104286)","available_translations":[{"language":"ar","title":"استغلال FortiMail CVE-2026-104286 جارٍ: رقّع البوابة ثم تحقّق مما كان يمكنها كتابته","html_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response?lang=ar","markdown_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.md?lang=ar","json_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/fortimail_cve_2026_104286_active_exploitation_response?lang=ar"},{"language":"de","title":"FortiMail CVE-2026-104286 wird aktiv ausgenutzt: Gateway patchen und anschließend prüfen, was geschrieben werden konnte","html_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response?lang=de","markdown_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.md?lang=de","json_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/fortimail_cve_2026_104286_active_exploitation_response?lang=de"},{"language":"en","title":"FortiMail CVE-2026-104286 Is Being Exploited: Patch the Gateway, Then Check What It Could Write","html_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response?lang=en","markdown_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.md?lang=en","json_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/fortimail_cve_2026_104286_active_exploitation_response?lang=en"},{"language":"es","title":"CVE-2026-104286 de FortiMail está siendo explotada: parchea la pasarela y comprueba qué pudo escribir","html_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response?lang=es","markdown_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.md?lang=es","json_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/fortimail_cve_2026_104286_active_exploitation_response?lang=es"},{"language":"fr","title":"La CVE-2026-104286 de FortiMail est exploitée : corrigez la passerelle, puis vérifiez ce qu’elle a pu écrire","html_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response?lang=fr","markdown_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.md?lang=fr","json_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/fortimail_cve_2026_104286_active_exploitation_response?lang=fr"},{"language":"pl","title":"CVE-2026-104286 w FortiMail jest aktywnie wykorzystywana: załataj bramę, a potem sprawdź, co mogła zapisać","html_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response?lang=pl","markdown_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.md?lang=pl","json_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/fortimail_cve_2026_104286_active_exploitation_response?lang=pl"},{"language":"ru","title":"FortiMail: CVE-2026-104286 уже эксплуатируется — исправьте шлюз и проверьте, что он мог записать","html_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response?lang=ru","markdown_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.md?lang=ru","json_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/fortimail_cve_2026_104286_active_exploitation_response?lang=ru"},{"language":"zh","title":"FortiMail CVE-2026-104286 已遭利用：先修补网关，再检查它曾经能写入什么","html_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response?lang=zh","markdown_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.md?lang=zh","json_url":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/fortimail_cve_2026_104286_active_exploitation_response?lang=zh"}],"_links":{"self":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.json?lang=de","api":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/fortimail_cve_2026_104286_active_exploitation_response?lang=de","html":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response?lang=de","canonical":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response?lang=de","markdown":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.md?lang=de","json":"https://publicasta.com/cybersecurity/fortimail_cve_2026_104286_active_exploitation_response.json?lang=de","channel":"https://publicasta.com/api/public/v1/channels/cybersecurity","channel_articles":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}