สรุปสั้น
นักวิจัยด้านความมั่นคงปลอดภัยไซเบอร์เปิดเผยช่องโหว่ระดับวิกฤตใน isolated-vm ซึ่งเป็นแซนด์บ็อกซ์โอเพนซอร์สที่ได้รับความนิยมสูง มีดาวบน GitHub มากกว่า 2,900 ดวงและถูกฟอร์กไปแล้ว 190 ครั้ง ช่องโหว่นี้เปิดทางให้ผู้โจมตีหลุดออกจากขอบเขตของสภาพแวดล้อมที่ถูกแยกไว้ได้ ช่องโหว่ถูกกำหนดหมายเลข GHSA-864f-rcv7-6rh4 แต่ยังไม่ได้รับหมายเลข CVE โดยกระทบทุกเวอร์ชันตั้งแต่ก่อนหน้าและรวมถึงเวอร์ชัน 7.0.0 และได้รับการแก้ไขแล้วในเวอร์ชัน 6.2.0 และ 7.0.1 ที่ปล่อยออกมาเมื่อต้นเดือนนี้
isolated-vm เป็นไลบรารีของ Node.js สำหรับรันจาวาสคริปต์ที่ไม่น่าเชื่อถือภายใน V8 Isolate ซึ่งเป็นอินสแตนซ์อิสระของเอนจินจาวาสคริปต์ V8 ของ Google ทำให้สภาพแวดล้อมจาวาสคริปต์หลายชุดทำงานพร้อมกันได้โดยไม่แชร์ข้อมูลและไม่รบกวนกัน แพ็กเกจนี้บน npm มียอดดาวน์โหลดเกือบหนึ่งล้านครั้งในสัปดาห์ที่ผ่านมาเพียงสัปดาห์เดียว ซึ่งสะท้อนว่ามันเป็นชิ้นส่วนพื้นฐานที่ระบบจำนวนมากพึ่งพาโดยไม่รู้ตัว
จุดที่ล้มเหลวไม่ใช่กลไกการแยกของ V8 เอง แต่คือชั้นโค้ด C++ ที่ทำหน้าที่แปลงค่าข้ามขอบเขตนั้น ช่องโหว่เป็นแบบ type confusion ในคลาส ExternalCopy ซึ่งจัดการตัวเลือก transferList โดยผลกระทบต่ำสุดที่สาธิตได้คือการทำให้โปรเซสหลักล่มด้วย segmentation fault ที่ควบคุมตำแหน่งได้ ส่วนผลกระทบสูงสุดคือการยึดการควบคุมการทำงานของโปรเซสหลัก ซึ่งหมายถึงความเป็นไปได้ที่จะเกิดการรันโค้ดจากระยะไกลในโปรเซสนั้น
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 20 สิงหาคม 2569 ว่า นักวิจัยเปิดเผยช่องโหว่ระดับวิกฤตใน isolated-vm ไลบรารีแซนด์บ็อกซ์ที่ใช้กันกว้างขวางในระบบนิเวศ Node.js ไลบรารีนี้แยกโค้ดไว้ใน V8 Isolate ซึ่งแต่ละตัวมีสถานะและฮีปของตัวเอง จึงส่งวัตถุจาวาสคริปต์จากเธรดหลักของ Node.js เข้าไปตรง ๆ ไม่ได้ isolated-vm จึงมีคลาส ExternalCopy ไว้แปลงวัตถุออกจาก isolate ของโฮสต์อย่างปลอดภัยแล้วแปลงกลับเข้า isolate ของแขก และช่องโหว่ที่บริษัท Endor Labs พบก็อยู่ในองค์ประกอบนี้ โดยเปิดทางให้โค้ดในแซนด์บ็อกซ์หลุดออกมาทำลายความถูกต้องของหน่วยความจำในแอปโฮสต์
นาย Cristian-Alexandru Staicu นักวิจัยของ Endor Labs ผู้ค้นพบและรายงาน อธิบายว่าต้นเหตุ คือ type confusion ในการจัดการตัวเลือก transferList ของ ExternalCopy ทีมวิจัยเริ่มจาก ivm.Reference เพียงตัวเดียว ซึ่งเป็นวิธีมาตรฐานที่โฮสต์ใช้มอบความสามารถให้แซนด์บ็อกซ์ แล้วยกระดับจากการทำให้ล่มที่ควบคุมตำแหน่งได้ ไปจนถึงยึดการทำงานของโฮสต์ได้ทั้งหมด ซึ่งเท่ากับหลุดจากแขกสู่โฮสต์อย่างสมบูรณ์ ด้านนาย Marcel Laverdet ผู้ดูแลโครงการ ระบุในประกาศเตือนว่าผลกระทบต่ำสุดที่สาธิตได้ คือ การทำให้ล่มอย่างน่าเชื่อถือ ซึ่งแขกรายใดที่ได้ ivm.Reference ก็ทำได้ ส่วนผลสูงสุด คือ การยึดโปรเซสโฮสต์จนอาจรันโค้ดจากระยะไกลได้ ผู้ที่ติดตั้ง isolated-vm ไว้ได้รับคำแนะนำให้อัปเดตเป็นเวอร์ชันล่าสุด และรายละเอียดโค้ดโจมตีฉบับเต็มถูกระงับไว้เพื่อไม่ให้ผู้ไม่หวังดีนำไปใช้
รายละเอียดช่องโหว่
type confusion คือข้อผิดพลาดที่โปรแกรมตีความข้อมูลก้อนหนึ่งว่าเป็นชนิดหนึ่ง ทั้งที่จริงแล้วเป็นอีกชนิดหนึ่ง ผลที่ตามมาคือโค้ดอ่านหรือเขียนหน่วยความจำตามโครงสร้างที่ไม่ตรงกับของจริง ซึ่งในภาษาอย่าง C++ ที่ไม่มีการตรวจสอบขอบเขตอัตโนมัติ มักนำไปสู่การเขียนทับข้อมูลนอกพื้นที่ที่ควรจะเป็น ในกรณีนี้ความสับสนเกิดขึ้นในการจัดการตัวเลือก transferList ของ ExternalCopy ซึ่งเป็นเส้นทางที่ข้อมูลจากฝั่งแขกเดินทางเข้าสู่ฝั่งโฮสต์อยู่แล้วโดยการออกแบบ
จุดที่ทำให้ช่องโหว่นี้ร้ายแรงเป็นพิเศษคือเงื่อนไขในการใช้งานต่ำมาก ตามที่ผู้ดูแลโครงการระบุ แขกรายใดก็ตามที่ได้รับ ivm.Reference สามารถกระตุ้นการล่มที่ควบคุมตำแหน่งได้ และการมอบ ivm.Reference คือวิธีมาตรฐานที่โฮสต์ใช้มอบความสามารถใด ๆ ให้แซนด์บ็อกซ์ กล่าวอีกอย่างคือ แซนด์บ็อกซ์ที่ถูกตั้งค่าให้ทำอะไรก็ตามที่เป็นประโยชน์ ย่อมเข้าเงื่อนไขของช่องโหว่นี้แทบทั้งหมด ส่วนแซนด์บ็อกซ์ที่ไม่ได้รับ ivm.Reference เลยก็เป็นแซนด์บ็อกซ์ที่แทบทำอะไรไม่ได้อยู่แล้ว
บทสรุปเชิงสถาปัตยกรรมที่นักวิจัยเน้นเป็นประเด็นที่ควรจดจำมากที่สุดจากข่าวนี้ นาย Staicu ระบุว่าสิ่งที่สำคัญที่สุดคือสิ่งที่ไม่ได้พังคือกลไกการแยกตัวเอง ขอบเขตของ V8 Isolate ยังทำงานได้ดี สิ่งที่ล้มเหลวคือโค้ด C++ ที่ทำหน้าที่เป็นกาวคอยแปลงค่าข้ามขอบเขตนั้น ชิ้นส่วนพื้นฐานที่ออกแบบมาอย่างถูกต้องสมบูรณ์ถูกบั่นทอนด้วยชั้นเชื่อมต่อที่ห่อหุ้มมันไว้ นี่คือรูปแบบที่พบซ้ำในระบบความปลอดภัยจำนวนมาก ที่จุดอ่อนไม่ได้อยู่ที่กลไกป้องกันหลัก แต่อยู่ที่รอยต่อระหว่างกลไกนั้นกับส่วนอื่นของระบบ
ข้อจำกัดของข้อมูลที่ต้องระบุคือ ช่องโหว่นี้ยังไม่ได้รับหมายเลข CVE ซึ่งหมายความว่าเครื่องมือสแกนช่องโหว่ที่ตรวจตามฐานข้อมูล CVE อาจยังมองไม่เห็น รายงานไม่ได้ระบุว่ามีการนำช่องโหว่ไปใช้โจมตีจริงแล้วหรือไม่ ไม่ได้ระบุจำนวนหรือรายชื่อระบบที่ได้รับผลกระทบ และรายละเอียดของโค้ดโจมตีฉบับเต็มถูกระงับไว้ ทำให้ไม่สามารถประเมินความยากง่ายในการทำซ้ำได้จากข้อมูลสาธารณะ
ผลกระทบ
ความเสี่ยงของช่องโหว่นี้ต้องอ่านจากบริบทการใช้งานของ isolated-vm ไลบรารีตัวนี้ไม่ได้ถูกใช้ในงานทั่วไป แต่ถูกใช้เฉพาะในกรณีที่ระบบต้องรันโค้ดที่ไม่น่าเชื่อถือ ซึ่งหมายความว่าทุกระบบที่ติดตั้งมันไว้คือระบบที่ยอมรับโค้ดจากภายนอกมารันโดยตั้งใจอยู่แล้ว การที่แซนด์บ็อกซ์ของระบบเหล่านั้นแตก จึงไม่ใช่ความเสี่ยงเชิงทฤษฎี แต่คือการที่กลไกป้องกันชิ้นเดียวที่ยืนอยู่ระหว่างโค้ดของคนแปลกหน้ากับเซิร์ฟเวอร์ถูกยกออกไป
กลุ่มผู้ใช้ที่ควรตรวจสอบเป็นอันดับแรกคือแพลตฟอร์มที่เปิดให้ผู้ใช้เขียนสคริปต์เองหรือติดตั้งปลั๊กอิน ระบบที่รันสูตรคำนวณหรือกฎที่ลูกค้ากำหนด บริการที่ประมวลผลเทมเพลตจากผู้ใช้ และที่สำคัญไม่แพ้กันในช่วงนี้คือระบบที่รันโค้ดซึ่งโมเดลภาษาสร้างขึ้น เพราะการรันโค้ดจากโมเดลในแซนด์บ็อกซ์กลายเป็นรูปแบบมาตรฐานของเครื่องมือสาย AI ที่ต้องคำนวณหรือเรียกใช้เครื่องมือ ในกรณีนั้นโค้ดที่ไหลเข้าแซนด์บ็อกซ์อาจถูกควบคุมทางอ้อมโดยผู้ที่ป้อนข้อความเข้าโมเดล ซึ่งเป็นเส้นทางที่ผู้ออกแบบระบบมักไม่ได้นับว่าเป็นอินพุตจากผู้โจมตี เว็บไซต์ Cloud Thunder เคยรายงานการที่ OpenAI ยกระดับความเข้มของแซนด์บ็อกซ์สำหรับภาระงานที่รันโค้ดซึ่งโมเดลสร้างขึ้นไว้ที่ 2026/08/121
อีกประเด็นที่ทำให้การแก้ไขยากกว่าที่คิดคือ isolated-vm มักไม่ได้ถูกติดตั้งโดยตรง แต่ติดมากับไลบรารีหรือเฟรมเวิร์กอื่นที่ใช้มันเป็นเครื่องยนต์ภายใน ยอดดาวน์โหลดเกือบหนึ่งล้านครั้งต่อสัปดาห์จึงไม่ได้แปลว่ามีนักพัฒนาหนึ่งล้านคนที่รู้ตัวว่าใช้มันอยู่ องค์กรจำนวนหนึ่งจะพบว่าตัวเองได้รับผลกระทบก็ต่อเมื่อไล่ดูต้นไม้ของแพ็กเกจที่ติดตั้งจริง ไม่ใช่จากรายการที่ประกาศไว้ในไฟล์ตั้งค่าของโครงการ
คำแนะนำ
สิ่งที่ต้องทำทันทีคืออัปเดต isolated-vm ไปยังเวอร์ชัน 7.0.1 หรือ 6.2.0 ตามสายที่ใช้อยู่ เนื่องจากทุกเวอร์ชันจนถึงและรวมถึง 7.0.0 ได้รับผลกระทบทั้งหมด องค์กรควรตรวจสอบด้วยคำสั่งที่ไล่ดูต้นไม้ของแพ็กเกจจริง ไม่ใช่ดูเฉพาะรายการที่ประกาศไว้เป็น dependency โดยตรง เพราะไลบรารีตัวนี้มักถูกดึงมาโดยแพ็กเกจอื่นอีกทอดหนึ่ง
เนื่องจากช่องโหว่นี้ยังไม่มีหมายเลข CVE เครื่องมือสแกนที่อ้างอิงฐานข้อมูล CVE เพียงอย่างเดียวอาจรายงานว่าไม่พบปัญหา องค์กรจึงควรตรวจสอบว่าเครื่องมือที่ใช้อยู่ดึงข้อมูลจากฐาน GitHub Security Advisory ด้วยหรือไม่ และค้นหาด้วยหมายเลข GHSA-864f-rcv7-6rh4 โดยตรงเพื่อยืนยัน
ในระดับสถาปัตยกรรม ควรถือว่าแซนด์บ็อกซ์ระดับกระบวนการภายในโปรเซสเดียวเป็นชั้นป้องกันชั้นหนึ่งเท่านั้น ไม่ใช่ชั้นสุดท้าย ระบบที่ต้องรันโค้ดที่ไม่น่าเชื่อถือควรมีการแยกในระดับที่หยาบกว่านั้นรองรับไว้ด้วย ไม่ว่าจะเป็นการรันในโปรเซสแยกที่มีสิทธิ์ต่ำ ในคอนเทนเนอร์ที่จำกัดสิทธิ์ระบบ หรือในเครื่องเสมือนแยก เพื่อให้การหลุดออกจากแซนด์บ็อกซ์ชั้นในยังไม่เท่ากับการได้สิทธิ์บนระบบทั้งหมด และควรตรวจสอบว่าโปรเซสที่รันแซนด์บ็อกซ์มีสิทธิ์เข้าถึงเครือข่ายภายในหรือข้อมูลรับรองของระบบอื่นเกินความจำเป็นหรือไม่