Xiaozhi-esp32-server 0.9.8 แก้ CVE-2026-116017 อ่านสมุดที่อยู่อุปกรณ์ข้ามบัญชี

Xiaozhi-esp32-server แก้ช่องโหว่ข้ามสิทธิ์อ่านสมุดที่อยู่ของอุปกรณ์

ผู้ดูแลระบบที่เปิดใช้ Xiaozhi-esp32-server ควรตรวจสอบเวอร์ชันของส่วน manager-api หลังมีการเปิดเผย CVE-2026-116017 ช่องโหว่นี้อยู่ที่การตรวจสิทธิ์ก่อนอ่านสมุดที่อยู่ของอุปกรณ์ ผู้ใช้ซึ่งเข้าสู่ระบบด้วยบัญชีทั่วไปหรือบัญชีที่สมัครเองอาจร้องขอข้อมูลของอุปกรณ์ที่ไม่ได้เป็นเจ้าของได้ หากทราบ MAC address ของอุปกรณ์เป้าหมาย การอัปเดตเป็น 0.9.8 เป็นแนวทางแก้ไขตามขอบเขตเวอร์ชันที่ระบุในระเบียน CVE และบันทึกการออกรุ่นของโครงการ

ข่าวนี้เกิดขึ้นเมื่อใด

ประเด็นความปลอดภัยถูกแจ้งต่อสาธารณะใน GitHub issue ของโครงการ เมื่อวันที่ 22 ตุลาคม 2026 เวลา 14:24 UTC โครงการเผยแพร่ รุ่น 0.9.8 เมื่อวันที่ 23 ตุลาคม 2026 เวลา 10:54 UTC โดยระบุชัดว่าแก้การเข้าถึงสมุดที่อยู่เกินสิทธิ์ ส่วนระเบียน CVE-2026-116017 เผยแพร่ครั้งแรกเมื่อวันที่ 24 ตุลาคม 2026 เวลา 11:40 UTC เวลาทั้งหมดนี้เป็น UTC เพื่อให้ตรวจสอบย้อนกับต้นทางได้ตรงกัน

ขอบเขตและผลกระทบ

ตามระเบียน CVE ผลิตภัณฑ์ที่ได้รับผลกระทบคือ xinnan-tech/xiaozhi-esp32-server เวอร์ชันก่อน 0.9.8 จุดที่ระบุคือเมธอด DeviceController.getAddressBook ใน manager-api ซึ่งให้บริการคำขอรูปแบบ /device/address-book/{macAddress} การตรวจว่าผู้เรียกมีสิทธิ์ในอุปกรณ์ตามค่า macAddress ไม่เพียงพอ จึงเกิดปัญหา Insecure Direct Object Reference หรือ IDOR: ตัวระบุออบเจ็กต์ใน URL ถูกใช้เข้าถึงข้อมูลที่อยู่ภายใต้เจ้าของบัญชีอื่น

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

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

วิธีแก้ของโครงการ

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

แม้บันทึกการออกรุ่นกล่าวถึงหลายการกระทำ แต่ CVE-2026-116017 อธิบายผลกระทบที่ยืนยันได้โดยเฉพาะการอ่านข้อมูลผ่าน getAddressBook จึงไม่ควรนำรายการการแก้ทั้งหมดไปเหมารวมเป็นผลกระทบของเลข CVE นี้โดยไม่มีหลักฐานเพิ่ม นอกจากนี้การแก้ด้านสิทธิ์ใน API ควรอยู่บนเซิร์ฟเวอร์ การซ่อนปุ่มในหน้าเว็บหรือแอปผู้ใช้ไม่อาจป้องกันคำขอที่เรียก API โดยตรงได้

สิ่งที่ผู้ดูแลควรทำ

เริ่มจากตรวจเวอร์ชันที่ใช้งานจริงทั้ง source checkout, container image และ deployment ที่อาจรันแยกหลายชุด หากต่ำกว่า 0.9.8 ให้สำรองค่ากำหนดที่จำเป็นและวางแผนอัปเดตตามคู่มือโครงการ ตรวจให้แน่ใจว่า manager-api ที่รับทราฟฟิกหลังอัปเดตเป็นเวอร์ชันใหม่จริง ไม่ใช่เพียงอัปเดต repository หรือ dashboard ส่วนหน้า จากนั้นทดสอบด้วยบัญชีที่เป็นเจ้าของอุปกรณ์และบัญชีทั่วไปอีกบัญชีหนึ่ง: เจ้าของต้องอ่านสมุดที่อยู่ของตัวเองได้ ส่วนบัญชีอื่นต้องไม่ได้ข้อมูลของอุปกรณ์นั้น ทดสอบกับข้อมูลใน lab หรือข้อมูลทดสอบที่ตนมีสิทธิ์เท่านั้น

หากยังอัปเดตทันทีไม่ได้ ให้จำกัดการเข้าถึง manager-api จากเครือข่ายที่ไม่จำเป็น ทบทวนว่าเปิดรับการสมัครบัญชีทั่วไปหรือไม่ และติดตามการเรียก endpoint สมุดที่อยู่ซ้ำ ๆ ด้วย macAddress หลายค่า มาตรการชั่วคราวเหล่านี้ลดโอกาสการใช้ช่องโหว่ แต่ไม่แทนที่การแก้สิทธิ์ใน 0.9.8 ขณะตรวจ log ควรหลีกเลี่ยงการเผยแพร่ MAC address และรหัสผู้ใช้จริงในรายงานสาธารณะ เพราะข้อมูลดังกล่าวเป็นส่วนหนึ่งของสิ่งที่ช่องโหว่เปิดเผย

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

แหล่งข้อมูลต้นทาง: GitHub issue ที่เปิดเผยประเด็น, รุ่น 0.9.8, commit แก้ไข และระเบียน CVE