สรุปสั้น

Consul คือ ระบบ service mesh และ service discovery ของบริษัท HashiCorp ส่วน Consul-k8s คือ ตัวติดตั้งและเชื่อม Consul เข้ากับ Kubernetes เมื่อวันที่ 26 ตุลาคม 2569 บริษัท HashiCorp ออกประกาศ HCSEC-2026-50 แก้ช่องโหว่ CVE-2026-110720 ใน Consul-k8s เวอร์ชัน 0.42.0 ถึง 2.0.4 ช่องโหว่อยู่ในกฎที่ผูกตัวตนของ Kubernetes เข้ากับสิทธิ์ใน Consul กฎเหล่านี้ไม่ได้จำกัดว่าต้องเป็น ServiceAccount ใน namespace ที่ติดตั้ง Consul เท่านั้น ผล คือ ตัวตนจาก namespace อื่นสามารถล็อกอินเป็นคอมโพเนนต์ของ Consul และรับสิทธิ์ของคอมโพเนนต์นั้นไปได้

ช่องโหว่นี้ไม่ใช่ช่องที่ใครบนอินเทอร์เน็ตก็โจมตีได้ ผู้โจมตีต้องมีสิทธิ์สร้าง ServiceAccount ใน namespace อื่นของคลัสเตอร์และขอโทเค็นของมันได้ ต้องเข้าถึง Consul API ทางเครือข่ายได้ และระบบต้องเปิด global.acls.manageSystemACLs=true ไว้ HashiCorp ไม่ได้ให้คะแนน CVSS และยังไม่มีรายงานการโจมตีจริง แต่ในคลัสเตอร์ที่หลายทีมแชร์กันแบบ multi-tenant ช่องโหว่นี้ทำลายเส้นแบ่ง namespace ที่หลายองค์กรใช้เป็นขอบเขตความปลอดภัย ผู้ดูแลระบบที่เปิด manageSystemACLs ควรอัปเกรดเป็น Consul-k8s 2.1.0 หรือ 1.8.18

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

เว็บไซต์ Cyber Security News รายงานเมื่อวันที่ 27 ตุลาคม 2569 ว่าบริษัท HashiCorp เปิดเผยช่องโหว่ authorization bypass ใน Consul-k8s ผ่านประกาศความปลอดภัย HCSEC-2026-50 เมื่อวันที่ 26 ตุลาคม 2569 และระบุเวอร์ชัน 2.1.0 กับ 1.8.18 เป็นเวอร์ชันที่แก้แล้ว

ตามประกาศของ HashiCorp ช่วงเวอร์ชันที่กระทบ คือ 0.42.0 ถึง 2.0.4 โดย 1.8.18 เป็นเวอร์ชันแก้สำหรับสาย 1.8 ผู้ค้นพบ คือ นาย Elias Hasas นักวิจัยความปลอดภัยที่ใช้ชื่อ zer0d4y5 บน GitHub

ข้อจำกัดของหลักฐาน คือ พาดหัวของ Cyber Security News เรียกช่องโหว่นี้ว่า “วิกฤต” (critical) แต่ประกาศของ HashiCorp เองไม่ได้ให้ระดับความรุนแรงหรือคะแนน CVSS ประกาศไม่ได้ให้โค้ดสาธิตการโจมตี ไม่มีรายงานการโจมตีจริง และไม่ได้ระบุขั้นตอนทำความสะอาดหลังอัปเกรด HashiCorp ยังระบุว่าการโจมตีสำเร็จไม่จำเป็นต้องได้สิทธิ์ผู้ดูแลระบบเต็ม เพราะสิทธิ์ที่ได้ขึ้นกับคอมโพเนนต์ที่ถูกสวมรอย

รายละเอียดช่องโหว่

สาเหตุ — กฎ ACL binding ที่ Consul-k8s สร้างให้อัตโนมัติไม่ได้ผูกกับ namespace เมื่อเปิดการจัดการ ACL ของระบบอัตโนมัติ (global.acls.manageSystemACLs=true) Consul-k8s จะตั้งค่า Kubernetes auth method และ binding rule ให้คอมโพเนนต์ของ Consul ขอโทเค็นได้เอง กฎเหล่านี้ควรจับคู่ ServiceAccount ของแต่ละคอมโพเนนต์เข้ากับ Consul role ที่ตรงกัน แต่กฎในเวอร์ชันที่มีปัญหาไม่ได้จำกัดอย่างสม่ำเสมอว่า ServiceAccount ต้องอยู่ใน namespace ที่ติดตั้ง Consul

เงื่อนไขการโจมตี — ผู้โจมตีต้องมีจุดตั้งหลักในคลัสเตอร์ก่อน ได้แก่ สิทธิ์ Kubernetes ในการสร้าง ServiceAccount และขอโทเค็นของมันใน namespace อื่น และต้องเข้าถึง Consul API ทางเครือข่ายได้ ระบบที่ปิด manageSystemACLs ไม่ได้รับผลกระทบตามที่ HashiCorp ระบุชัด ดังนั้นการดูแค่เวอร์ชันจึงยังบอกไม่ได้ว่าระบบเสี่ยงหรือไม่

ผลลัพธ์ — ตัวตนจาก namespace อื่นจึงล็อกอินผ่าน Kubernetes auth method ในฐานะคอมโพเนนต์ของ Consul และได้โทเค็น Consul ที่มีสิทธิ์ของคอมโพเนนต์นั้น นี่ คือ การข้ามเส้นแบ่งการเข้าถึงที่ออกแบบไว้ ไม่ใช่แค่การลืมตรวจว่ามีโทเค็นหรือไม่ ขอบเขตความเสียหายขึ้นกับว่าคอมโพเนนต์ที่ถูกสวมรอยมีสิทธิ์อะไรใน Consul เช่น อ่านหรือแก้การตั้งค่า service mesh

เวอร์ชันที่แก้แล้ว — Consul-k8s 2.1.0 และ 1.8.18

ผลกระทบ

กลุ่มที่เสี่ยง คือ องค์กรที่รัน Consul บน Kubernetes ผ่าน Consul-k8s เวอร์ชัน 0.42.0 ถึง 2.0.4 และเปิด manageSystemACLs ซึ่งเป็นการตั้งค่าที่นิยมเพราะช่วยให้ไม่ต้องจัดการโทเค็นเอง ความเสี่ยงสูงสุดอยู่ในคลัสเตอร์ที่หลายทีมหรือหลายลูกค้าแชร์กัน และใช้ namespace เป็นเส้นแบ่งสิทธิ์ ผู้ใช้หรือ workload ที่มีสิทธิ์แค่ใน namespace ของตัวเองอาจยกระดับไปควบคุมส่วนของ Consul ได้

ในทางปฏิบัติช่องโหว่นี้เหมาะกับการใช้เป็นขั้นที่สองของการโจมตี เช่น หลังผู้โจมตีได้ pod หรือบัญชีที่มีสิทธิ์สร้าง ServiceAccount แล้ว จึงยกระดับต่อไปยัง service mesh ซึ่งควบคุมการสื่อสารระหว่างบริการทั้งหมด แม้ยังไม่มีรายงานการโจมตีจริง การที่รายละเอียดกลไกเปิดเผยแล้วทำให้ควรอัปเกรดโดยไม่รอรอบปกติ

คำแนะนำ

  • เช็กการตั้งค่าก่อน — ดูว่า Helm values ของ Consul มี global.acls.manageSystemACLs=true หรือไม่ ถ้าปิดอยู่ ระบบไม่ได้รับผลกระทบจากช่องโหว่นี้
  • อัปเกรด Consul-k8s ทันทีถ้าเปิดค่านี้ — สาย 2.x อัปเกรดเป็น 2.1.0 · สาย 1.8 อัปเกรดเป็น 1.8.18
  • จำกัดสิทธิ์สร้าง ServiceAccount และขอโทเค็น — ตรวจ RBAC ว่าผู้ใช้หรือ workload ใดสร้าง serviceaccounts และ serviceaccounts/token ได้นอก namespace ที่จำเป็น เพราะเป็นเงื่อนไขหลักของการโจมตี
  • จำกัดการเข้าถึง Consul API ด้วย NetworkPolicy — อนุญาตเฉพาะ namespace และ pod ที่ต้องคุยกับ Consul server เพื่อตัดเงื่อนไขข้อที่สอง
  • ตรวจล็อกย้อนหลัง — ค้นหาการล็อกอินผ่าน Kubernetes auth method ของ Consul ที่มาจาก ServiceAccount นอก namespace ของ Consul ถ้าพบ ให้เพิกถอนโทเค็น Consul ที่ออกให้ตัวตนนั้น

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