ห้องเก็บนโยบายความปลอดภัยสีเขียวเข้มที่มีแนวลิ้นชักและแถบกระดาษสีอำพันลอดกำแพงเข้าไปถึงห้องควบคุม
securitycheck-pointzero-daycvepath-traversal

Check Point CVE-2026-93616: Zero-Day เจาะ Management Server ก่อนล็อกอิน

น้องกายEngineering

Check Point ยืนยันว่า CVE-2026-93616 ถูกใช้โจมตี Check Point Security Management จริงแล้ว ช่องโหว่นี้เกิดใน web service ของระบบบริหารจัดการ เปิดให้ผู้โจมตีที่ยังไม่ล็อกอินทำ path traversal แล้วสั่งสคริปต์จากตำแหน่งไฟล์ที่เลือกเอง รวมถึงโหลด Java class ได้ คะแนน CVSS อยู่ที่ 9.8 และผู้ผลิตขอให้ติดตั้ง hotfix ทันทีครับ

ผมตรวจประกาศของ Check Point, เอกสารแก้ไข sk1000171, รายการ Known Exploited Vulnerabilities ของ CISA และรายงานอิสระของ BleepingComputer ณ 29 กันยายน 2026 เพื่อแยกว่าอะไรคือข้อเท็จจริงจากผู้ผลิต อะไรคือสิ่งที่พบในสนาม และอะไรยังตอบไม่ได้ บทความนี้โฟกัส CVE-2026-93616 ไม่รวม CVE-2026-85102 ซึ่งเป็นช่องโหว่คนละเส้นทางบน Security Gateway/VPN ครับ

สรุป 30 วินาที

  • CVE-2026-93616 เป็นช่องโหว่ pre-authentication path traversal ใน Check Point Management web service ผู้โจมตีไม่ต้องมีบัญชีก่อนเริ่มโจมตี
  • ผลลัพธ์ที่ผู้ผลิตระบุคือรันสคริปต์จาก path ใดก็ได้และโหลด Java class ได้ จึงกระทบ confidentiality, integrity และ availability ของศูนย์กลางบริหารนโยบาย
  • Check Point พบการโจมตีแบบเจาะจงจำนวนหนึ่งตั้งแต่วันที่ 23 กรกฎาคม 2026; CISA นำช่องโหว่นี้เข้า KEV เพราะมีหลักฐานการใช้โจมตีจริง
  • ระบบที่ได้รับผลรวม Security Management Server, Multi-Domain Security Management, Log Server, Multi-Domain Log Server และ SmartEvent ตามรายการผลิตภัณฑ์ใน advisory
  • ทางแก้หลักคือ Jumbo Hotfix หรือ Security Hotfix ที่ตรง release ไม่ใช่เพียงติด LivePatch Take 28/29 เพราะผู้ผลิตระบุชัดว่าสอง take นี้ ไม่แก้ CVE-2026-93616
  • หลัง patch ต้องตรวจหาร่องรอยการบุกรุกด้วย เพราะการอุดช่องโหว่ไม่ลบสคริปต์, Java class หรือบัญชีที่ผู้โจมตีอาจวางไว้ก่อนหน้า

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

Security Management Server ไม่ใช่เว็บภายในธรรมดา แต่เป็นจุดรวม policy ของ firewall, การเปลี่ยนแปลงโดยผู้ดูแล และ log จากอุปกรณ์หลายตัว หากจุดนี้ถูกยึด ผู้โจมตีอาจมองเห็นโครงสร้างเครือข่าย เปลี่ยนกฎให้ทราฟฟิกผ่าน สร้างทางกลับเข้าระบบ หรือทำให้หลักฐานที่ทีม incident response ต้องใช้ไม่น่าเชื่อถือได้

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

ทีม platform และ network ต้องสนใจแม้ไม่ได้ดูแล Check Point โดยตรง เพราะ Management Server มักเชื่อมต่อกับ directory, SIEM, ticketing, backup หรือ automation ถ้า credential บนเครื่องถูกขโมย ความเสียหายอาจข้ามผลิตภัณฑ์ไปยังระบบข้างเคียง ส่วนทีม compliance ต้องรู้ว่าการโจมตีเกิดก่อนวันออกคำเตือนหลายสัปดาห์ การตรวจย้อนหลังจึงต้องครอบคลุมช่วงก่อนวันที่ patch ไม่ใช่ดูเฉพาะ log หลังประกาศข่าว

สำหรับผู้บริหาร ประเด็นนี้ไม่ควรถูกลดเหลือคำถามว่า “อัปเดตแล้วหรือยัง” คำถามที่ครบกว่าคือ เราปิดช่องโหว่แล้วหรือยัง, มีหลักฐานไหมว่าระบบไม่เคยถูกเจาะ, และถ้าหลักฐานชี้ว่าถูกเจาะ เราแยก credential กับ policy ที่ต้องเปลี่ยนครบหรือยัง สามคำถามนี้ใช้งบและเวลาคนละก้อนครับ

ทำงานยังไง

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

คำว่า pre-authentication หมายถึงผู้โจมตียังไม่ต้องแสดงบัตร ไม่ต้องขโมยรหัสผ่าน และไม่ต้องผ่าน MFA ก่อนส่งคำขออันตราย ความเสี่ยงจึงขึ้นกับการเข้าถึง web service จาก network มากกว่าสิทธิ์ของบัญชี หาก management interface เปิดถึงอินเทอร์เน็ตหรือเครือข่ายผู้ใช้กว้างเกินจำเป็น โอกาสที่ request จะมาถึงจุดเปราะบางก็สูงขึ้น

เมื่อวางหรือชี้ไปยังสคริปต์ใน arbitrary path ได้ ขั้นถัดไปคือทำให้ระบบรันสคริปต์นั้น Check Point ระบุผลกระทบเพิ่มว่าโหลด Java class ได้ด้วย นั่นสำคัญเพราะ Java class เป็นโค้ดที่ JVM นำไปทำงาน ไม่ใช่ไฟล์ข้อความเฉย ๆ ผู้โจมตีจึงอาจเปลี่ยนจากการเขียนไฟล์เป็นการรันตรรกะบน Management Server และต่อยอดไปสู่ persistence หรือการขโมยข้อมูล ทั้งนี้ advisory สาธารณะไม่ได้เปิดเผย exploit chain ทุกบรรทัด การอธิบายลำดับละเอียดกว่านี้โดยไม่มีหลักฐานจะกลายเป็นการเดา

ความต่างระหว่าง patch กับ hunting จึงเหมือนเปลี่ยนกลอนประตูหลังพบรอยงัด กลอนใหม่หยุดการงัดแบบเดิมในอนาคต แต่ไม่ได้ตอบว่ามีใครซ่อนตัวอยู่ในบ้านแล้วหรือไม่ ทีมต้องเก็บหลักฐานก่อนทำลาย state ที่สำคัญ ตรวจไฟล์และ class ผิดปกติ, process, scheduled task, บัญชีผู้ดูแล, policy change และการเชื่อมต่อออกจากเครื่อง แล้วเทียบกับ IoC ล่าสุดใน sk1000171

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

ต้นทุนตรงคือหน้าต่างบำรุงรักษา การทดสอบ compatibility และกำลังคนสำหรับ patch หลาย management domain รุ่นที่ยังรองรับมีเส้นทางแก้ต่างกัน: R82.20 ใช้ Security Hotfix เฉพาะ; R82.10 ต้องใช้ Jumbo Hotfix Take 45 ขึ้นไป; R82 ต้อง Take 127 ขึ้นไป; R81.20 ต้อง Take 170 ขึ้นไป; และ R81.10 ต้อง Take 192 ขึ้นไป แต่ R81.10 สิ้นสุดการสนับสนุนแล้ว ส่วน R80 ถึง R81 รุ่นเก่าที่อยู่ในรายการ EoS ต้องวางแผนอัปเกรด ไม่ควรตีความว่ามี patch ระยะยาวให้ทุกรุ่น

อีกก้อนคือ incident assessment ถ้าเครื่องเปิดให้เครือข่ายที่ไม่น่าเชื่อถือเข้าถึงได้ในช่วงเสี่ยง ทีมอาจต้อง preserve image, export log, rotate credential, ตรวจ policy drift และสอบสวนระบบที่ Management Server เชื่อมต่อ ค่าใช้จ่ายนี้สูงกว่า maintenance ปกติ แต่การข้ามขั้นตอนเพราะ “ลง patch แล้ว” อาจทิ้ง persistence ไว้และทำให้ต้องหยุดระบบรอบสอง

ผลกระทบทางธุรกิจอาจเกิดทั้งสองด้าน การรีบปิด management interface โดยไม่มีแผนอาจทำให้ทีมเปลี่ยน policy ฉุกเฉินไม่ได้ ขณะที่การเปิดทิ้งไว้เพื่อความสะดวกเพิ่มหน้าต่างโจมตี วิธีที่สมเหตุผลคือจำกัด Trusted Clients หรือ firewall ให้เหลือ jump host/VPN สำหรับผู้ดูแลที่จำเป็น วาง change freeze สั้น ๆ เก็บหลักฐาน แล้ว patch ตาม runbook พร้อมแผน rollback ที่ทดสอบได้

องค์กรที่ใช้บริการ managed security ควรถามผู้ให้บริการเป็นลายลักษณ์อักษรว่ารุ่นและ take ปัจจุบันคืออะไร management plane เปิดรับจากไหน ติดตั้ง hotfix เมื่อใด และทำ compromise assessment ครอบคลุมตั้งแต่ก่อน 23 กรกฎาคมหรือไม่ คำตอบว่า “ผู้ให้บริการอัปเดตอัตโนมัติ” ยังไม่เพียงพอ เพราะ Check Point ระบุว่า LivePatch Take 28/29 ไม่ได้ครอบคลุมช่องโหว่นี้

ข้อมูลที่ยังไม่ชัดและแหล่งที่ไม่ตรงกัน

Check Point บอกว่าพบ “a handful of pinpointed attacks” เมื่อวันที่ 23 กรกฎาคม ซึ่งสื่อถึงการโจมตีแบบจำกัดและเลือกเป้าหมาย ขณะที่ภาษาใน CISA KEV สรุปในระดับว่าช่องโหว่ถูกใช้โจมตีจริง สองแหล่งไม่ได้ขัดกันโดยตรง แต่ตอบคนละคำถาม: ผู้ผลิตบอกขนาดที่ตนสังเกต ณ วันประกาศ ส่วน KEV บอกสถานะว่ามี exploitation เพียงพอให้หน่วยงานต้องเร่งแก้ เราจึงไม่ควรแปลคำว่า handful ว่ามีเหยื่อทั่วโลกเพียงไม่กี่ราย เพราะ telemetry ของผู้ผลิตอาจไม่เห็นทุกระบบ

BleepingComputer อธิบายผลในภาษาที่จับต้องได้ว่า unauthenticated attacker สามารถอัปโหลดและรัน arbitrary script ด้วยความซับซ้อนต่ำ ส่วน Check Point ใช้ถ้อยคำระมัดระวังกว่าว่า arbitrary-path script execution และ Java class load รายงานอิสระช่วยแปลผลกระทบ แต่รายละเอียดทางเทคนิคที่ถือเป็นฐานตัดสินเวอร์ชันและวิธีแก้ต้องยึด sk1000171 ของผู้ผลิต

ยังไม่มีข้อมูลสาธารณะครบเกี่ยวกับจำนวนองค์กรที่ถูกเจาะ ประเทศหรืออุตสาหกรรมทั้งหมด initial request ที่ใช้ได้ทุกกรณี payload หลังเจาะ และ attribution ของผู้โจมตี IoC อาจเปลี่ยนหลังบทความนี้เผยแพร่ จึงต้องใช้หน้า advisory สด ไม่คัดลอกรายการ hash หรือ path เก่าไปฝังใน playbook แล้วหยุดอัปเดต

อย่าสับสน CVE-2026-93616 กับ CVE-2026-85102 ซึ่ง Check Point ประกาศใกล้กัน ตัวแรกอยู่ใน Management web service และเกี่ยวกับ path traversal ส่วนตัวหลังอยู่ใน VPN certificate handling ของ Security Gateway แม้ทั้งคู่มี CVSS 9.8 และถูกใช้โจมตี การตรวจ log, ผลิตภัณฑ์ที่ได้รับผล และแพตช์เป็นคนละชุด การรวมสองเรื่องเข้าตั๋วเดียวอาจทำให้ทีมปิดงานทั้งที่แก้เพียงครึ่งเดียว

ควรทำอะไร

ทีมดูแล Check Point ควรเริ่มจาก inventory แบบไม่เดา: ระบุผลิตภัณฑ์, release, Jumbo Hotfix Take, exposure ของ management web service และ Trusted Clients ทุก environment แล้วเทียบ sk1000171 เวอร์ชันล่าสุด หากอยู่บน R82.20 ให้ใช้ Security Hotfix ที่ผู้ผลิตกำหนด; ถ้าเป็น R82.10, R82, R81.20 หรือ R81.10 ให้ติด take ขั้นต่ำที่แก้แล้วตาม matrix และตรวจ build หลัง reboot อย่าใช้การมี LivePatch 28/29 เป็นหลักฐานว่าปลอดภัย

ก่อนเปลี่ยนระบบ เก็บ snapshot และ log ตามกระบวนการ forensic ขององค์กรโดยไม่ทำลาย chain of custody จำกัด management access ให้เฉพาะ trusted IP/jump host ที่จำเป็น และหลีกเลี่ยงการเปิด service กลับสู่อินเทอร์เน็ตเพียงเพราะ patch เสร็จ จากนั้นล่าร่องรอยตาม IoC ใน sk1000171 รวมการสร้างสคริปต์หรือ Java class นอกตำแหน่งปกติ, process ลูกผิดปกติ, policy/admin change ที่ไม่มี ticket และ outbound connection จาก Management Server

ถ้าพบร่องรอย ให้ถือว่า credential และ policy ที่เครื่องเข้าถึงอาจถูกเปิดเผย แยกเครื่องออกอย่างระมัดระวัง ติดต่อ Check Point Support และทีม incident response หมุน secret จากเครื่องที่เชื่อถือได้ ตรวจระบบ downstream และสร้าง management server ใหม่จากแหล่งสะอาดเมื่อ playbook กำหนด การลบไฟล์ต้องสงสัยหนึ่งไฟล์ไม่ใช่การยืนยันว่า attacker ถูกขับออกแล้ว

ทีมที่ patch ไม่ได้ทันทีควรใช้ mitigation ในเอกสารผู้ผลิต เช่น วาง management interface หลัง firewall และจำกัด Trusted Clients ให้แคบที่สุด แต่ต้องเข้าใจว่านี่คือลดโอกาสที่ request จะมาถึง ไม่ใช่ซ่อม parser ที่มีช่องโหว่ ตั้งเวลาอัปเกรดที่มีเจ้าของชัดเจน และตรวจว่าระบบ EoS ไม่ถูกปล่อยให้ mitigation ชั่วคราวกลายเป็นถาวร

Recap

  • หา Security Management ทุกตัว พร้อม release, build และ Jumbo Hotfix Take จริง
  • จำกัด management web service ให้เฉพาะ trusted admin path ก่อนเริ่มงาน
  • เก็บหลักฐานและ log ย้อนหลังอย่างน้อยครอบคลุมวันที่ 23 กรกฎาคม 2026
  • ติด R82.20 Security Hotfix หรือ JHF ขั้นต่ำที่ตรง matrix ใน sk1000171
  • ไม่ใช้ LivePatch Take 28/29 เป็นตัวแทน patch ของ CVE-2026-93616
  • ตรวจ IoC, arbitrary scripts, Java classes, process, admin และ policy changes หลังแก้
  • แยก CVE-2026-93616 ออกจาก CVE-2026-85102 ใน tracking และ validation
  • ถ้าพบ compromise ให้ rotate secret และตรวจ downstream จากเครื่องที่เชื่อถือได้
  • อัปเดตระบบ EoS แทนการพึ่ง mitigation ระยะยาว