OpenStack keystonemiddleware CVE-2026-115642 ข้าม access rules ผ่าน X-Service-Token
OpenStack VMT แจ้ง CVE-2026-115642 ผู้ถือ application credential ที่ถูกจำกัดอาจใช้ X-Service-Token ข้าม access rules ตรวจช่วงรุ่นและสถานะแพตช์
OpenStack keystonemiddleware พบ CVE-2026-115642: X-Service-Token อาจข้ามข้อจำกัด application credential
ทีม OpenStack Vulnerability Management Team (VMT) เปิดเผยช่องโหว่ CVE-2026-115642 ใน keystonemiddleware เมื่อวันที่ 29 ตุลาคม 2026 ผู้ใช้ที่มี application credential ซึ่งถูกจำกัดด้วย access_rules อาจแนบ HTTP header X-Service-Token ที่กำหนดเองเพื่อให้คำขอข้ามข้อจำกัดดังกล่าว ส่งผลให้ได้รับสิทธิมากกว่าที่ credential นั้นควรมี ประกาศทางการระบุว่าการติดตั้งที่ใช้ application credential access rules หรือบังคับ token binding ได้รับผลกระทบ
จุดสำคัญของข่าวนี้คือผู้โจมตี ต้องมี application credential ที่มีข้อจำกัดอยู่ก่อน จึงไม่ควรเรียกว่าเป็นช่องให้บุคคลภายนอกที่ไม่มี credential เข้าถึงระบบได้โดยตรง ความรุนแรงขึ้นอยู่กับสิทธิที่ credential ถูกจำกัดไว้และบริการที่ใช้ middleware นี้ตรวจคำขอ หากขอบเขต access rules เป็นกลไกหลักในการจำกัด API ที่ credential ใช้งานได้ ช่องโหว่อาจทำให้การแยกสิทธิที่ผู้ดูแลตั้งใจไว้ไม่ทำงานตามคาด
ไทม์ไลน์จากแหล่งต้นทาง
ประวัติใน Launchpad แสดงว่ารายงานเดิมอยู่ในสถานะ Private Security และมีการเปลี่ยนเป็น Public Security วันที่ 29 ตุลาคม 2026 โดยผู้ประสานงานแจ้งล่วงหน้าว่าจะเปิดเผยประมาณ 14:00 UTC ในวันนั้น แพตช์ถูกส่งเข้า OpenDev Gerrit ต่อสาธารณะตั้งแต่ประมาณ 14:05–14:07 UTC และประกาศ OSSA-2026-050 ของ OpenStack VMT ส่งไปยังรายชื่อ oss-security วันที่ 29 ตุลาคม 2026 เวลา 14:47:50 UTC จึงตรวจยืนยันการเปิดเผยสาธารณะจากโครงการได้ในวันที่ 29 ตุลาคม ระเบียน CVE Program ของ CVE-2026-115642 เผยแพร่ครั้งแรกวันที่ 30 ตุลาคม 2026 เวลา 16:23:23 UTC ทั้งสองวันอยู่ภายใน 48 ชั่วโมงของรอบตรวจ
การแก้ไขถูก merge เข้า branch พัฒนา master วันที่ 29 ตุลาคม 2026 เวลา 17:19 UTC, branch stable/2026.2 เวลา 21:28 UTC และ stable/2026.1 เวลา 22:01 UTC ส่วน stable/2025.1 กับ stable/2025.2 ถูก merge วันที่ 30 ตุลาคม 2026 เวลา 11:49 UTC วันเหล่านี้เป็น วันรวมแพตช์ในซอร์สโค้ด ไม่ใช่หลักฐานว่าแพ็กเกจทุกช่องทางจัดจำหน่ายได้รับรุ่นแก้ไขแล้ว ผู้ดูแลต้องตรวจรุ่นและแพตช์ของช่องทางที่ตนติดตั้งจริง
ช่องโหว่ทำงานอย่างไร
Keystonemiddleware ใช้ตรวจ token และข้อกำหนดสิทธิสำหรับบริการ OpenStack ในกรณี application credential ที่กำหนด access_rules ระบบควรยอมให้ credential เข้าถึงเฉพาะการดำเนินการที่ได้รับอนุญาต ประกาศ OSSA-2026-050 ระบุว่าเมื่อผู้ร้องขอเพิ่ม X-Service-Token ที่กำหนดเอง กลไกบังคับ access rules อาจถูกข้ามได้ การใช้ credential ที่ถูกจำกัดจึงอาจนำไปสู่การยกระดับสิทธิภายในขอบเขตที่บริการยอมรับคำขอ
Header ดังกล่าวเกี่ยวข้องกับการตรวจ token สำหรับการเรียกจากบริการหนึ่งไปยังอีกบริการหนึ่ง แต่ข้อผิดพลาดอยู่ที่ middleware ยอมให้ค่าที่ผู้ร้องขอควบคุมมีผลต่อการตัดสินใจด้านสิทธิ ผู้ดูแลไม่ควรสรุปว่าการมี authentication หน้า API เพียงอย่างเดียวปิดความเสี่ยง เพราะผู้ที่ถือ credential แบบจำกัดอยู่แล้วเป็นกลุ่มที่อาจใช้ช่องทางนี้ การประเมินควรเริ่มจากระบบที่ออก application credential ให้ผู้ใช้หรือระบบอัตโนมัติ พร้อม access rules หรือใช้ token binding
รุ่นที่กระทบและสถานะแพตช์
ประกาศของ OpenStack VMT ระบุช่วงที่กระทบดังนี้: keystonemiddleware ก่อน 10.9.2, ตั้งแต่ 10.10.0 แต่ก่อน 10.12.2, ตั้งแต่ 11.0.0 แต่ก่อน 12.0.1, และ ตั้งแต่ 13.0.0 แต่ก่อน 13.0.2 ขอบเขตนี้ต้องอ่านตามสายรุ่น ไม่ควรนำเลขรุ่นล่าสุดของสายหนึ่งไปเทียบกับอีกสายโดยไม่ดูแพตช์ backport
เวอร์ชันเป้าหมายที่ประกาศระบุคือ 10.9.2, 10.12.2, 12.0.1 และ 13.0.2 ตามสายรุ่นที่ใช้อยู่ อย่างไรก็ดี ณ เวลาตรวจ แพ็กเกจ 13.0.2 ยังไม่ปรากฏบน PyPI ซึ่งแสดง 13.0.1 เป็นรุ่นล่าสุด แม้แพตช์ในซอร์สโค้ดจะ merge แล้ว จึงไม่ควรแจ้งทีมงานว่าการอัปเกรดไป 13.0.2 ทำได้จาก PyPI ในทันที ผู้ใช้แพ็กเกจจาก distribution หรือช่องทาง OpenStack release ต้องตรวจ availability และการ backport ของช่องทางนั้นก่อนดำเนินการ
แนวทางรับมือ
ให้สำรวจบริการ OpenStack ที่ใช้ keystonemiddleware และจดรุ่นของแพ็กเกจจริงในแต่ละสภาพแวดล้อม ตรวจว่ามีการใช้ application credential ที่ตั้ง access rules หรือมีการบังคับ token binding หรือไม่ จากนั้นติดตามแพ็กเกจแก้ไขในสายรุ่นที่ใช้อยู่ หากองค์กรสามารถดูแลแพตช์ซอร์สได้ ให้ประเมินการนำ commit ที่ OpenStack VMT อ้างอิงไปใช้ผ่านกระบวนการทดสอบและเปลี่ยนแปลงของตนเอง โดยต้องคำนึงถึงความเข้ากันได้ของ branch และแพ็กเกจปลายทาง
ระหว่างรอแพ็กเกจที่ตรวจยืนยันแล้ว ควรทบทวน application credential ที่มีสิทธิอ่อนไหว ลดการกระจาย credential และตรวจบันทึกคำขอที่ใช้ X-Service-Token ร่วมกับ credential ที่มี access rules ตามความสามารถของระบบบันทึกที่ติดตั้ง การลบ header โดยพลการจากทุกเส้นทางอาจกระทบการสื่อสารระหว่างบริการ จึงควรประเมินกับสถาปัตยกรรมจริงก่อนใช้เป็นมาตรการชั่วคราว และไม่มีมาตรการดังกล่าวใดแทนการติดตั้งแพตช์ที่เหมาะสม
หลังได้รับแพ็กเกจแก้ไข ให้ตรวจเวอร์ชันที่รันจริงบนทุก node และทดสอบว่า application credential แบบจำกัดไม่สามารถเข้าถึง API ที่อยู่นอก access rules ได้เมื่อคำขอมี X-Service-Token ทีมปฏิบัติการควรบันทึกวันและช่องทางที่แพตช์ถูกนำไปใช้ เพื่อแยกวันเปิดเผย วัน merge โค้ด และวันติดตั้งแพตช์ของระบบตนเองอย่างชัดเจน