พบช่องโหว่ CVE-2026-73296 ใน Microsoft UFO ซึ่งเป็น Open-source Framework สำหรับควบคุมการทำงานของอุปกรณ์แบบอัตโนมัติ ช่องโหว่นี้มีคะแนน CVSS สูงถึง 9.4 จัดอยู่ในระดับ Critical กระทบ UFO เวอร์ชันก่อน 3.0.8 ที่ตั้งค่า Mobile MCP ให้เข้าถึงจากระยะไกล ผู้ไม่ประสงค์ดีอาจสามารถดูข้อมูลและควบคุมอุปกรณ์ Android ที่เชื่อมต่อผ่าน Android Debug Bridge (ADB) ได้โดยไม่ต้อง Login ใช้ API Key หรืออาศัยการโต้ตอบจากผู้ใช้งานแต่อย่างใด
รายละเอียดช่องโหว่
Mobile MCP Server และโครงสร้างที่ได้รับผลกระทบ
UFO มี Mobile MCP (Model Context Protocol) Server ที่ออกแบบมาเพื่อเก็บข้อมูลจากและควบคุมอุปกรณ์ Android ที่เชื่อมต่อผ่าน Android Debug Bridge (ADB) โดยแบ่งเป็น 2 ส่วนหลัก ได้แก่
- Data-collection Server — Listen บน TCP Port 8020 ทำหน้าที่รวบรวมข้อมูลจากอุปกรณ์
- Action Server — Listen บน TCP Port 8021 ทำหน้าที่สั่งการและควบคุมอุปกรณ์
จุดที่มาของช่องโหว่
ทั้งสอง Service ไม่มีการบังคับใช้ Authentication Provider หรือ Request-level Authorization Check ในเวอร์ชันที่ได้รับผลกระทบ ซึ่งหมายความว่า MCP Client ใดก็ตามที่สามารถเข้าถึง Port ดังกล่าวได้ทางเครือข่าย สามารถเริ่ม Session และเรียกใช้ Tool ที่มีสิทธิ์สูงได้โดยตรงโดยไม่ต้องผ่านกระบวนการยืนยันตัวตนใดๆ
ผู้โจมตีที่ไม่ผ่านการยืนยันตัวตนอาจสามารถดำเนินการต่อไปนี้บนอุปกรณ์เป้าหมายได้ตามอำเภอใจ
- แตะตำแหน่งใดก็ได้บนหน้าจอ (Tap Arbitrary Screen Location)
- ปัดหน้าจอ (Swipe)
- พิมพ์ข้อความ (Type Text)
- กระตุ้น Android Key Event
- เปิดแอปพลิเคชัน (Launch Applications)
- คลิก UI Control ต่างๆ บนหน้าจอ
ปัจจัยที่ลดหรือเพิ่มความเสี่ยง
ค่า Default Configuration ของ UFO ผูก Mobile MCP Service ไว้กับ Localhost ซึ่งจำกัดการเข้าถึงผ่านเครือข่ายในการติดตั้งที่ไม่ได้ปรับแต่งเพิ่มเติม อย่างไรก็ตาม ความเสี่ยงจะเพิ่มขึ้นอย่างมีนัยสำคัญเมื่อผู้ดูแลระบบตั้งใจเปิด Service ผ่าน Address ที่ไม่ใช่ Loopback เพื่อรองรับการใช้งานหรือการควบคุมอุปกรณ์จากระยะไกล ซึ่งเป็นรูปแบบการใช้งานที่พบได้ทั่วไปในสภาพแวดล้อมที่ต้องการควบคุมอุปกรณ์ Android จำนวนมากจากศูนย์กลาง เช่น Device Farm หรือ Automation Testing Infrastructure
Microsoft ได้เผยแพร่ UFO เวอร์ชัน 3.0.8 เพื่อแก้ไขปัญหานี้แล้ว
ผลกระทบที่อาจเกิดขึ้น
- องค์กรที่ใช้ UFO ควบคุมอุปกรณ์ Android จำนวนมาก เช่น สำหรับ Automation Testing, QA หรือ Device Farm เสี่ยงถูกผู้โจมตีเข้าควบคุมอุปกรณ์จากระยะไกลโดยไม่ทิ้งร่องรอยการ Authentication ใดๆ ในระบบ
- ความสามารถควบคุมหน้าจอและ UI แบบเต็มรูปแบบเปิดทางให้ผู้โจมตีเข้าถึงข้อมูลที่แสดงบนอุปกรณ์ รวมถึงสั่งดำเนินการที่มีผลกระทบจริง เช่น เปิดแอปพลิเคชันทางการเงิน ส่งข้อความ หรือดำเนินการอื่นที่อุปกรณ์ Android รองรับ
- คะแนน CVSS 9.4 สะท้อนความรุนแรงระดับ Critical โดยเฉพาะในสภาพแวดล้อมที่เปิด Mobile MCP Service ให้เข้าถึงจากระยะไกลเพื่อรองรับการใช้งานจริง ซึ่งเป็นสถานการณ์ที่พบได้บ่อยในสภาพแวดล้อม Enterprise ที่ต้องการควบคุมอุปกรณ์จากศูนย์กลาง
- การไม่ต้องอาศัยการโต้ตอบจากผู้ใช้งาน (No User Interaction Required) ทำให้การโจมตีสามารถเกิดขึ้นได้แบบเงียบ โดยเจ้าของอุปกรณ์อาจไม่รู้ตัวว่าอุปกรณ์กำลังถูกควบคุมจากภายนอก
สิ่งที่องค์กรควรทำ
- อัปเดต Microsoft UFO เป็นเวอร์ชัน 3.0.8 หรือใหม่กว่าโดยทันที ซึ่งเป็นเวอร์ชันที่ Microsoft แก้ไขปัญหานี้แล้วอย่างเป็นทางการ
- ตรวจสอบว่า Mobile MCP Service (Port 8020 และ 8021) ถูกผูกไว้กับ Localhost เท่านั้น หากไม่มีความจำเป็นต้องเข้าถึงจากระยะไกล ควรหลีกเลี่ยงการเปิด Service ผ่าน Address ที่ไม่ใช่ Loopback โดยเด็ดขาด
- หากจำเป็นต้องเปิดให้เข้าถึงจากระยะไกลเพื่อรองรับการใช้งานจริง ให้เพิ่มมาตรการควบคุมเพิ่มเติม เช่น VPN, Firewall Rule หรือ Network Segmentation เพื่อจำกัดผู้ที่สามารถเข้าถึง Port ดังกล่าวได้เฉพาะผู้ที่ได้รับอนุญาต
- ตรวจสอบ Inventory ของระบบที่ใช้งาน Microsoft UFO ในองค์กร โดยเฉพาะระบบที่ควบคุมอุปกรณ์ Android จำนวนมาก เพื่อยืนยันว่าไม่มีระบบใดตกหล่นจากการอัปเดต
แนวทางลดความเสี่ยงระยะยาว
1. กำหนดนโยบาย Default-deny สำหรับ Service ที่ควบคุมอุปกรณ์จากระยะไกลในทุกกรณี
โดยเฉพาะ Framework หรือ Tool ที่ออกแบบมาเพื่อ Automation ซึ่งมักมีสิทธิ์สูงในการควบคุมอุปกรณ์ปลายทาง ควรมีการยืนยันตัวตนและ Authorization เป็นค่าเริ่มต้น ไม่ใช่ Feature เสริมที่ต้องเปิดใช้งานเอง
2. ตรวจสอบ Framework หรือ Tool ประเภท MCP (Model Context Protocol) อื่นที่องค์กรใช้งานว่ามีการบังคับใช้ Authentication อย่างเหมาะสมหรือไม่
เนื่องจาก MCP เป็นมาตรฐานที่เริ่มถูกนำมาใช้อย่างแพร่หลายในเครื่องมือ Automation และ AI Agent จึงควรตรวจสอบ Security Posture ของ MCP Server ทุกตัวที่องค์กรพึ่งพา
3. จัดทำ Network Segmentation แยกอุปกรณ์ Android ที่ใช้สำหรับ Testing/Automation ออกจาก Network หลักขององค์กร
เพื่อจำกัดผลกระทบหากมี Service ใดในกลุ่มนี้ถูกโจมตีสำเร็จ ไม่ให้ลุกลามไปยังระบบสำคัญอื่น
4. ติดตาม Security Advisory ของ Open-source Project ที่องค์กรนำมาใช้งานอย่างสม่ำเสมอ
โดยเฉพาะ Project ที่มีการพัฒนาอย่างต่อเนื่องและมีการเพิ่ม Feature ใหม่บ่อยครั้ง ซึ่งอาจมาพร้อมกับความเสี่ยงด้าน Security ที่ยังไม่ถูกตรวจพบ
วิเคราะห์ในมุมมองจาก TXEC
ช่องโหว่ CVE-2026-73296 สะท้อนความเสี่ยงที่ TXEC เฝ้าติดตามมาอย่างต่อเนื่องเกี่ยวกับ Framework และ Tool ประเภท Automation ที่มีสิทธิ์ควบคุมอุปกรณ์หรือระบบในระดับลึก การขาด Authentication เป็นค่าเริ่มต้นใน Service ที่มีความสามารถสูงเช่นนี้ถือเป็นความเสี่ยงเชิงโครงสร้างที่ควรได้รับการออกแบบให้ปลอดภัยตั้งแต่ต้น (Secure by Design) มากกว่าการพึ่งพา Network Configuration เพียงอย่างเดียวเป็นเกราะป้องกัน
TXEC มองว่าการที่ค่า Default ผูก Service ไว้กับ Localhost เป็นมาตรการที่ดีในระดับหนึ่ง แต่ไม่ควรถูกมองว่าเป็นการป้องกันที่เพียงพอ เนื่องจากองค์กรจำนวนมากที่ต้องการใช้งานจริงมักจำเป็นต้องเปิด Service ให้เข้าถึงจากระยะไกล ซึ่งเป็นจุดที่ช่องโหว่นี้แสดงผลกระทบเต็มรูปแบบ องค์กรที่นำ Framework ลักษณะนี้มาใช้งานควรตรวจสอบ Security Posture อย่างรอบด้านก่อนเปิดให้เข้าถึงจากภายนอกเสมอ ไม่ว่า Vendor จะระบุว่า Default Configuration ปลอดภัยเพียงใดก็ตาม
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: Cyber Security News, GBHackers, Microsoft GitHub Security Advisory ]