สรุปสั้น
นักวิจัยด้านความมั่นคงปลอดภัยไซเบอร์เปิดเผยช่องโหว่ระดับวิกฤตใน 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 ว่า นักวิจัยได้เปิดเผยช่องโหว่ด้านความปลอดภัยระดับวิกฤตในไลบรารีแซนด์บ็อกซ์ที่ถูกใช้อย่างกว้างขวางในระบบนิเวศของ Node.js
เนื่องจาก V8 Isolate แต่ละตัวมีสถานะแยกจากกันและมีฮีปของตัวเอง จึงไม่สามารถส่งวัตถุจาวาสคริปต์จากเธรดหลักของ Node.js เข้าไปยัง isolate ของผู้ปฏิบัติงานได้โดยตรง isolated-vm จึงเปิดคลาสชื่อ ExternalCopy เพื่อทำหน้าที่แปลงวัตถุจาวาสคริปต์ออกจาก isolate ของโฮสต์อย่างปลอดภัย แล้วแปลงกลับเข้าไปใน isolate ของแขก
ช่องโหว่ที่บริษัท Endor Labs ระบุพบอยู่ในองค์ประกอบดังกล่าว โดยเปิดทางให้โค้ดที่ทำงานอยู่ภายในแซนด์บ็อกซ์หลุดออกมาและทำลายความถูกต้องของหน่วยความจำในแอปพลิเคชันโฮสต์ได้
นาย Cristian-Alexandru Staicu นักวิจัยของ Endor Labs ซึ่งได้รับเครดิตในการค้นพบและรายงานช่องโหว่ อธิบายในเอกสารทางเทคนิคที่แบ่งปันกับ The Hacker News ว่า type confusion ในการจัดการตัวเลือก transferList ของ ExternalCopy ทำให้โค้ดที่รันอยู่ในแซนด์บ็อกซ์สามารถทำลายหน่วยความจำในโปรเซสของโฮสต์ได้ และระบุเพิ่มเติมว่า เริ่มจากสิ่งที่มีอยู่เพียงอย่างเดียวคือ ivm.Reference หนึ่งตัว ซึ่งเป็นวิธีมาตรฐานที่โฮสต์ใช้มอบความสามารถใด ๆ ก็ตามให้กับแซนด์บ็อกซ์ ทีมวิจัยสามารถยกระดับบั๊กจากการทำให้ล่มที่ควบคุมตำแหน่งได้ ไปจนถึงการยึดการควบคุมการทำงานของโฮสต์ ซึ่งเป็นการสาธิตการหลุดออกจากแซนด์บ็อกซ์จากแขกสู่โฮสต์อย่างสมบูรณ์
นาย Marcel Laverdet ผู้ดูแลโครงการ ระบุในประกาศเตือนว่าผลกระทบต่ำสุดที่สาธิตได้คือการทำให้ล่มที่ควบคุมตำแหน่งได้อย่างน่าเชื่อถือ ซึ่งเป็นการปฏิเสธการให้บริการที่แขกรายใดก็ตามที่ได้รับ ivm.Reference สามารถกระตุ้นให้เกิดขึ้นได้ โดยการมอบ 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 โดยตรงเพื่อยืนยัน
ในระดับสถาปัตยกรรม ควรถือว่าแซนด์บ็อกซ์ระดับกระบวนการภายในโปรเซสเดียวเป็นชั้นป้องกันชั้นหนึ่งเท่านั้น ไม่ใช่ชั้นสุดท้าย ระบบที่ต้องรันโค้ดที่ไม่น่าเชื่อถือควรมีการแยกในระดับที่หยาบกว่านั้นรองรับไว้ด้วย ไม่ว่าจะเป็นการรันในโปรเซสแยกที่มีสิทธิ์ต่ำ ในคอนเทนเนอร์ที่จำกัดสิทธิ์ระบบ หรือในเครื่องเสมือนแยก เพื่อให้การหลุดออกจากแซนด์บ็อกซ์ชั้นในยังไม่เท่ากับการได้สิทธิ์บนระบบทั้งหมด และควรตรวจสอบว่าโปรเซสที่รันแซนด์บ็อกซ์มีสิทธิ์เข้าถึงเครือข่ายภายในหรือข้อมูลรับรองของระบบอื่นเกินความจำเป็นหรือไม่