FlawOpen

flawopen.com/Teardowns/cve-2026-104286-fortimail-ibe-path-traversal

● CVE-2026-104286 · CVSS 9.8[7] · Kritis
Riset Keamanan · FlawOpen

CVE-2026-104286: path traversal IBE FortiMail

CVE-2026-104286 memungkinkan permintaan HTTP(S) tanpa autentikasi menulis file pada FortiMail rentan melalui path traversal. Fortinet melaporkan eksploitasi aktif; nonaktifkan IBE atau batasi akses web, selidiki, lalu perbarui.[1], [5]

💡 Penjelasan Sederhana (ELI5)

Bayangkan ruang surat tempat petugas mengarsipkan lampiran. Kerentanan ini memungkinkan permintaan memberi jalur folder yang menyesatkan sehingga file ditulis di luar area semestinya. Mitigasi sementara menutup akses IBE atau membatasi antarmuka web sambil memperbarui dan memeriksa apakah akses sudah terjadi sebelumnya.[1], [5]

Konsep Kunci & Istilah

Path traversal (CWE-22)
Komponen jalur yang tidak tepercaya keluar dari direktori yang ditentukan untuk operasi file. Fortinet menjelaskan penulisan file arbitrer pada FortiMail terdampak.[1], [6]
Identity-Based Encryption (IBE)
Fitur FortiMail untuk alur kerja pesan terenkripsi. Mitigasi sementara vendor adalah menonaktifkan IBE; pertimbangkan dampak operasionalnya.[1], [5]
CISA KEV
CISA menambahkan CVE-2026-104286 ke katalog KEV pada 1 Oktober 2026. Ini menandakan eksploitasi diketahui, bukan bukti perangkat tertentu telah dibobol.[2], [5]
Perbedaan cakupan versi
Ringkasan Fortinet dan pemberitahuan pemerintah menyebut cabang 7.2, 7.4, 7.6, 8.0; data CNA terstruktur juga menyebut 7.0. Konfirmasikan cabang 7.0 langsung ke Fortinet.[6], [5], [4]

Pemetaan kerangka kerja

Analisis Akar Masalah (Root Cause)

Fortinet menjelaskan CVE-2026-104286 sebagai path traversal yang memungkinkan permintaan HTTP atau HTTPS tanpa autentikasi menulis file sembarang. Firmware FortiMail bersifat tertutup dan penasihat publik tidak menyediakan baris sumber rentan atau diff patch; artikel ini tidak mengarangnya. Pemberitahuan pemerintah mengonfirmasi dampak penulisan file, eksploitasi, dan panduan versi, tetapi tidak menjelaskan handler internal FortiMail. Penasihat Fortinet menjadi sumber langkah sementara untuk menonaktifkan IBE atau membatasi akses web serta IOC yang dipublikasikan. Batasi akses ke perangkat dan selidiki, lalu pasang versi perbaikan yang sesuai; tidak ditemukannya IOC bukan bukti aman. Uraian teks pada catatan CVE mencantumkan 7.2.0–7.2.9, 7.4.0–7.4.8, 7.6.0–7.6.6, dan 8.0.0–8.0.1. Tabel versi terstruktur memberi batas atas lebih rendah untuk 7.4 dan 7.6 serta juga mencantumkan 7.0.0–7.0.9. Bagian solusi pada catatan yang sama justru menyebut versi “mendatang” yang lebih rendah, yaitu 7.4.8, 7.6.6, 8.0.1, dan 7.2.10; ini bertentangan dengan data versi terdampak dan penasihat Kanada tanggal 1 Oktober. Gunakan penasihat pemerintah bertanggal tersebut sebagai panduan operasional yang diterbitkan, lalu konfirmasikan ketersediaan saat ini dan cakupan 7.0 kepada Fortinet; jangan menyimpulkan versi perbaikan dari kolom CNA yang saling bertentangan.[1], [3], [5], [4], [6], [7]

Matriks operator: cakupan versi dan respons awal

BidangKeterangan sumber resmiTindakan defensif
FortiMail 7.0Data NVD/CNA mencantumkan 7.0.0–7.0.9; ringkasan resmi Kanada dan Prancis tidak mencantumkan cabang 7.0. Uraian dan tabel pada catatan yang sama juga berbeda dalam batas atas 7.4 dan 7.6. Bagian solusi juga mencantumkan versi “mendatang” yang lebih rendah (7.4.8, 7.6.6, 8.0.1, dan 7.2.10), bertentangan dengan rentang terdampak dan penasihat Kanada.Minta konfirmasi status cabang ini kepada Fortinet; jangan menganggap cabang yang tidak disebut berarti aman.
FortiMail 7.2Penasihat Kanada menyarankan peningkatan ke cabang 7.4 atau yang lebih baru.Rencanakan migrasi ke cabang yang didukung dan telah diperbaiki; jangan menganggap tersedia patch untuk 7.2.
FortiMail 7.4 / 7.6 / 8.0Penasihat Kanada mencantumkan versi perbaikan 7.4.9, 7.6.7, dan 8.0.2 secara berurutan.Gunakan penasihat Kanada AV26-989 sebagai panduan versi yang diterbitkan; pastikan ketersediaan dan dukungan di penasihat Fortinet terbaru sebelum memperbarui. Jangan mengandalkan batas CNA yang lebih rendah tanpa konfirmasi.
Pembatasan dan investigasiFortinet melaporkan eksploitasi dan menerbitkan indikator kompromi; langkah sementara adalah menonaktifkan IBE atau membatasi akses web.Simpan bukti, terapkan langkah sementara, periksa indikator vendor, lalu pasang patch dan nilai kemungkinan kompromi.

Alur Serangan Langkah demi Langkah

Langkah 1

Permintaan tanpa autentikasi mencapai alur web

Fortinet menyatakan permintaan HTTP atau HTTPS khusus dapat memicu masalah tanpa kredensial. Penasihat publik tidak mengungkap handler internal atau implementasi tepatnya.[1], [5], [4]

Langkah 2

Jalur melewati batas file yang dimaksud

Vendor mengklasifikasikan masalah sebagai path traversal (CWE-22), yang memungkinkan file ditulis ke FortiMail terdampak. Jangan menyimpulkan teknik persistence tertentu hanya dari deskripsi CVE.[1], [6], [5]

Langkah 3

File yang ditulis dapat memperluas dampak

Fortinet memberi nilai CVSS 3.1 9,8 Critical dan melaporkan eksploitasi aktif. Gunakan IOC terbaru vendor untuk penyelidikan.[1], [5], [4]

Langkah 4

Mitigasi, simpan bukti, lalu perbarui

Nonaktifkan IBE atau batasi akses web ke jaringan tepercaya. Simpan log dan konfigurasi, periksa IOC, lalu pasang versi perbaikan cabang yang sesuai.[1], [5]

Kode Sumber: Rentan vs Aman

Kode firmware FortiMail dan diff patch vendor tidak tersedia untuk publik, jadi ini pola pertahanan Python generik, bukan kode Fortinet atau reproduksi kerentanan. Pola ini membuka direktori tepercaya sekali, memakai nama opak yang dibuat server, lalu membuat file baru relatif terhadap deskriptor direktori dengan pembuatan eksklusif dan flag tanpa-follow. Ini khusus POSIX dan gagal secara aman jika flag yang diperlukan tidak tersedia. Untuk path bertingkat, telusuri satu komponen tervalidasi setiap kali melalui deskriptor direktori; jangan memeriksa path teks lalu membukanya kembali berdasarkan nama. Terapkan pembaruan yang didukung atau mitigasi sementara resmi Fortinet untuk memperbaiki CVE-2026-104286. Semua komponen path root yang dikonfigurasi, termasuk direktori induknya, harus tetap dikendalikan administrator; O_NOFOLLOW hanya melindungi komponen terakhir saat root dibuka.

IMPLEMENTASI RENTAN
from pathlib import Path

def destination(root: Path, request_path: str) -> Path:
    # Ilustrasi desain tidak aman: input permintaan digabung
    # tanpa memastikan tetap di dalam root yang diizinkan.
    return root / request_path
PERBAIKAN AMAN & KUAT
import os
import uuid

# Buka direktori layanan tepercaya sekali; direktori induk path harus dikendalikan administrator.

def open_upload_root(root):
    required = ("O_DIRECTORY", "O_NOFOLLOW")
    if not all(hasattr(os, flag) for flag in required) or os.open not in os.supports_dir_fd:
        raise RuntimeError("POSIX directory protections unavailable")
    flags = os.O_RDONLY | os.O_DIRECTORY | os.O_NOFOLLOW
    return os.open(root, flags)

# Jangan ubah path request menjadi path file; buat nama opak dari server.
# O_EXCL gagal jika nama sudah ada; O_NOFOLLOW menolak tautan simbolis terakhir.
ROOT_FD = open_upload_root("/srv/app-private/uploads")


def create_upload_file():
    name = uuid.uuid4().hex
    flags = os.O_WRONLY | os.O_CREAT | os.O_EXCL | os.O_NOFOLLOW
    fd = os.open(name, flags, 0o600, dir_fd=ROOT_FD)
    return name, fd

Daftar Periksa Penguatan Sistem Rekayasa

Sumber