ตู้คัดจดหมายสีเขียวเข้มมีช่องรับตามทางปกติ แต่ซองหนึ่งลอดผนังข้างและทิ้งรอยไฟล์สีอำพันไว้ในห้องเครื่อง
securityfortimailfortinetcve-2026-104286cisa-kevpath-traversal

CVE-2026-104286 ถูกใช้โจมตี FortiMail แล้ว—ช่อง path traversal เขียนไฟล์ได้และเส้นตาย CISA สั้นมาก

พี่โชว์Engineering

ถ้าองค์กรคุณวาง FortiMail ไว้หน้าระบบอีเมล ข่าวนี้ควรถูกยกขึ้นคิว incident วันนี้ครับ CISA เพิ่ม CVE-2026-104286 เข้า Known Exploited Vulnerabilities หรือ KEV วันที่ 1 ตุลาคม 2026 หมายความว่ามีหลักฐานการถูกใช้โจมตีจริง ไม่ใช่เพียงช่องโหว่ในห้องทดลอง และกำหนด due date วันที่ 4 ตุลาคมสำหรับหน่วยงานที่อยู่ภายใต้คำสั่งของสหรัฐฯ เส้นตายสั้นผิดปกติพอให้ทีมอื่นใช้เป็นสัญญาณเร่งด่วนด้วย

ช่องโหว่นี้ถูกอธิบายว่าเป็น path traversal ผสม null byte ที่ผู้โจมตีไม่ต้องยืนยันตัวตนและอาจใช้เขียนไฟล์ผ่าน HTTP(S) ได้ ผมตรวจต้นทาง Fortinet PSIRT FG-IR-26-175, รายการ KEV, NVD และแหล่งติดตามอิสระ ไม่ได้รัน exploit หรือ scanner กับระบบใด บทความนี้จึงช่วยจัดลำดับและวาง triage ไม่ใช่คู่มือโจมตีครับ

สรุป 30 วินาที

  • CISA เพิ่ม CVE-2026-104286 เข้า KEV วันที่ 1 ตุลาคม 2026 พร้อมข้อความว่ามี exploitation ที่ทราบแล้ว และกำหนด due date 4 ตุลาคมสำหรับหน่วยงานที่เกี่ยวข้อง
  • ช่องโหว่กระทบ FortiMail ตาม matrix ใน advisory ของ Fortinet ผู้โจมตีที่ไม่ล็อกอินอาจส่งคำขอ HTTP(S) ที่ใช้ path traversal กับ null byte เพื่อหลบการตรวจชื่อไฟล์และเขียนไฟล์ในตำแหน่งที่ไม่ควรเข้าถึง
  • arbitrary file write ไม่เท่ากับ remote code execution อัตโนมัติทุกระบบ แต่การเขียนไฟล์ลงตำแหน่งที่ process เชื่อถืออาจนำไปสู่ persistence, config tampering, web-accessible payload หรือขั้นต่อไปที่รุนแรงขึ้น จึงต้องจัดเป็นเหตุการณ์ความเสี่ยงสูง
  • แหล่งอิสระอย่าง TechGeeks รายงาน severity ระดับ Critical 9.8 และการ exploit ที่ยืนยันแล้ว ส่วนตัวเลขเวอร์ชันกับ mitigation ต้องยึด advisory ทางการ ณ เวลาปฏิบัติ เพราะหน้า advisory อาจอัปเดต
  • ถ้าเครื่องอยู่ใน affected range ให้เก็บหลักฐานก่อน เปลี่ยนไปใช้ fixed version ตาม Fortinet จำกัด management/HTTP(S) exposure และตรวจหาไฟล์หรือการเปลี่ยนค่าผิดปกติ อย่าแพตช์แล้วถือว่าเหตุการณ์จบ
  • ถ้ายืนยันไม่ได้ว่าเครื่องไม่เคยเปิดรับจากอินเทอร์เน็ตหรือไม่มีร่องรอย ให้ยกระดับเป็น incident triage พร้อม rotate credential ที่อาจเข้าถึงได้จาก appliance ตามผลการสืบสวน

ทำไมเรื่องนี้เกี่ยวกับคุณ

ระบบ email security อยู่ตรงประตูหน้าขององค์กร มันรับข้อมูลจากภายนอกตลอดวันและมักเชื่อมกับ DNS, mail server, directory, quarantine, certificate และบัญชีแอดมิน หากกล่องหน้าประตูถูกเขียนไฟล์ได้ ผลกระทบจึงไม่ได้จำกัดแค่กล่องอีเมลหนึ่งใบครับ

ลองนึกถึง FortiMail เป็นห้องคัดจดหมายของคอนโด ทุกซองต้องผ่านห้องนี้ก่อนส่งเข้าห้องลูกบ้าน ช่อง path traversal เหมือนคนภายนอกยื่นซองผ่านช่องรับ แต่เขียนที่อยู่บนซองให้เจ้าหน้าที่เดินออกจากห้องคัด ไปวางของในห้องเครื่องแทน null byte เปรียบเหมือนสอดเครื่องหมายที่ทำให้พนักงานคนแรกอ่านว่า “ไฟล์รูปธรรมดา” แต่ระบบอีกชั้นอ่านชื่อจบเร็วกว่าจนส่วนต่อท้ายที่ใช้ตรวจความปลอดภัยหายไป

ทีมอีเมลได้รับผลตรงเพราะ downtime มีต้นทุนสูง ทีม security ต้องหาว่ามีไฟล์ถูกเขียนก่อน patch หรือไม่ ทีม identity ต้องประเมิน credential ที่ appliance เคยเก็บ ทีม network ต้องจำกัด exposure ขณะที่ฝ่ายธุรกิจต้องมีแผนรับส่งอีเมลระหว่าง maintenance ข่าวนี้จึงไม่ควรถูกโยนให้ผู้ดูแลเครื่องคนเดียว

การอยู่ใน KEV เปลี่ยนลำดับงาน เพราะ KEV ไม่ได้รวบรวมทุก CVE ที่คะแนนสูง แต่เน้นรายการที่มีหลักฐานถูกใช้โจมตีจริง คะแนน CVSS ช่วยบอกความรุนแรงเชิงเทคนิค ส่วน KEV ช่วยบอกว่าความน่าจะเกิดไม่ใช่ศูนย์แล้ว เมื่อสองสัญญาณมาพร้อมกัน การรอรอบ patch ปกติสิ้นเดือนมักไม่เหมาะครับ

ทำงานยังไง: ที่อยู่ ../ กับป้ายจบชื่อไฟล์

เว็บแอปมักรับชื่อไฟล์หรือ path แล้วนำไปประกอบกับโฟลเดอร์ที่กำหนด เช่นเก็บไฟล์ใน /safe/uploads/ หากระบบไม่ normalize path อย่างถูกต้อง ตัวระบุย้อนขึ้นโฟลเดอร์อย่าง ../ อาจพาการเขียนออกจากพื้นที่นั้น นี่คือ path traversal

Null byte คือไบต์ศูนย์ที่ซอฟต์แวร์บางชั้นใช้เป็นเครื่องหมายจบข้อความ ถ้าชั้นตรวจสอบกับชั้นเขียนไฟล์ตีความไม่เหมือนกัน ผู้โจมตีอาจทำให้ validator เห็น suffix ที่อนุญาต แต่ API ระดับล่างเห็นชื่อสั้นกว่าที่ไม่มี suffix นั้น ช่องโหว่สมัยใหม่ไม่ได้เกิดเพราะภาษาทุกตัวรับ null byte แบบเดียวกัน แต่เกิดได้เมื่อข้อมูลผ่านหลาย parser หรือ native interface ที่มีสมมติฐานต่างกัน

เมื่อรวมสองอย่าง คำขอภายนอกอาจชี้ path ไปตำแหน่งที่ต้องการและตัดส่วนชื่อที่ใช้บังคับประเภทไฟล์ออก Advisory ระบุผลเป็น arbitrary file write ผ่าน HTTP(S) โดยไม่ยืนยันตัวตน คำว่า arbitrary แปลว่าผู้โจมตีควบคุมตำแหน่งหรือเนื้อหาได้ในระดับที่ช่องโหว่อนุญาต ไม่ควรตีความเกินหลักฐานว่าได้ root ทุกเครื่องทันที

อันตรายขึ้นกับตำแหน่งที่ process เขียนได้ ถ้าเขียน web directory ได้ ไฟล์อาจถูกเรียกผ่านเว็บ ถ้าเขียน config หรือ startup path ได้ อาจเกิด persistence ถ้าเขียน authorized key, cron-like location หรือไฟล์ที่ service โหลด อาจขยายไปสู่ code execution แต่เส้นทางจริงต่างตาม version, permission, filesystem layout และ hardening เราจึงต้องตรวจหลักฐานบนเครื่องแทนการเดา

การแพตช์แก้ทางเข้าของช่องโหว่ แต่ไม่ลบไฟล์ที่ผู้โจมตีเขียนไว้ก่อนหน้า เปรียบเหมือนซ่อมช่องกำแพงหลังโจรเข้าบ้าน ประตูใหม่หยุดคนถัดไปได้ แต่ยังต้องเดินตรวจห้อง ดูกล้อง และเปลี่ยนกุญแจที่หายครับ

เงินและผลกระทบ

ต้นทุนมีสองด้าน ด้านแรกคือ downtime และความเสี่ยงส่งอีเมลล่าช้าระหว่าง patch ด้านที่สองคือความเสียหายหากเครื่องถูกควบคุม เช่น business email compromise, credential theft, spam relay, การแก้ routing หรือการใช้ appliance เป็นฐานเข้าระบบข้างใน

การเลือก “ไม่หยุดระบบตอนนี้” อาจดูประหยัด แต่ความล่าช้าเพิ่มหน้าต่างโจมตีในช่วงที่ attacker รู้ว่าช่องโหว่ถูกใช้งานแล้ว วิธีลดผลกระทบคือเตรียม HA/failover, maintenance notice, backup config ที่ตรวจ integrity, rollback plan และคนเฝ้า mail queue แทนการเลื่อนเพราะกลัว downtime อย่างเดียว

ฝ่ายบริหารควรเห็นตัวเลขที่ตัดสินใจได้: จำนวน appliance, เวอร์ชัน, exposure, owner, patch ETA, IOC status, backup ล่าสุด และ credential ที่ต้องหมุน ไม่ควรได้เพียงรายงานว่า “ทีมกำลังดู CVE” เพราะเส้นตาย CISA มีไม่กี่วันและการ exploit เกิดขึ้นแล้ว

สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน

ข้อมูลที่ตรงกันคือ CVE, ผลกระทบแบบ unauthenticated arbitrary file write และสถานะ KEV ส่วนรายละเอียด affected/fixed version ต้องยึด matrix ล่าสุดใน Fortinet PSIRT เพราะฐานข้อมูลอิสระอาจ sync ช้ากว่าและ advisory เปลี่ยนได้ ผมจงใจไม่คัดลอกตัวเลขเวอร์ชันมาฝังถาวรโดยที่หน้าทางการควรเป็น authority ตอนลงมือ

TechGeeks สรุปคะแนน 9.8 และใช้คำ Critical ขณะที่ฐานข้อมูลอาจอัปเดตคะแนนหรือ vector ภายหลัง คะแนนช่วยคัดลำดับ แต่การมี exploitation ใน KEV สำคัญกว่าส่วนต่างทศนิยม อย่ารอให้ทุกฐานข้อมูลแสดงตัวเลขเหมือนกันก่อนเริ่ม inventory

ข้อมูลสาธารณะ ณ เวลาตรวจยังไม่ทำให้เรายืนยัน initial access ของทุกเหตุการณ์, payload ที่พบ, campaign attribution หรือ IOC ครบชุด เราจึงไม่ควรแต่งรายชื่อไฟล์, IP หรือ user-agent ขึ้นเอง การ block IOC ที่เผยแพร่ภายหลังเป็นเพียงชั้นเสริม เพราะ attacker เปลี่ยน infrastructure ได้

ยังไม่ชัดว่าทุก deployment เปิด endpoint ที่เปราะต่ออินเทอร์เน็ตหรือมี reverse proxy/WAF ลด reachability แค่ไหน แต่การ “อยู่หลัง WAF” ไม่ใช่หลักฐานว่าไม่กระทบจนกว่าจะทดสอบ rule และ log จริง Path encoding กับ parser mismatch อาจผ่านตัวกรองที่ไม่เข้าใจเหมือน origin

CISA due date มีผลบังคับตรงกับหน่วยงานสหรัฐฯ ที่อยู่ในขอบเขตคำสั่ง ไม่ใช่ deadline ทางกฎหมายของทุกบริษัท อย่างไรก็ตามความสั้นของ deadline สื่อถึง urgency ทางปฏิบัติ องค์กรไทยควรใช้ risk-based response ไม่ควรตีความว่า “ไม่ใช่หน่วยงานสหรัฐฯ จึงรอได้”

ควรทำอะไร

ภายในชั่วโมงแรก

  1. ทำ inventory FortiMail ทุกตัว รวม HA node, lab, DR และเครื่องที่หยุดแต่ยังเข้าถึงได้ บันทึก version/build และ management/data interface exposure
  2. เปิด advisory FG-IR-26-175 จากช่องทาง Fortinet ที่องค์กรใช้ ตรวจ affected matrix กับ entitlement ของตัวเอง และดาวน์โหลด firmware ผ่าน support channel ที่ตรวจ checksum/signature ได้
  3. จำกัด HTTP(S) management ให้เข้าผ่าน VPN/jump host และ allowlist เท่าที่จำเป็น ถ้า endpoint ที่เปราะแยกปิดได้โดยไม่ทำลาย mail flow ให้ใช้ mitigation ตาม vendor
  4. เก็บ snapshot/log/config และเวลาเครื่องก่อนเปลี่ยนแปลง เพื่อให้ forensic timeline ไม่หาย

ภายในวันเดียวกัน

  1. อัปเกรดไป fixed version ตาม advisory ผ่าน staging/HA plan แล้วตรวจ health, mail queue, TLS, routing, quarantine และ authentication หลังเปลี่ยน
  2. ค้นหาการเขียนไฟล์ผิดปกติในช่วงก่อน patch: เวลาไฟล์, web/config/startup locations, process child, request log ที่มี encoding/path แปลก และ config diff ใช้ IOC จาก vendor/CISA เมื่อมี ไม่ใช้ scanner จากแหล่งไม่รู้ที่มา
  3. ถ้าพบร่องรอยหรือ log ไม่พอยืนยัน ให้ isolate node ตามความสามารถธุรกิจ รักษาหลักฐาน และเรียก incident response อย่าลบไฟล์ทันทีจนทำลาย timeline
  4. ประเมิน credential และ key ที่ appliance เข้าถึงได้ เช่น directory bind, API, backup, mail relay, certificate private key แล้ว rotate ตามหลักฐานและ risk

หลังควบคุมเหตุการณ์

  1. ตรวจว่าระบบ monitoring มองเห็นการเขียนไฟล์และ config change บนอุปกรณ์ edge หรือไม่ เพิ่ม central log กับ alert ที่ไม่พึ่ง log บน appliance เพียงจุดเดียว
  2. ทบทวนเหตุผลที่ management interface เปิดกว้าง, SLA patch อุปกรณ์ขอบเครือข่าย, owner สำรอง และขั้นตอน emergency change

Recap

  • ยืนยัน inventory กับ version/build ทุก FortiMail node
  • ตรวจ affected/fixed matrix จาก Fortinet PSIRT ล่าสุด ไม่เดาจากชื่อผลิตภัณฑ์
  • ถือ KEV วันที่ 1 ต.ค. และ due date 4 ต.ค. เป็นสัญญาณเร่งด่วน
  • จำกัด HTTP(S) exposure และใช้ fixed version ผ่านช่องทางที่ตรวจ provenance ได้
  • เก็บหลักฐานก่อน patch และตรวจย้อนหลัง เพราะ patch ไม่ลบ persistence เดิม
  • ค้นหาไฟล์, config, process และ request ที่ผิดปกติด้วย IOC ที่เชื่อถือได้
  • rotate credential/key ตาม exposure และผลสืบสวน
  • ถ้าพบร่องรอยหรือพิสูจน์ความสะอาดไม่ได้ ให้เข้าสู่ incident response ไม่ปิด ticket แค่ “แพตช์แล้ว”

CVE-2026-104286 เป็นกรณีที่ไม่ควรรอให้รายละเอียด campaign สมบูรณ์ครับ หลักฐานที่พอใช้ตัดสินใจมีแล้ว: ช่องโหว่อยู่บนระบบขอบเครือข่าย เข้าถึงได้โดยไม่ล็อกอิน อาจเขียนไฟล์ และอยู่ในรายการ exploited จริง งานวันนี้คือปิดทางเข้าโดยอ้างอิง vendor พร้อมตรวจว่ามีใครเข้ามาก่อนเราซ่อมหรือยังครับ