สรุปสั้น

โครงการ Ruby on Rails ได้ปล่อยแพตช์แก้ไขช่องโหว่ระดับวิกฤตในคอมโพเนนต์ Active Storage ที่เปิดทางให้ผู้โจมตีซึ่งไม่ต้องยืนยันตัวตนใดๆ อ่านไฟล์ใดก็ได้จากเซิร์ฟเวอร์ที่รันแอปพลิเคชัน ผ่านการอัปโหลดไฟล์รูปภาพที่ถูกประดิษฐ์ขึ้นมาเป็นพิเศษ ช่องโหว่นี้ถูกกำหนดรหัส CVE-2026-66066 (CVSS 9.5) และสามารถเปิดเผยสภาพแวดล้อมของโปรเซส Rails พร้อมความลับต่างๆ ทั้ง secret_key_base, กุญแจ master key ของ Rails, รหัสผ่านฐานข้อมูล ข้อมูลรับรองของที่เก็บข้อมูลบนคลาวด์ และโทเคน API ซึ่งความลับเหล่านี้อาจนำไปสู่การรันโค้ดจากระยะไกล (RCE) หรือการเคลื่อนที่ทางข้างเข้าสู่ระบบอื่นที่เชื่อมต่ออยู่

แอปพลิเคชันที่ได้รับผลกระทบคือแอปที่ใช้ไลบรารี libvips ในการประมวลผลรูปภาพของ Active Storage และเปิดรับการอัปโหลดรูปจากผู้ใช้ที่ไม่น่าเชื่อถือ โดย Rails จะเลือกใช้ Vips ตั้งแต่ load_defaults 7.0 เป็นต้นมาและค่าเริ่มต้นรุ่นหลังก็ยังคงไว้ ทีมวิจัยจากบริษัท Ethiack และบริษัท GMO Flatt Security ระบุช่วงเวอร์ชันที่ได้รับผลกระทบไว้ที่ Rails 7.0.0 ถึง 7.2.3.1, Rails 8.0.0 ถึง 8.0.5 และ Rails 8.1.0 ถึง 8.1.3 ส่วน Rails 6.0.0 ถึง 6.1.7.10 จะได้รับผลกระทบเฉพาะเมื่อตั้งค่า Active Storage ให้ใช้ Vips ซึ่งไม่ใช่ค่าเริ่มต้นในยุคนั้น ทั้งนี้ทีมความปลอดภัยของ Rails ระบุว่า Rails 7.1 และรุ่นเก่ากว่าหมดอายุการสนับสนุนแล้วและจะไม่มีการ backport ผู้ใช้จึงต้องอัปเกรดขึ้นมาเป็น 7.2.3.2 หรือใหม่กว่าเท่านั้น

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 29 กรกฎาคม 2569 ว่า บริษัท Ethiack ได้แจ้งกับสำนักข่าวว่าสภาพแวดล้อมของ Debian, Ubuntu และ Docker ที่สร้างจากเทมเพลตของ Rails ซึ่งอ้างถึงในงานวิจัยนั้น มีไลบรารีที่จำเป็นติดตั้งมาให้โดยค่าเริ่มต้นและอยู่ในข่ายที่ถูกโจมตีได้ ขณะที่ดิสทริบิวชันอื่นและ base image อื่นอาจไม่สามารถถูกโจมตีได้ ด้านทีมความปลอดภัยของ Rails ยืนยันกับสำนักข่าวว่าช่วงเวอร์ชันที่นักวิจัยระบุนั้นถูกต้อง โดยคำแนะนำสาธารณะครอบคลุมเฉพาะรุ่นที่ยังอยู่ในการสนับสนุนด้านความปลอดภัย ได้แก่ Rails 7.2, 8.0 และ 8.1 ส่วนแอปที่ใช้ MiniMagick ไม่ได้รับผลกระทบผ่านเส้นทางโจมตีนี้

ผู้ดูแลระบบควรอัปเกรดเป็น Rails 7.2.3.2, 8.0.5.1 หรือ 8.1.3.1 และหมุนเปลี่ยนความลับทุกตัวที่โปรเซสของแอปพลิเคชันสามารถอ่านได้ โดยการติดตั้งที่แพตช์แล้วยังต้องใช้ libvips เวอร์ชัน 8.13 ขึ้นไป และหากติดตั้ง ruby-vips ไว้ ก็ต้องเป็นเวอร์ชัน 2.2.1 ขึ้นไปด้วย นอกจากนี้ Rails ยังได้เผยแพร่ชุดเครื่องมือนิติวิทยาศาสตร์ (forensic toolkit) เพื่อช่วยระบุช่วงเวลาที่แอปพลิเคชันเปิดรับความเสี่ยง และค้นหาหลักฐานการถูกโจมตีในที่เก็บอ็อบเจกต์และในระเบียนของ Active Storage

Critical Ruby on Rails Active Storage flaw allows unauthenticated arbitrary file read via image uploads

ในแง่สถานะของโค้ดสาธิตการโจมตี ทีมวิจัยทั้งสองยังไม่ได้เผยแพร่ PoC ณ เวลา 17:30 UTC ของวันที่ 29 กรกฎาคม 2569 แต่หลังจากนั้นมี repository ของบุคคลที่สามบน GitHub ที่อ้างว่าสามารถทำซ้ำเชนการโจมตีตั้งแต่อ่านไฟล์จนถึงรันโค้ดได้ครบ ในห้องทดลอง Docker แบบ loopback เท่านั้น โดยใช้ Rails 8.1.3 และใช้ 8.1.3.1 เป็นตัวควบคุมที่แพตช์แล้ว โค้ดดังกล่าวใช้ไฟล์ MATLAB/HDF5 ที่ประดิษฐ์ขึ้นเพื่ออ่านสภาพแวดล้อมของโปรเซส Rails กู้คืนค่า SECRET_KEY_BASE เซ็นเพย์โหลด Marshal ที่ฝังไว้ แล้วกระตุ้นการเรียกกลับออกนอกระบบด้วย curl ซึ่ง The Hacker News ระบุว่ายังไม่ได้ตรวจสอบความถูกต้องของ PoC นี้ด้วยตัวเอง ต่อมาบริษัท Ethiack ได้เผยแพร่เชนของตัวเองซึ่งใช้กลไกอ่านไฟล์แบบ MATLAB/HDF5 เหมือนกัน แต่ไปถึงการรันโค้ดผ่าน CVE-2025-24293 แทนที่จะใช้เพย์โหลด Marshal

ทีมความปลอดภัยของ Rails แจ้งกับ The Hacker News ว่ายังไม่ทราบว่ามีการโจมตีหรือความพยายามโจมตีทั้งก่อนและหลังการเปิดเผย และระบุว่า Rails ไม่มีระบบเก็บข้อมูลการใช้งานจึงประเมินไม่ได้ว่ามีแอปพลิเคชันจำนวนเท่าใดที่ใช้ Active Storage ร่วมกับ Vips และเปิดรับการอัปโหลดรูปจากผู้ใช้ที่ไม่น่าเชื่อถือ ด้าน Ethiack แจ้งว่าได้รายงานช่องโหว่นี้ไปยัง Rails ครั้งแรกเมื่อวันที่ 22 กรกฎาคม โดยทำ PoC ใช้งานได้ครั้งแรกเมื่อวันที่ 21 กรกฎาคม และ Rails ตอบรับรายงานเมื่อวันที่ 23 กรกฎาคม ทั้งนี้การตรวจสอบของ The Hacker News เมื่อเวลา 17:30 UTC วันที่ 29 กรกฎาคม พบว่า CVE-2026-66066 ยังไม่ถูกบรรจุอยู่ในบัญชี Known Exploited Vulnerabilities (KEV) ของ CISA เวอร์ชัน 2026.07.27 และยังไม่มีตัวเลขที่เชื่อถือได้ว่ามีแอปพลิเคชันกี่รายที่เสี่ยง หรือมีเหยื่อรายใดที่ถูกระบุชื่อ

ความคืบหน้าล่าสุดที่เว็บไซต์ BleepingComputer รายงานเมื่อวันที่ 1 สิงหาคม พ.ศ. 2569 คือทีม Rails เปลี่ยนแผนการเปิดเผยข้อมูล จากเดิมที่ตั้งใจระงับรายละเอียดเชิงเทคนิคไว้ก่อนเพื่อลดความเสี่ยงที่จะถูกโจมตีก่อนผู้ใช้ทันอัปเดต และกำหนดจะเปิดเผยรายละเอียดฉบับเต็มบนเว็บบอร์ดของ Rails ในวันที่ 28 สิงหาคม แต่เมื่อโค้ดสาธิตการโจมตีสาธารณะปรากฏขึ้นอย่างรวดเร็ว ทีมผู้ดูแลจึงตัดสินใจเผยแพร่รายละเอียดทั้งหมดพร้อมเครื่องมือสำหรับการตรวจพิสูจน์หลักฐานออกมาก่อนกำหนด

ด้านบริษัท Akamai ได้ออกคำเตือนเกี่ยวกับ CVE-2026-66066 เช่นกัน โดยตั้งชื่อเชนการโจมตีนี้ว่า “KindaRails2Shell” และเน้นย้ำถึงศักยภาพในการต่อยอดไปสู่การรันโค้ดจากระยะไกล บริษัทอธิบายว่า “เมื่อ secret_key_base ถูกเปิดเผย ผู้โจมตีก็ถือกุญแจเข้ารหัสหลักของแอปพลิเคชันไว้ในมือ พวกเขาสามารถปลอมคุกกี้เซสชัน เซ็น global ID และดัดแปลงข้อมูลที่ถูกซีเรียลไลซ์ ซึ่งแปลตรง ๆ ได้ว่าเป็นการรันโค้ดได้เต็มรูปแบบบนเซิร์ฟเวอร์เบื้องหลัง” ทั้งนี้ Akamai ระบุว่าได้ประสานงานกับบริษัท Ethiack ก่อนการเปิดเผยต่อสาธารณะเพื่อเตรียมมาตรการป้องกันให้ลูกค้า และขณะนี้ได้ปล่อยกฎป้องกันบน web application firewall (WAF) ออกมาแล้ว อย่างไรก็ตามบริษัท Ethiack ตั้งข้อสังเกตว่า WAF อาจช่วยซื้อเวลาให้ผู้ดูแลระบบได้บ้าง แต่ผู้โจมตีที่ใช้เครื่องมือ AI ช่วยน่าจะประกอบเชนการโจมตีขึ้นมาใหม่ได้จากการดูส่วนต่างของแพตช์ การอัปเกรดจึงยังเป็นทางแก้เดียวที่ใช้ได้จริง

Rails ให้เครดิตแก่นาย André Baptista, นาย Bruno Mendes และนาย Rafael Castilho จากบริษัท Ethiack รวมถึงนักวิจัยที่ใช้ชื่อว่า RyotaK จากบริษัท GMO Flatt Security ที่รายงานปัญหานี้เข้ามาอย่างเป็นอิสระจากกัน โดยขณะนี้ Ethiack ได้เผยแพร่รายละเอียดที่เคยระงับไว้ทั้งรูปแบบไฟล์อันตราย วิธีอ่านไฟล์ และเชนที่นำไปสู่การรันโค้ดออกมาแล้ว

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

กลไกอ่านไฟล์อาศัยไฟล์ MAT เวอร์ชัน 7.3 ที่ประดิษฐ์ขึ้น ซึ่งแท้จริงคือคอนเทนเนอร์ HDF5 ที่มีชุดข้อมูลภายนอกชี้ไปยัง path ของไฟล์ที่ผู้โจมตีเลือกเอง เพย์โหลดจะขึ้นต้นด้วยสตริง MATLAB 5.0 ตามที่ libvips คาดหวัง ขณะที่ฟิลด์เวอร์ชันของมันทำให้ libmatio ประมวลผลไฟล์ในฐานะ HDF5 และเดินตามการอ้างอิงภายนอกนั้นไป จุดที่ทำให้โจมตีได้โดยไม่ต้องล็อกอินคือบนเส้นทางอัปโหลดตรง (direct upload) ตัว Active Storage จะยอมรับค่า content_type ที่ฝั่งไคลเอนต์ส่งมาเอง ผู้โจมตีจึงติดป้ายเพย์โหลด MAT ว่าเป็น image/png ได้ จากนั้นจึงนำ variation key ที่ถูกต้องมาเล่นซ้ำกับ blob อันตราย ทำให้ Active Storage เอาไปประมวลผลด้วย libvips แล้วคืนไบต์ของไฟล์เป้าหมายกลับมาในรูปของพิกเซลภาพที่ถูกสร้างขึ้น

ต้นตอของปัญหาอยู่ที่ขอบเขตความไว้วางใจระหว่าง Active Storage กับ libvips โดยคำแนะนำด้านความปลอดภัยของ Rails ระบุว่า libvips รองรับ loader, saver และปฏิบัติการอื่นๆ ซึ่งบางส่วนพึ่งพาไลบรารีของบุคคลที่สามและถูกทำเครื่องหมายว่า “unfuzzed” หรือ “untrusted” เพราะไม่ปลอดภัยเมื่อเจอกับอินพุตที่เป็นปฏิปักษ์ แต่ Active Storage กลับไม่ได้ปิดกั้นปฏิบัติการเหล่านั้น ไฟล์อัปโหลดที่ประดิษฐ์ขึ้นจึงเรียกใช้มันได้และเปิดเผยไฟล์ที่โปรเซส worker ของ Rails อ่านได้ทั้งหมด และที่สำคัญคือแอปที่มีช่องโหว่ไม่จำเป็นต้องเปิดฟีเจอร์ย่อรูปหรือสร้างภาพขนาดย่อไว้โดยเฉพาะ เพราะ Rails ระบุชัดว่า “การสร้าง variant ไม่ใช่เงื่อนไขแยกต่างหาก” อีกทั้งแพตช์สาธารณะยังแสดงให้เห็นว่าทั้งตัว analyzer และ transformer ของ Vips ต่างส่งไฟล์แนบที่ไม่น่าเชื่อถือเข้าไปยังปฏิบัติการที่ไม่ปลอดภัยเหมือนกัน

เมื่อการร้องขอสำเร็จ ผู้โจมตีจะได้กลไกอ่านไฟล์ตามอำเภอใจไว้ในมือ ซึ่งบริษัท Ethiack อธิบายว่าเชนไปสู่การรันโค้ดของตนใช้การเข้าถึงนั้นกู้คืนค่า secret_key_base จากไฟล์ข้อมูลรับรองที่เข้ารหัสไว้หรือจากสภาพแวดล้อมของโปรเซส แล้วปลอม variation key ที่เป็นอันตราย ก่อนใช้ประโยชน์จาก CVE-2025-24293 โดยบริษัทระบุว่าตัว transformer ของ Vips ยอมให้ variation ที่ถูกปลอมขึ้นเรียกใช้ instance_eval และรันโค้ด Ruby ได้ สำหรับการแก้ไข แพตช์จะเรียก Vips.block_untrusted(true) ตั้งแต่ตอนที่ Active Storage เริ่มทำงาน ส่วนแอปที่ยังอัปเดต Rails ทันทีไม่ได้ สามารถตั้งค่า VIPS_BLOCK_UNTRUSTED เมื่อใช้ libvips 8.13 ขึ้นไป หรือเรียก Vips.block_untrusted(true) เองเมื่อใช้ ruby-vips 2.2.1 ขึ้นไป โดย Rails ย้ำว่า libvips รุ่นเก่ากว่านั้นไม่สามารถบล็อกปฏิบัติการเหล่านี้ได้ จึงต้องอัปเกรด libvips หรือถอดออกจากแอปพลิเคชันไปเลย

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

Ruby on Rails ยังเป็นเฟรมเวิร์กเบื้องหลังเว็บแอปพลิเคชันของสตาร์ตอัป ระบบอีคอมเมิร์ซ และระบบภายในองค์กรในไทยจำนวนไม่น้อย โดยเฉพาะระบบที่มีฟังก์ชันให้ผู้ใช้อัปโหลดรูป เช่น โปรไฟล์ผู้ใช้ รูปสินค้า หลักฐานการชำระเงิน หรือเอกสารยืนยันตัวตน ซึ่งเป็นรูปแบบการใช้งานที่ตรงกับเงื่อนไขของช่องโหว่นี้พอดี ยิ่งไปกว่านั้นทีมพัฒนาไทยจำนวนมากใช้ base image ของ Docker ที่สร้างจากเทมเพลตมาตรฐานหรือใช้ Debian/Ubuntu ซึ่งบริษัท Ethiack ระบุว่ามีไลบรารีที่จำเป็นครบตั้งแต่แรก จึงอยู่ในข่ายที่ถูกโจมตีได้ทันทีโดยไม่ต้องตั้งค่าเพิ่ม

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

คำแนะนำ

  • อัปเกรด Rails เป็นเวอร์ชัน 7.2.3.2, 8.0.5.1 หรือ 8.1.3.1 ทันที และหากยังใช้ Rails 7.1 หรือเก่ากว่าซึ่งหมดอายุสนับสนุนแล้ว ต้องอัปเกรดขึ้นมาเป็น 7.2.3.2 เป็นอย่างน้อย
  • ตรวจสอบว่า libvips เป็นเวอร์ชัน 8.13 ขึ้นไป และ ruby-vips เป็น 2.2.1 ขึ้นไป มิฉะนั้นแพตช์จะทำงานได้ไม่สมบูรณ์
  • หากยังอัปเกรดไม่ได้ทันที ให้ตั้งค่า VIPS_BLOCK_UNTRUSTED หรือเรียก Vips.block_untrusted(true) เป็นมาตรการชั่วคราว หรือถอด libvips ออกจากแอปพลิเคชันหากไม่จำเป็น
  • หมุนเปลี่ยนความลับทุกตัวที่โปรเซสแอปอ่านได้ ทั้ง secret_key_base, master key, ข้อมูลรับรองที่ถอดรหัสแล้ว, รหัสผ่านฐานข้อมูล, กุญแจบริการของ Active Storage และโทเคนของบุคคลที่สาม
  • ใช้ชุดเครื่องมือนิติวิทยาศาสตร์ที่ Rails เผยแพร่ เพื่อระบุช่วงเวลาที่ระบบเปิดรับความเสี่ยงและค้นหาหลักฐานการถูกโจมตีในที่เก็บอ็อบเจกต์
  • อย่าเชื่อค่า content_type ที่ไคลเอนต์ส่งมา ให้ตรวจชนิดไฟล์จริงจากเนื้อไฟล์ฝั่งเซิร์ฟเวอร์ และจำกัดชนิดไฟล์ที่รับได้ให้แคบที่สุด
  • แยกโปรเซสที่ประมวลผลไฟล์จากผู้ใช้ออกไปรันในสภาพแวดล้อมที่จำกัดสิทธิ์ ไม่ให้เข้าถึงตัวแปรสภาพแวดล้อมที่มีความลับหรือไฟล์ข้อมูลรับรองโดยตรง

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