ศูนย์ประสานการรักษาความมั่นคงปลอดภัยระบบคอมพิวเตอร์แห่งชาติ (ThaiCERT)ได้ติดตามสถานการณ์ภัยคุกคามทางไซเบอร์ พบช่องโหว่ด้านความปลอดภัยในระบบฐานข้อมูล MongoDB Server โดยช่องโหว่นี้เปิดโอกาสให้ผู้โจมตีที่ยังไม่ได้ยืนยันตัวตน (Unauthenticated Attacker) สามารถส่งคำขอเพื่อทำให้เซิร์ฟเวอร์หยุดทำงาน (Crash) ซึ่ง MongoDB ได้ออกแพตช์อัปเดตเพื่อแก้ไขปัญหาดังกล่าวเรียบร้อยแล้ว หน่วยงานที่ใช้งานควรเร่งดำเนินการตรวจสอบและอัปเดตทันที [1]
1. รายละเอียดช่องโหว่
CVE-2026-118383 (CVSS v4.0: 9.5) [2] เป็นช่องโหว่ประเภท Use-After-Free ที่เกิดจากข้อบกพร่องในการจัดการหน่วยความจำระหว่างกระบวนการ Cleanup ของ MongoDB Server โดยอาจเปิดโอกาสให้ผู้โจมตีที่ไม่ได้ผ่านการยืนยันตัวตนส่งคำขอที่ถูกสร้างขึ้นเป็นพิเศษ เพื่อกระตุ้นให้ระบบเข้าถึงพื้นที่หน่วยความจำที่ถูกคืนไปแล้ว ส่งผลให้เซิร์ฟเวอร์หยุดทำงาน (Crash) และเกิดภาวะปฏิเสธการให้บริการ (Denial of Service: DoS)
2. ผลิตภัณฑ์หรือระบบที่ได้รับผลกระทบ [3]
2.1 เซิร์ฟเวอร์ฐานข้อมูล MongoDB ที่ตั้งค่าใช้งานในรูปแบบชุดแบบจำลอง (Replica Set)
2.2 สมาชิกของเซิร์ฟเวอร์ประเภท Shard และ Config Server ภายในคลัสเตอร์แบบ Sharded (Sharded Clusters)
2.3 MongoDB Version 8.2 (สิ้นสุดการสนับสนุนเมื่อ 31 ก.ค. 2026) ยังคงพบช่องโหว่จากการทดสอบ
3. ผลกระทบที่อาจเกิดขึ้น
3.1 แฮกเกอร์สามารถส่งคำสั่ง ping 2 ชุด พร้อมแนบค่า readConcern.afterOpTime ไปฝังในเซิร์ฟเวอร์สำรองที่มีข้อมูลของเซิร์ฟเวอร์หลัก
3.2 แม้ระบบจะเปิดการยืนยันตัวตนไว้ คำสั่งดังกล่าวยังสามารถทะลุผ่านไปได้
3.3 หากเกิดการสลับการทำงาน (Failover) และเซิร์ฟเวอร์สำรองถูกดันขึ้นเป็นเซิร์ฟเวอร์หลัก ระบบจะอัปเดตข้อมูลให้ครบและเรียกใช้คำสั่งกระบวนการล้างข้อมูลซ้ำ 2 ครั้ง
3.4 การเรียกใช้คำสั่งซ้ำทำให้เกิดช่องโหว่ Use-After-Free ส่งผลให้เซิร์ฟเวอร์ล่ม (Crash) และฐานข้อมูลหยุดให้บริการ (Denial of Service)
3.5 ภายใต้เงื่อนไขบางประการ ช่องโหว่นี้อาจเปิดทางไปสู่การเรียกใช้คำสั่งอันตรายได้
4. แนวทางการป้องกันและลดความเสี่ยง
4.1 ผู้ดูแลระบบ (IT Admin) ควรเร่งตรวจสอบและอัปเดต MongoDB ให้เป็นเวอร์ชันแก้ไขล่าสุด โดยต้องอัปเดตสมาชิกของ Replica Set ทุกตัว
4.2 ระบบ MongoDB Atlas จะได้รับการอัปเดตอัตโนมัติในช่วง Maintenance หากหน่วยงานเลื่อนเวลาอัปเดตไว้ ให้รีบดำเนินการอัปเดตทันที
4.3 การป้องกันชั่วคราวระหว่างรออัปเดต ควรจำกัดการเข้าถึงเครือข่ายของระบบฐานข้อมูลให้เหลือเฉพาะ IP และระบบที่จำเป็น
4.4 ตรวจสอบความผิดปกติใน Log อย่างสม่ำเสมอ เพื่อหาสัญญาณการโจมตี เช่น รายการ “Slow query” (ID 51803), การออกจากสถานะ primary catch-up 2 ครั้ง (ID 21363) หรือการแจ้งเตือน Fatal signal ที่เชื่อมโยงกับ CatchupState::abort_inlock()
แหล่งอ้างอิง
[1] https://dg.th/joby3sl2p4
[2] https://dg.th/7z6fgl9cwp
[3] https://dg.th/jkpb83a4i0