Wasmtime แพตช์ช่องโหว่วิกฤต 2 รายการใน Cranelift CVSS 9.9 — โมดูล WebAssembly ของผู้โจมตีหลุด sandbox ได้ ตัวหนึ่งกระทบเฉพาะ ARM64 และมีมาตั้งแต่ปี 2563

สรุปสั้น

Wasmtime คือ runtime สำหรับรันโค้ด WebAssembly นอกเบราว์เซอร์ที่ถูกฝังเป็นไลบรารีในซอฟต์แวร์อื่นได้ และเป็นเบื้องหลังของแพลตฟอร์ม serverless หลายแห่ง เช่น Fastly Compute ที่รันโค้ดของลูกค้าแต่ละรายแยกกันใน sandbox ล่าสุดมูลนิธิ Bytecode Alliance ผู้ดูแล Wasmtime เผยแพร่ประกาศความปลอดภัยเมื่อ 19 ตุลาคม 2569 แจ้งช่องโหว่วิกฤต 2 รายการ ได้แก่ CVE-2026-115889 และ CVE-2026-115893 ซึ่งได้คะแนน CVSS 9.9 จาก 10 ทั้งคู่ ช่องโหว่ทั้งสองอยู่ใน Cranelift คอมไพเลอร์ค่าเริ่มต้นที่แปลง WebAssembly เป็นโค้ดเครื่อง เมื่อผู้โจมตีส่งโมดูลที่สร้างมาเป็นพิเศษให้ Wasmtime คอมไพล์ Cranelift จะสร้างโค้ดเครื่องผิดเพี้ยน จนโมดูลหลุดออกจาก sandbox ที่ควรกักไว้ได้

ตัวแรกกระทบทุกสถาปัตยกรรมโปรเซสเซอร์ ส่วนตัวที่สองกระทบเฉพาะเครื่อง ARM64 และแฝงอยู่ตั้งแต่ Wasmtime เริ่มรองรับ ARM64 ในปี 2563 ความเสี่ยงสูงสุดจึงตกกับบริการที่รับโมดูลจากคนนอกมาคอมไพล์ ยังไม่มีรายงานการโจมตีจริง และ ณ 26 ตุลาคม ยังไม่อยู่ในรายการ KEV ของ CISA แต่ไม่มีวิธีแก้ชั่วคราว ผู้ดูแลต้องอัปเดตเป็น 36.0.19, 48.0.7, 49.0.4 หรือ 50.0.0 และ rebuild ทุกโปรแกรมที่ฝัง Wasmtime เพราะการอัปเดตแค่เครื่องมือบรรทัดคำสั่งไม่พอ

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 26 ตุลาคม 2569 ว่าผู้ดูแล Wasmtime ที่ Bytecode Alliance ประเมินช่องโหว่ทั้งสองไว้ที่ CVSS 9.9 ในประกาศที่เผยแพร่เมื่อ 19 ตุลาคม เวอร์ชันที่แก้ไขออกมาวันที่ 19 และ 20 ตุลาคม โดย Wasmtime 50.0.0 ที่ออกวันที่ 20 ตุลาคม แก้ทั้งสองรายการแล้ว

ไทม์ไลน์ของ CVE-2026-115889 น่าสนใจ เพราะสายพัฒนาหลักแก้ปัญหาไปก่อนหน้านานแล้วโดยไม่ได้ตั้งใจ การเปลี่ยนแปลงที่ merge เมื่อ 18 กุมภาพันธ์ 2569 ขยายฟิลด์ภายในจาก 24 บิตเป็น 32 บิต และออกใน Wasmtime 43.0.0 เมื่อ 20 มีนาคม คำอธิบายของการเปลี่ยนแปลงนั้นพูดถึงแค่การคอมไพล์ฟังก์ชันขนาดใหญ่ได้ ไม่ได้กล่าวถึงความปลอดภัย จนถึงวันที่ 19 ตุลาคม สาย LTS 36.x จึงได้รับการแก้แบบเดียวกัน ประกาศไม่ได้บอกว่าทีมรู้ว่าบั๊กนี้มีผลด้านความปลอดภัยเมื่อไร

ผลที่ตามมา คือ สถานะของแต่ละเครื่องขึ้นกับสายเวอร์ชันและสถาปัตยกรรม เวอร์ชัน 43.x ขึ้นไปพ้นจาก CVE-2026-115889 แล้ว แต่ยังโดน CVE-2026-115893 หากรันบน ARM64 ส่วนเครื่อง ARM64 ที่อัปเดตเป็น 36.0.7, 42.0.2 หรือ 43.0.1 เมื่อเดือนเมษายนเพื่อปิดช่องโหว่หลุด sandbox ของ Cranelift รายการก่อนหน้า ยังคงโดน CVE-2026-115893

ด้านเครื่องมือตรวจ dependency ช่องโหว่ทั้งสองอยู่ในฐานข้อมูล RustSec แล้วในชื่อ RUSTSEC-2026-0380 และ RUSTSEC-2026-0379 ซึ่ง cargo-audit ใช้ตรวจไฟล์ Cargo.lock แต่ ณ 26 ตุลาคม ฐานข้อมูลประกาศความปลอดภัยของ GitHub มีรายการที่ผ่านการตรวจทานแล้วเฉพาะ CVE-2026-115889 ขณะที่ CVE-2026-115893 ยังไม่มี GitHub ระบุว่าเฉพาะรายการที่ตรวจทานแล้วเท่านั้นที่ทำให้ Dependabot แจ้งเตือน ผู้ใช้ Dependabot จึงไม่ควรรอการแจ้งเตือนสำหรับช่องโหว่ฝั่ง ARM64 ส่วน Spin เครื่องมือโอเพนซอร์สสร้างแอป WebAssembly แบบ serverless ที่รันบน Wasmtime อัปเดตเป็น Wasmtime 50.0.0 ในเวอร์ชัน 4.2.4 เมื่อ 21 ตุลาคม

ข้อจำกัดของข้อมูล คือ ประกาศไม่ได้ระบุบริการที่ได้รับผลกระทบ และไม่ได้บอกว่าผู้โจมตีที่หลุด sandbox แล้วจะเข้าถึงอะไรได้บ้าง Fastly ถูกยกเป็นตัวอย่างเพียงเพราะระบุเองว่า Compute รันโค้ดลูกค้าด้วย Wasmtime ไม่ใช่เพราะมีการยืนยันว่าได้รับผลกระทบ

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

sandbox ของ WebAssembly ควรทำงานอย่างไร — โมดูลที่ถูกกักต้องใช้ได้เฉพาะหน่วยความจำของตัวเองและฟังก์ชันของโฮสต์ที่ได้รับอนุญาต และโค้ดกระโดดไปได้เฉพาะตำแหน่งที่ผ่านการตรวจแล้ว ทั้งสองช่องโหว่ทำลายเงื่อนไขนี้ เพราะ Cranelift สร้างโค้ดเครื่องที่ไม่ตรงกับสิ่งที่โมดูลสั่ง เงื่อนไขร่วมของทั้งคู่ คือ ผู้โจมตีต้องส่งโมดูลที่ตัวเองควบคุมให้ Wasmtime เวอร์ชันที่มีช่องโหว่คอมไพล์

CVE-2026-115889 (CVSS 9.9 · ทุกสถาปัตยกรรม) — สาเหตุ คือ ตัวเลขที่ Cranelift ใช้ติดตามค่าภายในฟังก์ชันถูกเก็บในฟิลด์ขนาด 24 บิตก่อนเวอร์ชัน 43 และใน release build ตัวเลขที่ใหญ่เกินฟิลด์จะ overflow โดยไม่มีข้อผิดพลาดใด ๆ Cranelift จึงอ้างถึงค่าผิดตัวและสร้างโค้ดเครื่องผิด ฟังก์ชัน WebAssembly ขนาดใหญ่มากหรือที่จงใจใช้ค่าจำนวนมากสามารถอาศัยจุดนี้สร้าง type confusion แล้วหลุด sandbox ได้ เวอร์ชันที่กระทบ คือ ก่อน 36.0.19 (รวมสาย 24.x) และ 37.0.0 ถึง 42.x

CVE-2026-115893 (CVSS 9.9 · เฉพาะ ARM64/aarch64) — ช่องโหว่อยู่ที่คำสั่ง br_table ซึ่งกระโดดไปยังหนึ่งในหลายตำแหน่งตามค่า index ค่า index ที่เกินตารางต้องไปยังเป้าหมายเริ่มต้น แต่บน ARM64 Cranelift ใช้คำสั่ง branch ที่ไปได้ไกลเพียงราว 1 MiB เมื่อ br_table มีเป้าหมายมากกว่าราว 256,000 รายการ ตารางกระโดดจะใหญ่เกินระยะนั้น และ branch จะชี้ไปผิดที่โดยไม่มีข้อผิดพลาด ประกาศระบุว่า Wasmtime บน ARM64 ที่ใช้ค่าตั้งปกติสามารถถูกโมดูลที่ผู้ใช้ควบคุมบังคับให้กระโดดไปยังโค้ดใดก็ได้ บั๊กนี้มีมาตั้งแต่รองรับ ARM64 ในปี 2563 และกระทบทุกเวอร์ชันก่อน 36.0.19 รวมถึง 37.0.0 ถึง 48.0.6 และ 49.0.0 ถึง 49.0.3

วิธีที่แพตช์แก้ — สำหรับ CVE-2026-115893 เวอร์ชันใหม่ส่ง index ที่เกินตารางผ่านตารางกระโดดเองโดยไม่ต้องใช้ branch ระยะไกล และปฏิเสธการคอมไพล์ br_table ที่มีเป้าหมายเกิน 65,520 รายการ ส่วน CVE-2026-115889 แก้ด้วยการขยายฟิลด์เป็น 32 บิต

สถานะ — ยังไม่มีรายงานการโจมตีจริง ไม่อยู่ใน KEV ของ CISA ณ 26 ตุลาคม 2569 และไม่มีวิธีแก้ชั่วคราว

ผลกระทบ

กลุ่มที่เสี่ยงที่สุด คือ ผู้ให้บริการที่คอมไพล์โมดูล WebAssembly ที่คนอื่นเขียน เช่น แพลตฟอร์ม serverless และ edge computing ระบบปลั๊กอินที่รับโค้ดจากผู้ใช้ และบริการที่รันโค้ดของลูกค้าหลายรายบนเครื่องเดียวกัน สำหรับระบบเหล่านี้ sandbox คือ เส้นแบ่งเดียวระหว่างลูกค้ารายหนึ่งกับลูกค้ารายอื่นและกับตัวโฮสต์ การหลุด sandbox จึงอาจแปลว่าโค้ดของลูกค้ารายหนึ่งเข้าถึงข้อมูลหรือหน่วยความจำของรายอื่นได้ แม้ประกาศจะไม่ได้ระบุขอบเขตที่ชัดเจน ส่วนโปรแกรมที่รันเฉพาะโมดูลที่ตัวเองเขียนและควบคุมเองมีความเสี่ยงต่ำกว่ามาก

ขนาดของปัญหาขยายจากโครงสร้างการแจกจ่ายของ Wasmtime เอง เพราะ Wasmtime ถูกฝังเป็นไลบรารี Rust ในซอฟต์แวร์อื่นจำนวนมาก ทุกโปรแกรมต้อง rebuild ด้วยเวอร์ชันที่แก้แล้ว และนโยบายรองรับที่สั้น (LTS ทุกเลขที่หารด้วย 12 ลงตัวได้ 2 ปี เวอร์ชันอื่นได้ 2 เดือน) ทำให้สายที่หมดอายุ เช่น 24.x LTS ที่สิ้นสุดเมื่อ 20 สิงหาคม 2569 ไม่ได้รับแพตช์เลย เครื่อง ARM64 เป็นกลุ่มที่ต้องระวังเป็นพิเศษ เพราะเคยอัปเดตเพื่อปิดช่องโหว่ Cranelift รอบเดือนเมษายนไปแล้วแต่ยังโดนรอบนี้ และ Dependabot จะยังไม่แจ้งเตือนช่องโหว่ฝั่ง ARM64

คำแนะนำ

• อัปเดตตามสายเวอร์ชันทันที — 36.x → 36.0.19 · 48.x → 48.0.7 · 49.x → 49.0.4 หรือย้ายไป 50.0.0 ซึ่งแก้ครบทั้งสองรายการ สายที่หมดการรองรับแล้ว (รวม 24.x และ 37–47) ต้องย้ายไปสายที่ยังรองรับ เพราะจะไม่มีแพตช์ออกมา
• rebuild ทุกโปรแกรมที่ฝัง Wasmtime — การอัปเดตเครื่องมือ wasmtime บรรทัดคำสั่งไม่ได้แก้โปรแกรมที่ลิงก์ Wasmtime เป็นไลบรารี ต้องอัปเดต dependency ใน Cargo.toml/Cargo.lock แล้ว build และ deploy ใหม่
• ตรวจด้วย cargo-audit ไม่ใช่รอ Dependabot — รัน cargo audit เพื่อหา RUSTSEC-2026-0380 และ RUSTSEC-2026-0379 เพราะ ณ 26 ตุลาคม GitHub Advisory Database ยังไม่มีรายการที่ตรวจทานแล้วของ CVE-2026-115893
• ให้ความสำคัญกับเครื่อง ARM64 ก่อน — รวมถึงเครื่องที่อัปเดตเป็น 36.0.7, 42.0.2 หรือ 43.0.1 เมื่อเดือนเมษายน ซึ่งยังโดน CVE-2026-115893
• ระหว่างรอ deploy — งดรับโมดูล WebAssembly จากคนนอกบนโฮสต์ที่ยังไม่ได้อัปเดต เพราะไม่มีวิธีแก้ชั่วคราว และความเสี่ยงมาจากโมดูลที่คนนอกส่งเข้ามาเท่านั้น
• ตรวจซอฟต์แวร์ปลายน้ำ — เช็กเวอร์ชัน Wasmtime ในเครื่องมือที่ใช้ เช่น Spin ควรเป็น 4.2.4 ขึ้นไป

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

• Two Critical Wasmtime Flaws Could Let Malicious WebAssembly Modules Escape Sandboxes — The Hacker News
• Wasmtime security advisory GHSA-897f-g5gm-fmxm — GitHub
• Wasmtime security advisory GHSA-mghf-wjfp-p5xm — GitHub
• Wasmtime stability and release policy — Wasmtime docs