VulnCheck รายงานการใช้ช่องโหว่ร้ายแรง 2 รายการในการโจมตีจริง ได้แก่ CVE-2026-0768 ใน Langflow ซึ่งมีคะแนน CVSS 9.8 เปิดทางให้สั่งรันโค้ด Python ด้วยสิทธิ์ Root โดยไม่ต้องยืนยันตัวตน และ CVE-2026-66066 หรือที่รู้จักในชื่อ "KindaRails2Shell" ใน Ruby on Rails ซึ่งมีคะแนน CVSS 9.5 ทำให้ผู้ไม่ประสงค์ดีอ่านไฟล์บน Server และเข้าถึงข้อมูลสำคัญ เช่น รหัสผ่าน Database, Cloud Credential และ API Token ได้
รายละเอียดช่องโหว่
CVE-2026-0768 — Langflow Unauthenticated RCE
Langflow เป็น Framework Open-source ที่นิยมใช้สร้างและจัดการ AI/LLM Workflow ช่องโหว่นี้อยู่ใน Code Validator ของ Custom Component Editor ซึ่งขาดการตรวจสอบ Input อย่างเหมาะสม เปิดทางให้ผู้โจมตีที่ไม่ต้องผ่านการยืนยันตัวตนใดๆสามารถส่งโค้ด Python ที่สร้างขึ้นเป็นพิเศษเข้าไปใน Component Editor และให้ Server รันโค้ดนั้นด้วยสิทธิ์ Root ได้โดยตรง คะแนน CVSS ที่สูงถึง 9.8 สะท้อนถึงความรุนแรงระดับสูงสุด เนื่องจากไม่ต้องอาศัยเงื่อนไขพิเศษหรือการโต้ตอบจากผู้ใช้งานใดๆ
CVE-2026-66066 "KindaRails2Shell" — Ruby on Rails Active Storage / libvips
ช่องโหว่นี้เกิดจากการทำงานร่วมกันระหว่าง Active Storage ของ Ruby on Rails กับ Library ประมวลผลรูปภาพ libvips ผู้โจมตีสามารถอัปโหลดรูปภาพที่สร้างขึ้นเป็นพิเศษเพื่อกระตุ้นให้เกิดการอ่านไฟล์ตามอำเภอใจ (Arbitrary File Read) บน Server ก่อนนำไปสู่การรั่วไหลของข้อมูลสำคัญระดับ Application ได้แก่
secret_key_baseของ Rails ซึ่งใช้ในการเข้ารหัส Session และ Cookie- Rails Master Key ที่ใช้เข้ารหัส Credential File ของ Application
- รหัสผ่าน Database
- Cloud Storage Credential
- API Token ต่างๆ ที่ Application เก็บไว้
การรั่วไหลของข้อมูลเหล่านี้อาจนำไปสู่ Remote Code Execution ได้ในหลายกรณี เนื่องจาก secret_key_base ที่รั่วไหลสามารถถูกนำไปใช้ปลอมแปลง Session หรือ Cookie ที่ผ่านการเข้ารหัสของ Rails ได้
รูปแบบการโจมตีที่พบจริง
จากการตรวจสอบของ VulnCheck พบว่า
- Traffic ที่โจมตี Langflow ส่วนใหญ่มีต้นทางจากรัสเซีย และมุ่งเป้าไปยัง Canary System (ระบบดักจับผู้โจมตีเพื่อการวิจัย) ที่ตั้งอยู่ในสหราชอาณาจักร
- การโจมตี Ruby on Rails มุ่งเป้าไปยัง Canary System ในสิงคโปร์ อิสราเอล และสหราชอาณาจักร โดยพบความเชื่อมโยงกับ Source IP ในฝรั่งเศส และมีการสร้างการเชื่อมต่อ Command-and-Control (C2) ไปยัง Host ในอิสราเอล
รูปแบบการกระจายตัวทางภูมิศาสตร์ของทั้ง Source และ Target บ่งชี้ว่านี่เป็นปฏิบัติการที่มีการจัดระเบียบและใช้โครงสร้างพื้นฐานหลายจุดในการดำเนินการ ไม่ใช่การโจมตีแบบเดี่ยวโดยผู้ก่อเหตุรายเดียว
ผลกระทบที่อาจเกิดขึ้น
- ทั้งสองช่องโหว่มีคะแนน CVSS ระดับ Critical (9.8 และ 9.5) และกำลังถูกใช้โจมตีจริงในปัจจุบัน ไม่ใช่เพียงช่องโหว่เชิงทฤษฎีที่ยังไม่มีการยืนยันการใช้งานจริง องค์กรที่มีระบบเปิดให้เข้าถึงจากอินเทอร์เน็ตจึงมีความเสี่ยงสูงและเร่งด่วน
- องค์กรที่ใช้ Langflow สำหรับสร้าง AI/LLM Workflow มีความเสี่ยงถูกยึดควบคุม Server ด้วยสิทธิ์ Root ได้ทันที โดยไม่ต้องผ่านการยืนยันตัวตนใดๆ ซึ่งเป็นความเสี่ยงระดับสูงสุดสำหรับระบบที่เปิดให้เข้าถึงจากภายนอก
- องค์กรที่ใช้ Ruby on Rails ร่วมกับ Active Storage และ libvips เสี่ยงหลุด Credential สำคัญที่อาจนำไปสู่การยึดควบคุม Application ทั้งระบบ การหลุดของ secret_key_base และ Master Key เปิดทางให้ผู้โจมตีปลอมแปลง Session หรือเข้าถึงข้อมูลที่เข้ารหัสไว้ทั้งหมด
- การโจมตีที่มีการเชื่อมต่อ C2 บ่งชี้ว่าเป้าหมายไม่ใช่เพียงการทดสอบช่องโหว่ แต่มุ่งสร้างช่องทางควบคุมระยะยาวบนระบบที่ถูกบุกรุก ซึ่งอาจนำไปสู่การขโมยข้อมูลหรือใช้เป็นฐานโจมตีระบบอื่นต่อไป
สิ่งที่องค์กรควรทำ
- อัปเดต Langflow และ Ruby on Rails เป็นเวอร์ชันที่แก้ไขช่องโหว่นี้แล้วโดยทันที และตรวจสอบ Inventory ของระบบทั้งหมดในองค์กรเพื่อยืนยันว่าไม่มี Instance ใดตกหล่นจากการแพตช์
- ตรวจสอบ Log การเข้าถึง Custom Component Editor ของ Langflow ว่ามีการส่งโค้ด Python ที่ผิดปกติหรือไม่ โดยเฉพาะจาก IP Address ที่ไม่คุ้นเคยหรือมีต้นทางจากต่างประเทศที่ไม่สอดคล้องกับผู้ใช้งานปกติ
- ตรวจสอบ Log การอัปโหลดรูปภาพผ่าน Active Storage ว่ามีไฟล์ที่มีโครงสร้างผิดปกติหรือขนาดผิดปกติหรือไม่ ซึ่งอาจเป็นสัญญาณของความพยายามใช้ช่องโหว่ CVE-2026-66066
- หากสงสัยว่าถูกโจมตีสำเร็จ ให้ Rotate secret_key_base, Rails Master Key, รหัสผ่าน Database, Cloud Credential และ API Token ที่เกี่ยวข้องทั้งหมดทันที เนื่องจากข้อมูลเหล่านี้อาจรั่วไหลไปแล้วแม้จะไม่พบสัญญาณการโจมตีขั้นถัดไป
แนวทางลดความเสี่ยงระยะยาว
1. จำกัดการเข้าถึง Langflow Instance จากอินเทอร์เน็ตสาธารณะให้เหลือน้อยที่สุด
เนื่องจากช่องโหว่นี้ไม่ต้องอาศัยการยืนยันตัวตน การจำกัดการเข้าถึงผ่าน VPN, Firewall หรือ Network Segmentation ช่วยลดพื้นที่การโจมตี (Attack Surface) ได้อย่างมีนัยสำคัญ แม้จะยังไม่ได้แพตช์ทันที
2. ทบทวนการใช้งาน Library ประมวลผลไฟล์ (เช่น libvips) ในทุก Application ที่รับ Input จากผู้ใช้งานภายนอก
ช่องโหว่ประเภท File Processing มักเกิดจาก Library ที่ทำงานร่วมกับ Framework หลัก องค์กรควรติดตาม Security Advisory ของ Library เหล่านี้อย่างสม่ำเสมอ ไม่ใช่เพียง Framework หลักเท่านั้น
3. จัดเก็บ Secret และ Credential สำคัญด้วย Secret Management System แยกต่างหาก แทนการฝังไว้ใน Configuration File โดยตรง
เพื่อลดผลกระทบหาก Application ถูกบุกรุกและมีการอ่านไฟล์ Configuration ได้ การใช้ Secret Manager ที่มีการหมุนเวียน Credential อัตโนมัติช่วยจำกัดหน้าต่างเวลาที่ Credential ที่รั่วไหลจะยังใช้งานได้
4. ติดตาม Threat Intelligence จาก VulnCheck และแหล่งข้อมูลที่ติดตาม Active Exploitation อย่างสม่ำเสมอ
เนื่องจากช่องโหว่ที่ถูกใช้โจมตีจริงมีความเร่งด่วนสูงกว่าช่องโหว่ที่ยังไม่มีรายงานการใช้งาน การติดตามแหล่งข้อมูลที่รายงาน Active Exploitation ช่วยให้องค์กรจัดลำดับความสำคัญในการแพตช์ได้อย่างเหมาะสม
วิเคราะห์ในมุมมองจาก TXEC
เหตุการณ์นี้ตอกย้ำความเสี่ยงที่ TXEC ให้ความสำคัญมาโดยตลอดเกี่ยวกับช่องโหว่ในเครื่องมือและ Framework ที่องค์กรนำมาใช้สร้างระบบของตนเอง ไม่ว่าจะเป็น Framework สำหรับ AI/LLM Workflow อย่าง Langflow ที่กำลังได้รับความนิยมเพิ่มขึ้นอย่างรวดเร็ว หรือ Framework ระดับ Enterprise ที่ใช้งานมายาวนานอย่าง Ruby on Rails การที่ทั้งสองช่องโหว่ถูกใช้โจมตีจริงพร้อมกันในช่วงเวลาใกล้เคียงกัน และมีรูปแบบการกระจายตัวทางภูมิศาสตร์ที่ซับซ้อนทั้ง Source และ Target สะท้อนถึงปฏิบัติการที่มีการวางแผนและอาจดำเนินการโดยกลุ่มที่มีทรัพยากรเพียงพอในการสแกนและใช้ช่องโหว่หลายรายการพร้อมกัน
TXEC มองว่าองค์กรที่นำ Framework Open-source มาใช้งาน โดยเฉพาะกลุ่มที่เกี่ยวข้องกับ AI/LLM ที่กำลังเติบโตอย่างรวดเร็ว ควรให้ความสำคัญกับกระบวนการติดตาม Security Advisory และการแพตช์อย่างรวดเร็วเทียบเท่ากับ Framework ระดับ Enterprise ที่ใช้งานมานาน เนื่องจากความเร็วในการนำ Framework ใหม่มาใช้งานมักไม่สอดคล้องกับความเร็วในการตรวจสอบและแพตช์ช่องโหว่ ซึ่งเป็นช่องว่างที่ผู้โจมตีมักใช้ประโยชน์
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: The Hacker News, VulnCheck, Rapid7 ]