Canonical แนะนำให้ผู้ใช้ LXD และ MicroCloud อัปเดตทันที หลังแก้ช่องโหว่การตรวจสอบใบรับรอง TLS ซึ่งอาจเปิดให้ผู้โจมตีสวมรอยเป็นไคลเอนต์ที่ระบบเชื่อถือได้ โดยมีเพียงใบรับรองสาธารณะของไคลเอนต์นั้น ไม่ต้องครอบครองกุญแจส่วนตัว [1]
เงื่อนไขและผลกระทบที่ยืนยันแล้ว
ผู้โจมตีต้องเข้าถึง HTTPS API ของระบบและมีใบรับรองสาธารณะของตัวตนที่ระบบเชื่อถือ ผลกระทบขึ้นอยู่กับสิทธิ์ของตัวตนนั้น และอาจถึงระดับ root บนเครื่องโฮสต์ ใน MicroCloud ผู้ผลิตระบุความเสี่ยงจากการดักใบรับรองของสมาชิกระหว่างเข้าร่วมคลัสเตอร์ [1]
Ubuntu ระบุรหัส CVE-2026-112816 และปัญหาการตรวจสอบใบรับรองของ LXD ประกาศที่ตรวจไม่ใช่หลักฐานยืนยันการโจมตีจริงในองค์กรไทย และบทความนี้ไม่สรุปว่ามีหรือไม่มีการโจมตีจริงจากการพบหรือไม่พบรายการ KEV [2]
รุ่นแก้ไขตามช่องทาง Snap
| ผลิตภัณฑ์ / Channel | รุ่นแก้ไข |
|---|---|
| LXD 6/stable | 6.10.1 |
| LXD 5.21/stable | 5.21.9 |
| LXD 5.0/stable | 5.0.11 |
| LXD 4.0/stable | 4.0.15 |
| MicroCloud 2/stable | 2.1.5 |
| MicroCloud 3/stable | 3.4.1 |
ตารางผู้ผลิตระบุวันออกแพตช์ 29 ตุลาคม 2569 และระบุว่ามีการทยอยปล่อย LXD จาก candidate สู่ stable จึงควรตรวจรุ่นที่ติดตั้งจริงหลังสั่งอัปเดต [1]
มุมมอง ALPHASEC: สิ่งที่องค์กรไทยควรทำ
- สำรวจคลัสเตอร์และ API: ให้ทีมคลาวด์ระบุโฮสต์ ช่องทาง Snap และเครือข่ายที่เข้าถึง API ได้ รวมถึงระบบทดสอบและระบบที่คู่ค้าดูแล
- อัปเดตและตรวจผล: วางแผนเปลี่ยนแปลงตามขั้นตอนขององค์กร ใช้
sudo snap refresh lxdและsudo snap refresh microcloudสำหรับผลิตภัณฑ์ที่ติดตั้ง แล้วตรวจว่าได้รุ่นแก้ไขจริง - จำกัดเครือข่ายบริหาร: ให้เฉพาะเครื่องและเครือข่ายที่จำเป็นเข้าถึง API ทบทวนไคลเอนต์ที่เชื่อถือและสิทธิ์ของแต่ละตัวตน การจำกัดเครือข่ายช่วยลดช่องทางเข้าถึง แต่ยังต้องแพตช์
- ตรวจย้อนหลัง: ตรวจการเพิ่มสมาชิก การเปลี่ยนสิทธิ์ และการจัดการ VM/container ที่ไม่สัมพันธ์กับงานอนุมัติ หากพบผิดปกติให้รักษาบันทึกและเข้าสู่กระบวนการตอบสนองเหตุ
ข้อเสนอด้านการควบคุมและการตรวจย้อนหลังเป็นการวิเคราะห์ของ ALPHASEC ไม่ใช่การยืนยันว่าองค์กรใดถูกบุกรุก
แหล่งอ้างอิง
อ่านประกาศฉบับเต็ม 1 พฤศจิกายน 2569 เวลา 17:46 น. ไทย ไม่ใช้คะแนนจากพาดหัวเป็นเหตุผลหลักในการจัดลำดับความเร่งด่วน