สรุปสั้น

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

ข่าวดีคือแพตช์ไม่ใช่ของใหม่ Zoom ปล่อยการแก้ไขฝั่งไคลเอนต์ไปตั้งแต่เดือนมิถุนายนและกรกฎาคม หรือราวสองเดือนก่อนที่ช่องโหว่จะถูกเปิดเผยต่อสาธารณะ และจนถึงวันที่รายงานเผยแพร่ก็ยังไม่มีรายงานการถูกใช้โจมตีจริง ทั้งสามหมายเลขยังไม่ปรากฏในแคตาล็อก Known Exploited Vulnerabilities ของ CISA เวอร์ชันที่ปิดช่องโหว่คือ Zoom Workplace ทุกแพลตฟอร์มที่รองรับ ก่อน 7.1.5 และ 7.0.6 ในแต่ละสายการพัฒนา, Zoom Workplace VDI Client สำหรับ Windows ก่อน 7.0.11 และ 6.6.16 รวมถึง Zoom Rooms และ Zoom Meeting SDK ทุกแพลตฟอร์มก่อน 7.1.0 และก่อน 7.1.5 สำหรับช่องโหว่รายการที่สาม

สิ่งที่ต้องอ่านด้วยความระมัดระวังคือคำอธิบายรอบ ๆ ตัวช่องโหว่ เพราะฝั่งผู้ผลิตกับฝั่งนักวิจัยให้ภาพไม่ตรงกันทั้งเรื่องคะแนนความรุนแรง ผลกระทบของช่องโหว่หนึ่งรายการ และเครดิตการค้นพบ อีกทั้งข้ออ้างเรื่องการใช้ AI ช่วยสร้างชุดโจมตีก็เป็นคำกล่าวของบริษัทเองที่คนภายนอกตรวจสอบไม่ได้

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 12 สิงหาคม 2569 ว่า มีการเปิดเผยช่องโหว่สามรายการในเครื่องมือ annotation ของ Zoom ซึ่งเปิดทางให้ผู้ร่วมประชุมคนหนึ่งเข้ายึดไคลเอนต์ของผู้ร่วมประชุมอีกคนได้

งานวิจัยมาจากบริษัท A Security ซึ่งเป็นสตาร์ตอัปด้าน offensive security ที่ก่อตั้งโดยทีมอิสราเอลและเพิ่งออกจากโหมดปิดตัวเมื่อเดือนมิถุนายนพร้อมเงินทุน 37 ล้านดอลลาร์ บริษัทระบุว่าใช้เวลาจากการเจอช่องโหว่ไปจนถึงชุดโจมตีที่ใช้งานได้จริงภายในไม่ถึงหนึ่งวัน โดยใช้พรอมป์ไม่ถึง 20 ครั้งบนโมเดล AI ที่เปิดให้คนทั่วไปใช้ได้ ปัญหาคือไม่มีใครนอกบริษัทตรวจสอบคำกล่าวอ้างนี้ได้ เพราะรายงานไม่ได้ระบุชื่อโมเดลที่ใช้เลย

Zoom กำหนดหมายเลขช่องโหว่ไว้สามรายการ ได้แก่ CVE-2026-53413 (CVSS 8.3) การเขียนทับหน่วยความจำเกินขอบเขตบัฟเฟอร์ และ CVE-2026-53414 (CVSS 6.5) การอ่านข้อมูลเกินขอบเขตบัฟเฟอร์ ซึ่งทั้งคู่อยู่ในประกาศ ZSB-26015 และ ZSB-26016 บวกกับ CVE-2026-53415 (CVSS 8.3) ช่องโหว่ use-after-free ในประกาศ ZSB-26017 ขณะที่ A Security ให้คะแนนทั้งสามรายการไว้ที่ 9.0 ตามมาตรฐาน CVSS 4.0 ซึ่งเป็นตัวเลขที่ไม่ปรากฏในประกาศฉบับใดของ Zoom เลย

จุดนี้มีนัยเชิงกระบวนการ เพราะ Zoom เป็นผู้ออกหมายเลข CVE ของตัวเอง และ NIST ก็ไม่ได้ให้คะแนนซ้ำเป็นกิจวัตรอีกต่อไป ตัวเลขที่ต่ำกว่าของผู้ผลิตจึงมีแนวโน้มจะเป็นตัวเลขที่คงอยู่ในฐานข้อมูล นอกจากนี้เวกเตอร์ความรุนแรงของผู้ผลิตทั้งสามรายการยังระบุว่าต้องมีการโต้ตอบจากผู้ใช้ ซึ่งขัดกับการเล่าเรื่องแบบ zero-click ของฝั่งนักวิจัย

ความเห็นที่ต่างกันมากที่สุดอยู่ที่ช่องโหว่การอ่านเกินขอบเขต โดย A Security ระบุว่าดึงหน่วยความจำฮีปที่ยังไม่ถูกกำหนดค่าออกมาจากไคลเอนต์ของเหยื่อได้ และในนั้นมีพอยน์เตอร์ของโค้ดที่กำลังทำงานอยู่และ vtable ซึ่งเป็นวัตถุดิบที่จำเป็นสำหรับการหลบเลี่ยงกลไกสุ่มตำแหน่งหน่วยความจำ แต่ประกาศของ Zoom กลับระบุว่าช่องโหว่เดียวกันนี้อาจทำให้ผู้ร่วมประชุม “ก่อให้เกิดการปฏิเสธการให้บริการ” และให้คะแนนผลกระทบด้านความลับของข้อมูลไว้ที่ระดับไม่มีผลกระทบ

เครดิตการค้นพบก็แยกกันเช่นกัน ประกาศสองฉบับระบุชื่อนาย Idan Levcovich จาก A Security ส่วนฉบับที่ครอบคลุมช่องโหว่ use-after-free ให้เครดิตทีม Zoom Offensive Security ซึ่งเป็นทีมภายในของ Zoom เอง และเป็นทีมเดียวกับที่อยู่เบื้องหลังช่องโหว่ยึดบัญชีระดับ 9.8 ที่บริษัทแพตช์ไปเมื่อเดือนกรกฎาคม (เว็บไซต์ Cloud Thunder รายงานไว้ในโพสต์ 2026/07/161) ขณะที่บทความของสตาร์ตอัประบุทั้งสามรายการเป็นผลงานของตัวเอง พร้อมยอมรับว่า Zoom รู้เรื่องรายการที่สามอยู่แล้วและได้กรองมันไว้ที่ฝั่งเซิร์ฟเวอร์ก่อนที่รายงานจะส่งถึง

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

Zoom ไม่ได้เผยแพร่รายละเอียดทางเทคนิค กลไกภายในทั้งหมดจึงมาจากการทำวิศวกรรมย้อนกลับของ A Security เอง หัวใจของเรื่องคือภาพที่ผู้ร่วมประชุมวาดไม่ได้ถูกส่งข้ามเครือข่ายในรูปของภาพ แต่ไคลเอนต์จะแปลงเป็นอ็อบเจ็กต์ที่มีโครงสร้าง แล้วส่งออกไปเป็นชุดของตัวนับตามด้วยข้อมูล ฝั่งผู้รับจะเชื่อตัวนับเหล่านั้นในการตัดสินใจว่าจะอ่านข้อมูลยาวเท่าไร

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

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

หมายเลข 0x10001 หมายถึง “นี่คืออ็อบเจ็กต์” ส่วน 0x10002 หมายถึง “ฉันได้รับของคุณแล้ว” เมื่อส่งข้อความประเภทแรกไปในที่ที่ควรเป็นประเภทที่สอง ไคลเอนต์ของเหยื่อก็จะประกอบอ็อบเจ็กต์นั้นขึ้นมาใหม่ทั้งหมด ผลคือการโจมตีเดินได้ทั้งสองทิศทาง ทั้งจากผู้แชร์ไปยังผู้ชมทุกคน และจากผู้ชมคนใดคนหนึ่งย้อนกลับไปยังผู้แชร์

ส่วนเรื่องบทบาทของ AI คำอธิบายในบทความของบริษัทเองยุ่งกว่าบทสรุปที่บริษัทพูดถึงพอสมควร รอบแรกซึ่งเป็นการจัดอันดับฟังก์ชันที่เข้าถึงได้จากชั้น Java แบบอัตโนมัติ ให้ผลออกมาเป็นคิวฟังก์ชัน 3,762 รายการจาก 70 ไลบรารี และพลาดไลบรารีที่มีช่องโหว่ไปโดยสิ้นเชิง โดยจัดไว้อันดับที่ 45 ไลบรารีตัวจริงโผล่ขึ้นมาก็ต่อเมื่อทีมงานไล่ตามไคลเอนต์ที่กำลังทำงานอยู่ในสายจริงทีละฟีเจอร์ ซึ่งเป็นงานที่มนุษย์ทำ ขณะที่นาย Idan Levcovich เขียนว่ากำแพงในการสร้างชุดโจมตีประเภทนี้ “พังลงแล้ว และจะไม่กลับมาอีก”

ผลกระทบ

ในทางปฏิบัติ ความเสี่ยงที่เหลืออยู่ต่ำกว่าที่พาดหัวชวนให้คิด เพราะแพตช์ออกมาก่อนการเปิดเผยราวสองเดือน ยังไม่มีรายงานการโจมตีจริง และช่องโหว่ทั้งสามยังไม่เข้าแคตาล็อก KEV ของ CISA องค์กรที่บังคับให้ไคลเอนต์อัปเดตอัตโนมัติจึงน่าจะพ้นจุดเสี่ยงไปแล้วโดยไม่รู้ตัว ปัญหาจะอยู่ที่เครื่องที่ล็อกเวอร์ชันไว้ เครื่องในห้องประชุมที่ไม่ค่อยมีใครดูแล และระบบที่ฝัง Zoom Meeting SDK ไว้ในผลิตภัณฑ์ของตัวเอง ซึ่งการอัปเดตต้องรอผู้พัฒนาปลายทางเป็นคนทำ

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

อีกเรื่องที่ควรอ่านอย่างมีสติคือข้ออ้างเรื่อง AI การที่ผู้ผลิตกับนักวิจัยให้คะแนนต่างกัน ให้เครดิตต่างกัน และอธิบายผลกระทบของช่องโหว่เดียวกันไปคนละทาง เป็นเครื่องเตือนว่ารายงานของบริษัทที่เพิ่งระดมทุนและกำลังสร้างชื่อย่อมมีแรงจูงใจในการเล่าเรื่องแบบหนึ่ง ยิ่งเมื่อไม่ระบุชื่อโมเดลที่ใช้ ข้อความว่า “ไม่ถึง 20 พรอมป์บนโมเดลสาธารณะ” จึงยังเป็นคำกล่าวอ้างที่รอการพิสูจน์ ทั้งหมดนี้เกิดขึ้นหลังจาก OpenAI แยกโปรแกรม Daybreak และปล่อย GPT-5.6-Cyber ให้เฉพาะพันธมิตรที่ผ่านการตรวจสอบเพียงหนึ่งวัน (เว็บไซต์ Cloud Thunder รายงานไว้ในโพสต์ 2026/08/066) ด้วยเหตุผลว่าความสามารถระดับนี้ต้องมีการกำกับ ขณะที่ A Security บอกว่าตัวเองได้ผลลัพธ์จากโมเดลที่ใครก็ใช้ได้ ซึ่งขัดกับตัวเลขของ OpenAI เองที่ว่าโมเดลสาธารณะที่มีการ์ดเรลตอบคำขอด้าน offensive security ขั้นสูงเพียง 1.5% เทียบกับ 95% ของโมเดลที่ถูกจำกัดการเข้าถึง

คำแนะนำ

  • อัปเดต Zoom Workplace ให้เป็นเวอร์ชัน 7.1.5 หรือ 7.0.6 ขึ้นไปตามสายการพัฒนาที่ใช้อยู่ ทุกแพลตฟอร์มที่รองรับ
  • อัปเดต Zoom Workplace VDI Client สำหรับ Windows เป็นเวอร์ชัน 7.0.11 หรือ 6.6.16 ขึ้นไป
  • อัปเดต Zoom Rooms และ Zoom Meeting SDK เป็นเวอร์ชัน 7.1.0 ขึ้นไป และเป็น 7.1.5 ขึ้นไปเพื่อปิดช่องโหว่รายการที่สาม
  • ไล่ตรวจอุปกรณ์ในห้องประชุมและเครื่องที่ล็อกเวอร์ชันไว้เป็นพิเศษ เพราะเป็นกลุ่มที่มักไม่ได้รับอัปเดตอัตโนมัติเหมือนเครื่องผู้ใช้ทั่วไป
  • หากองค์กรพัฒนาผลิตภัณฑ์ที่ฝัง Zoom Meeting SDK ให้ตรวจสอบเวอร์ชัน SDK ที่คอมไพล์อยู่ในผลิตภัณฑ์ และวางแผนออกอัปเดตให้ลูกค้าปลายทาง
  • พิจารณาจำกัดสิทธิ์การใช้ annotation ในการประชุมที่มีผู้เข้าร่วมจากภายนอกองค์กร ในกรณีที่ยังอัปเดตไคลเอนต์ทั้งหมดไม่เสร็จ

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