สรุปสั้น

ช่องโหว่วิกฤต 2 รายการในซอฟต์แวร์โอเพนซอร์สคนละสายกำลังถูกสแกนและลงมือโจมตีจริงพร้อมกัน โดยรายงานมาจากบริษัท watchTowr และบริษัท VulnCheck แยกกันคนละฉบับ ตัวแรกคือ CVE-2026-64849 คะแนน CVSS 9.3 ในแพลตฟอร์ม MLflow ซึ่งเป็นเครื่องมือโอเพนซอร์สสำหรับจัดการวงจรชีวิตโมเดล AI ช่องโหว่นี้เป็น Server-Side Request Forgery ที่ไม่ต้องยืนยันตัวตน ผู้โจมตีที่เข้าถึง Tracking Server ได้สามารถบังคับให้ระบบยิงคำขอ HTTP ไปยังปลายทางใดก็ได้ภายในเครือข่าย รวมถึง cloud metadata endpoint ที่เก็บข้อมูลรับรองของอินสแตนซ์ กระทบ MLflow ทุกเวอร์ชันก่อน 3.15.0 ส่วนตัวที่สองคือ CVE-2026-25895 คะแนน CVSS 9.5 ใน FUXA ซอฟต์แวร์ SCADA/HMI แบบเว็บที่ใช้ในงานเทคโนโลยีเชิงปฏิบัติการและระบบอัตโนมัติในโรงงาน ซึ่งรวมความบกพร่องสองอย่างเข้าด้วยกันคือฟังก์ชันสำคัญที่ไม่มีการยืนยันตัวตนและ path traversal ทำให้ผู้โจมตีจากระยะไกลเขียนไฟล์ลงระบบไฟล์ของเซิร์ฟเวอร์ได้ตามใจและต่อยอดเป็นการรันโค้ดจากระยะไกล กระทบเวอร์ชัน 1.2.9 ลงมา

จังหวะเวลาคือสิ่งที่ทำให้กรณีนี้น่าจับตา watchTowr ระบุว่าตรวจพบผู้ไม่หวังดีกวาดสแกนหาอินสแตนซ์ MLflow ที่เปิดสู่อินเทอร์เน็ตแบบไม่เลือกเป้าภายในไม่กี่ชั่วโมงหลังเลข CVE ถูกออกเมื่อวันที่ 17 สิงหาคม 2569 ขณะที่ VulnCheck เห็นการสแกนเล็ง FUXA เริ่มขึ้นในวันที่ 18 สิงหาคม 2569 ต่อมาในวันที่ 19 สิงหาคม 2569 หน่วยงาน CISA ของสหรัฐฯ ได้เพิ่ม CVE-2026-64849 เข้าบัญชี Known Exploited Vulnerabilities พร้อมกำหนดให้หน่วยงานรัฐบาลกลางฝ่ายพลเรือนแพตช์ให้เสร็จภายในวันที่ 2 กันยายน 2569

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 19 สิงหาคม 2569 ว่ามีรายงานอิสระจากทั้ง watchTowr และ VulnCheck ชี้ตรงกันว่าช่องโหว่ใน MLflow และ FUXA กำลังเผชิญกับความพยายามสแกนและโจมตีจริง โดยฝั่ง MLflow มีหลักฐานว่าไม่ได้หยุดอยู่แค่การสำรวจแล้ว

นาย Yordan Ganchev ผู้เชี่ยวชาญข่าวกรองภัยคุกคามระดับหลักของ watchTowr ให้ข้อมูลกับ The Hacker News ว่าช่องโหว่นี้ “เปิดทางให้ผู้โจมตีใช้ประโยชน์จากข้อบกพร่องในเว็บฮุกของ model-registry ใน MLflow เพื่อส่งผ่านคำขอผ่านระบบที่ได้รับผลกระทบไปคุยกับบริการภายในได้” และอธิบายต่อว่า “จุดที่ทำให้ข้ามการแก้ไขรอบก่อนหน้าได้คือวิธีที่มันจัดการกับการเปลี่ยนเส้นทางของเว็บ” พร้อมระบุว่า “หลักฐานจากเทเลเมทรีของฮันนีพ็อตทั่วโลกของเราชี้ว่าผู้โจมตีกำลังใช้ช่องโหว่นี้เล่นงานระบบ MLflow ที่โฮสต์บนคลาวด์ เพื่อพยายามดึงข้อมูลรับรองและความลับออกมาจากที่อยู่ไอพีภายในและบริการที่รู้กันดีอยู่แล้ว” ส่วนโพสต์ของ watchTowr บนลิงก์ดอินระบุสั้นแต่ชัดว่า “ผู้โจมตีกำลังใช้ช่องโหว่นี้เข้าถึงบริการ cloud metadata โดยตรง และดูดข้อมูลรับรองคลาวด์กับความลับออกไป”

ฝั่ง FUXA นางสาว Caitlin Condon รองประธานฝ่ายวิจัยของ VulnCheck โพสต์บนลิงก์ดอินว่า “คำขอของผู้โจมตีพยายามเขียนทับไฟล์ main.js ด้วยข้อมูลขยะผ่านเส้นทาง path traversal ของ CVE-2026-25895” แต่ย้ำว่า “ยังไม่มีการปล่อยเพย์โหลด RCE ลงมา” VulnCheck ระบุว่าเห็นที่อยู่ไอพีเพียงแหล่งเดียวกวาดสแกนหาอินสแตนซ์ FUXA ที่มีช่องโหว่ทั่วอินเทอร์เน็ต โดยประเมินว่ามีการติดตั้ง FUXA ที่เปิดสู่อินเทอร์เน็ตสาธารณะราว 60 แห่งเท่านั้น

Condon ยังชี้ด้วยว่าในรอบปีที่ผ่านมา ช่องโหว่อีก 2 รายการใน FUXA คือ CVE-2026-25939 และ CVE-2023-33831 ก็เผชิญความพยายามโจมตีจริงเช่นกัน โดยรายหลังมีกิจกรรม “ย้อนกลับไปได้ถึงเดือนพฤศจิกายน 2568 และล่าสุดคือเมื่อวานนี้” หมายความว่าซอฟต์แวร์ตัวนี้ถูกไล่เก็บช่องโหว่ต่อเนื่องมาแล้วหลายรอบ ไม่ใช่เป้าใหม่ที่เพิ่งถูกค้นพบ

วิธีการโจมตี

หัวใจของ CVE-2026-64849 อยู่ที่กลไกเว็บฮุกของ model registry ใน MLflow ซึ่งออกแบบมาให้เซิร์ฟเวอร์ยิงคำขอ HTTP ออกไปยังปลายทางที่ผู้ใช้กำหนดเองเมื่อมีเหตุการณ์เกี่ยวกับโมเดลเกิดขึ้น เมื่อผู้โจมตีคุมค่าปลายทางได้และ Tracking Server เปิดให้เข้าถึงโดยไม่ต้องยืนยันตัวตน เซิร์ฟเวอร์ก็กลายเป็นตัวกลางที่ยิงคำขอเข้าไปในเครือข่ายภายในแทนผู้โจมตี ปลายทางที่มีค่าที่สุดคือบริการ metadata ของผู้ให้บริการคลาวด์ที่ผูกกับที่อยู่ไอพีภายในซึ่งเป็นที่รู้กันทั่วไป เพราะเป็นจุดที่แจกโทเคนและข้อมูลรับรองชั่วคราวของอินสแตนซ์ให้กับเวิร์กโหลดที่รันอยู่บนเครื่องนั้น

จุดที่ต้องเน้นคือ watchTowr บอกว่าช่องโหว่นี้ “ข้ามการแก้ไขรอบก่อนหน้า” ได้เพราะวิธีจัดการการเปลี่ยนเส้นทาง นั่นแปลว่าการป้องกัน SSRF ที่มีอยู่เดิมทำงานในลักษณะตรวจปลายทางที่ระบุมาในคำขอแรก แต่ไม่ได้ตรวจซ้ำเมื่อปลายทางนั้นตอบกลับมาด้วยการเปลี่ยนเส้นทางไปยังที่อยู่ภายใน ผู้โจมตีจึงชี้เว็บฮุกไปยังเซิร์ฟเวอร์ของตัวเองที่ผ่านการตรวจ แล้วให้เซิร์ฟเวอร์นั้นส่ง redirect กลับไปหา metadata endpoint อีกที ผลคือด่านกรองเดิมไม่มีโอกาสได้เห็นปลายทางจริง

ส่วน CVE-2026-25895 ใน FUXA เป็นการรวมสองปัญหาที่ต่างคนต่างไม่ร้ายแรงเท่านี้เข้าด้วยกัน คือฟังก์ชันสำคัญที่ไม่มีการตรวจสิทธิ์ก่อนเรียกใช้ กับการที่พารามิเตอร์เส้นทางไฟล์ไม่ถูกกรอง เมื่อรวมกันแล้วผู้โจมตีที่ไม่มีบัญชีสามารถกำหนดเส้นทางไฟล์ปลายทางออกนอกไดเรกทอรีที่ตั้งใจไว้และเขียนไฟล์อะไรก็ได้ลงไป การเขียนทับไฟล์ที่แอปพลิเคชันเรียกใช้งานเองอย่าง main.js จึงกลายเป็นเส้นทางสู่การรันโค้ดบนเซิร์ฟเวอร์ ทั้งนี้พฤติกรรมที่ VulnCheck สังเกตได้จนถึงตอนนี้ยังเป็นการเขียนข้อมูลขยะทับไฟล์เท่านั้น ซึ่งมีลักษณะเหมือนการตรวจสอบว่าเป้าหมายมีช่องโหว่จริงหรือไม่ก่อนลงมือขั้นต่อไป

ผลกระทบ

ความแตกต่างที่สำคัญระหว่างสองช่องโหว่นี้คือขนาดของพื้นผิวการโจมตี MLflow เป็นเครื่องมือมาตรฐานในสายงานพัฒนาโมเดล AI และมักถูกติดตั้งไว้บนคลาวด์เพื่อให้ทีมข้อมูลเข้าถึงร่วมกัน หลายองค์กรจึงเปิด Tracking Server ทิ้งไว้ในเครือข่ายภายในหรือแม้แต่บนอินเทอร์เน็ตโดยเชื่อว่าเป็นแค่เครื่องมือภายในที่ไม่มีข้อมูลอ่อนไหว แต่สิ่งที่ผู้โจมตีต้องการไม่ใช่โมเดลหรือชุดข้อมูล กลับเป็นสิทธิ์ของอินสแตนซ์ที่รันเซิร์ฟเวอร์ตัวนั้นอยู่ ข้อมูลรับรองที่ดึงจาก metadata endpoint ได้มักเป็นบทบาทที่ผูกกับที่เก็บข้อมูล คลังสิ่งประดิษฐ์ และบริการอื่นในบัญชีคลาวด์เดียวกัน การเจาะเซิร์ฟเวอร์เครื่องมือ MLOps หนึ่งเครื่องจึงมีโอกาสกลายเป็นการเข้าถึงบัญชีคลาวด์ทั้งบัญชี

FUXA อยู่คนละขั้ว จำนวนอินสแตนซ์ที่เปิดสู่อินเทอร์เน็ตสาธารณะราว 60 แห่งถือว่าน้อยมากเมื่อเทียบกับซอฟต์แวร์ทั่วไป แต่บริบทของมันคือระบบควบคุมในโรงงานและงานเทคโนโลยีเชิงปฏิบัติการ ซึ่งเครื่องหนึ่งเครื่องอาจผูกกับกระบวนการผลิตจริงที่หยุดไม่ได้ การมีผู้โจมตีเพียงรายเดียวไล่สแกนทั้งอินเทอร์เน็ตเพื่อหาเป้าไม่กี่สิบแห่งจึงไม่ใช่สัญญาณว่าปัญหาเล็ก แต่แปลว่าเป้าหมายทั้งชุดถูกกวาดครบได้ในเวลาไม่นาน และการที่ FUXA เจอความพยายามโจมตีมาแล้ว 3 รายการในรอบปีเดียวบ่งชี้ว่าซอฟต์แวร์ HMI แบบโอเพนซอร์สที่เปิดสู่อินเทอร์เน็ตกำลังอยู่ในเรดาร์ของผู้โจมตีอย่างต่อเนื่อง

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

คำแนะนำ

องค์กรที่รัน MLflow ควรจัดลำดับความสำคัญของการอัปเดตเป็นเวอร์ชัน 3.15.0 ขึ้นไปกับระบบที่เปิดสู่ภายนอกก่อนเป็นอันดับแรก จากนั้นทบทวนล็อกการตรวจสอบย้อนหลังเพื่อหาร่องรอยการเรียกเว็บฮุกที่ผิดปกติ โดยเฉพาะคำขอที่ปลายทางเป็นที่อยู่ไอพีภายในหรือมีการเปลี่ยนเส้นทางไปยังบริการ metadata และตรวจว่าข้อมูลรับรองที่อ่อนไหวถูกเปิดเผยไปแล้วหรือไม่ หากพบร่องรอยควรหมุนกุญแจและโทเคนทั้งชุดที่ผูกกับอินสแตนซ์นั้นทันที ไม่ใช่เฉพาะที่เห็นว่าถูกเรียก

ในระดับสถาปัตยกรรม ควรบังคับใช้ IMDSv2 หรือกลไกเทียบเท่าที่ต้องใช้โทเคนก่อนอ่าน metadata เพื่อให้ SSRF ธรรมดาไม่พอที่จะดึงข้อมูลรับรองออกไป ลดสิทธิ์ของบทบาทที่ผูกกับอินสแตนซ์ให้เหลือเท่าที่งานต้องใช้จริง และไม่วาง Tracking Server ไว้บนอินเทอร์เน็ตสาธารณะโดยไม่มีชั้นยืนยันตัวตนคั่นหน้า สำหรับผู้ใช้ FUXA ควรอัปเดตให้พ้นเวอร์ชัน 1.2.9 ถอดระบบออกจากการเข้าถึงโดยตรงจากอินเทอร์เน็ต และตรวจความสมบูรณ์ของไฟล์แอปพลิเคชันโดยเฉพาะไฟล์จาวาสคริปต์ฝั่งหน้าเว็บว่าถูกเขียนทับไปแล้วหรือไม่ เพราะร่องรอยที่ VulnCheck เห็นคือการเขียนข้อมูลขยะทับไฟล์ ซึ่งจะไม่แสดงอาการชัดเจนนอกจากตรวจไฟล์เอง

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