สรุปสั้น

บริษัท Broadcom ได้ปล่อยอัปเดตด้านความปลอดภัยเพื่อแก้ไขช่องโหว่หลายรายการที่กระทบผลิตภัณฑ์ VMware ESX, vCenter, Workstation และ Fusion โดยในจำนวนนี้มีถึง 3 รายการที่ถูกจัดความรุนแรงไว้ในระดับวิกฤต ช่องโหว่แรกคือ CVE-2026-59309 (CVSS 9.8) ซึ่งเป็นการบายพาสการยืนยันตัวตนใน VMware vCenter โดยบริษัท Broadcom อธิบายว่า “ผู้ไม่หวังดีที่มีการเข้าถึงทางเครือข่ายไปยัง vCenter อาจใช้ประโยชน์จากปัญหานี้เพื่อข้ามการยืนยันตัวตนและเข้าถึงระบบโดยไม่ได้รับอนุญาต” ส่วนช่องโหว่วิกฤตตัวที่สองคือ CVE-2026-59310 (CVSS 9.8) เป็นช่องโหว่ประเภท directory traversal ใน vCenter เช่นกัน ที่ผู้ไม่หวังดีซึ่งเข้าถึงทางเครือข่ายได้สามารถใช้เพื่อรันโค้ดตามอำเภอใจ

ช่องโหว่วิกฤตรายการที่สามคือ CVE-2026-47876 (CVSS 9.3) ซึ่งเป็นการเขียนข้อมูลนอกขอบเขตหน่วยความจำ (out-of-bounds write) ในการ์ดเครือข่ายเสมือน VMXNET3 ของ VMware ESX โดย Broadcom อธิบายอย่างชัดเจนว่านี่คือการหนีออกจากเครื่องเสมือน (VM escape) กล่าวคือผู้โจมตีที่ถือสิทธิ์ผู้ดูแลระบบภายในเครื่องเสมือนซึ่งใช้การ์ดเครือข่าย VMXNET3 อยู่แล้ว จะสามารถรันโค้ดบนโฮสต์ ESX ที่รองรับเครื่องเสมือนนั้นได้ ซึ่งเท่ากับทลายกำแพงกั้นระหว่างเครื่องเสมือนกับโฮสต์ที่เป็นรากฐานความปลอดภัยของระบบเวอร์ชวลไลเซชันทั้งหมด ทั้งนี้บริษัทระบุว่ายังไม่พบหลักฐานว่ามีการนำช่องโหว่ใดไปใช้โจมตีจริง แต่เนื่องจากไม่มีวิธีบรรเทาชั่วคราวใดๆ ให้ใช้ระหว่างรอแพตช์ บริษัทจึงจัดหมวดอัปเดตชุดนี้เป็นการเปลี่ยนแปลงฉุกเฉินที่ต้องดำเนินการทันที

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 29 กรกฎาคม 2569 ว่า บริษัท Broadcom ในฐานะเจ้าของผลิตภัณฑ์ VMware ได้ออกแพตช์ชุดใหญ่ที่ครอบคลุมทั้งผลิตภัณฑ์ฝั่งศูนย์ข้อมูลและฝั่งเดสก์ท็อป โดยช่องโหว่วิกฤตสองรายการแรกที่อยู่ใน vCenter ได้รับการแก้ไขในเวอร์ชันต่อไปนี้ ได้แก่ VMware Cloud Foundation และ VMware vSphere Foundation เวอร์ชัน 9.1.x.x แก้ไขใน 9.1.0.0300, เวอร์ชัน 9.0.x.x แก้ไขใน 9.0.2.0100, VMware vCenter เวอร์ชัน 8.0 แก้ไขใน 8.0 U3k และ VMware Cloud Foundation เวอร์ชัน 5.x ที่ต้องใช้แพตช์แบบ async ไปยัง 8.0 U3k

นอกจากสามช่องโหว่วิกฤตแล้ว Broadcom ยังแก้ไขช่องโหว่อื่นอีก โดย CVE-2026-41703 (CVSS 7.6) เป็นช่องโหว่อ่านข้อมูลนอกขอบเขตหน่วยความจำ (out-of-bounds read) ใน VMware ESX ที่ผู้ไม่หวังดีซึ่งมีสิทธิ์สร้างเครื่องเสมือนสามารถกระตุ้นให้เกิดขึ้นได้ ซึ่งอาจนำไปสู่การเปิดเผยข้อมูลหรือสภาวะปฏิเสธการให้บริการ (DoS) ส่วนบน VMware Workstation และ Fusion ผลกระทบจำกัดอยู่ที่การเปิดเผยข้อมูลเท่านั้น ขณะที่ CVE-2026-41709 (CVSS 2.7) เป็นช่องโหว่เรื่องการบันทึกล็อกไม่เพียงพอใน VMware ESX ที่ผู้ดูแลระบบซึ่งมีเจตนาร้ายสามารถใช้ทำปฏิบัติการบางอย่างโดยไม่ถูกบันทึกไว้ในล็อก ซึ่งแม้คะแนนจะต่ำแต่มีนัยสำคัญมากในแง่การสอบสวนหลังเกิดเหตุ

สำหรับเวอร์ชันที่แก้ไข CVE-2026-47876 ได้แก่ VMware Cloud Foundation และ VMware vSphere Foundation เวอร์ชัน ESXi-9.1.0.0200-25557999 และ ESXi-9.0.2.0100-25595025 รวมถึง VMware ESX รุ่น ESXi80U3k-25595708 ส่วน CVE-2026-41703 แก้ไขใน ESXi-9.1.0.0-25370933, ESXi-9.0.2.0100-25595025, VMware ESX ESXi80U3i-25205845, VMware Workstation 26H1, VMware Fusion 26H1 และ VMware Cloud Foundation 5.2.3 ขณะที่ CVE-2026-41709 แก้ไขใน ESXi-9.1.0.0-25370933, ESXi-9.0.2.0100-25595025 และ VMware ESX ESXi80U3j-25429389

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

รายละเอียดช่องโหว่

ช่องโหว่คู่แรกใน vCenter ถือว่าอันตรายที่สุดในเชิงยุทธศาสตร์ เพราะ vCenter คือศูนย์กลางบริหารจัดการโฮสต์ ESX ทั้งฟาร์ม ผู้ที่ยึด vCenter ได้เท่ากับควบคุมเครื่องเสมือนทุกตัวในศูนย์ข้อมูล โดย CVE-2026-59309 เปิดทางให้ผู้โจมตีที่เพียงแค่มองเห็น vCenter ทางเครือข่ายข้ามขั้นตอนยืนยันตัวตนไปได้เลยโดยไม่ต้องมีบัญชีใดๆ ขณะที่ CVE-2026-59310 ซึ่งเป็นช่องโหว่ประเภทเดินทะลุไดเรกทอรี เปิดทางให้ผู้โจมตีอ้างอิง path ออกนอกขอบเขตที่ระบบอนุญาตจนสามารถรันโค้ดตามอำเภอใจได้ เมื่อทั้งสองรายการอยู่บนผลิตภัณฑ์เดียวกันและมีคะแนนสูงสุดเท่ากันที่ 9.8 การนำมาร้อยต่อกันจึงเป็นเส้นทางที่ผู้โจมตีจะไล่ตามอย่างแน่นอนเมื่อมีการวิเคราะห์แพตช์ย้อนกลับ

ส่วน CVE-2026-47876 มีลักษณะต่างออกไป เพราะต้องอาศัยจุดตั้งต้นภายในเครื่องเสมือนก่อน โดยผู้โจมตีต้องถือสิทธิ์ผู้ดูแลระบบภายใน VM ที่ใช้อะแดปเตอร์เครือข่ายเสมือน VMXNET3 ซึ่งเป็นค่าเริ่มต้นที่นิยมใช้กันแพร่หลาย จากนั้นจึงส่งข้อมูลที่ประดิษฐ์ขึ้นทำให้เกิดการเขียนข้อมูลเกินขอบเขตบัฟเฟอร์ในโค้ดของอะแดปเตอร์ที่ทำงานอยู่ในระดับโฮสต์ ผลลัพธ์คือการรันโค้ดบนโฮสต์ ESX ซึ่งหมายถึงการหลุดออกจากกรอบการแยกส่วนของเครื่องเสมือน สถานการณ์นี้อันตรายอย่างยิ่งกับผู้ให้บริการคลาวด์และผู้ให้บริการโฮสติงที่มีผู้เช่าหลายรายอยู่บนโฮสต์เดียวกัน เพราะผู้เช่ารายเดียวที่ประสงค์ร้ายหรือ VM ที่ถูกยึดไปแล้ว จะกลายเป็นบันไดไปสู่การเข้าถึงข้อมูลของผู้เช่ารายอื่นทั้งหมดบนเครื่องเดียวกัน

ผลกระทบต่อไทย

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

อีกประเด็นที่ควรพิจารณาคือหลังการเปลี่ยนโมเดลสิทธิ์ใช้งานของ VMware ในยุค Broadcom ซึ่งทำให้ต้นทุนของหลายองค์กรพุ่งสูงขึ้น มีหน่วยงานไทยส่วนหนึ่งเลือกชะลอการต่อสัญญาสนับสนุนหรือคงเวอร์ชันเก่าไว้ใช้งานต่อ ซึ่งจะทำให้เข้าถึงแพตช์ได้ช้าหรือเข้าไม่ได้เลย กลายเป็นความเสี่ยงสะสมที่ผู้บริหารด้านไอทีต้องนำมาชั่งน้ำหนักใหม่ นอกจากนี้ผู้ให้บริการคลาวด์และโคโลเคชันในไทยที่ให้บริการแบบผู้เช่าหลายรายบนโฮสต์เดียวกัน ควรถือว่า CVE-2026-47876 เป็นความเสี่ยงระดับสูงสุดต่อความเชื่อมั่นของลูกค้า เพราะการหนีออกจาก VM หมายถึงข้อมูลของลูกค้ารายอื่นบนเครื่องเดียวกันตกอยู่ในความเสี่ยงทันที

คำแนะนำ

  • ติดตั้งแพตช์ vCenter เป็นลำดับแรกสุด (9.1.0.0300, 9.0.2.0100 หรือ 8.0 U3k ตามเวอร์ชันที่ใช้) เพราะเป็นจุดควบคุมทั้งฟาร์มและช่องโหว่ทั้งสองมีคะแนน 9.8
  • ตามด้วยการอัปเดตโฮสต์ ESX ให้ครบตามรายการเวอร์ชันที่ Broadcom ระบุ โดยเฉพาะระบบที่มีผู้เช่าหลายรายหรือรัน VM ที่ผู้ใช้ภายนอกควบคุมได้
  • อย่ารอวิธีบรรเทาชั่วคราว เพราะผู้ผลิตยืนยันว่าไม่มี และให้ปฏิบัติตามที่จัดชั้นเป็นการเปลี่ยนแปลงฉุกเฉิน
  • จำกัดการเข้าถึงอินเทอร์เฟซบริหารจัดการของ vCenter และ ESX ให้อยู่บนเครือข่ายจัดการเฉพาะ ไม่เปิดสู่อินเทอร์เน็ตหรือเครือข่ายผู้ใช้ทั่วไป เพื่อลดพื้นที่โจมตีระหว่างรอแพตช์ครบทุกเครื่อง
  • ทบทวนสิทธิ์ผู้ดูแลระบบภายในเครื่องเสมือนและสิทธิ์ deploy VM ให้เหลือเท่าที่จำเป็น เพราะเป็นเงื่อนไขตั้งต้นของ CVE-2026-47876 และ CVE-2026-41703
  • ตรวจสอบระบบเก็บล็อกของ ESX ให้แน่ใจว่าส่งออกไปยัง SIEM ภายนอก เนื่องจาก CVE-2026-41709 เปิดทางให้ผู้ดูแลที่ประสงค์ร้ายทำงานบางอย่างโดยไม่ทิ้งร่องรอย
  • องค์กรที่ไม่ได้ต่อสัญญาสนับสนุนควรประเมินความเสี่ยงเป็นลายลักษณ์อักษรและวางแผนย้ายหรือแยกระบบที่ไม่สามารถรับแพตช์ได้ออกจากเครือข่ายหลัก

แหล่งอ้างอิง