Bytebase เปิดเผย 2 CVE ข้ามโปรเจกต์: แก้ความเห็นและอ่าน Task Run ที่ไม่มีสิทธิ์

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

ต้องแยกเวลาให้ชัด: ระเบียน CVE ทั้งสองเผยแพร่วันที่ 22 ตุลาคม 2026 แต่ Bytebase รวมโค้ดแก้ไขไว้ก่อนแล้วใน รุ่น 3.16.0 ซึ่งออกวันที่ 12 มีนาคม 2026 ข่าวนี้จึงเป็นการแจ้งรายละเอียดช่องโหว่ที่เพิ่งได้รับเลข CVE ไม่ใช่ประกาศว่าผู้พัฒนาเพิ่งออกแพตช์วันนี้ ผู้ดูแลที่อัปเกรดถึง 3.16.0 หรือใหม่กว่าอยู่แล้วควรตรวจยืนยันรุ่นที่ใช้งานจริง มากกว่าตีความว่าต้องรอแพตช์อีกชุด

สองช่องโหว่กระทบข้อมูลคนละส่วน

CVE-2026-115321 อยู่ในส่วน UpdateIssueComment ซึ่งใช้แก้ไขความเห็นของ issue รายงาน CVE ระบุว่า Bytebase ก่อน 3.16.0 ตรวจสิทธิ์กับ issue ที่ผู้ใช้ระบุในคำขอ แต่ค้นหาความเห็นจาก UID โดยไม่ได้ผูกกับ issue นั้น ผู้ใช้ที่มีบทบาทในโปรเจกต์หนึ่ง แม้เป็น Project Viewer จึงอาจใช้ issue ในโปรเจกต์ตนเองประกอบกับ UID ของความเห็นจากอีกโปรเจกต์ แล้วเขียนทับความเห็นที่ตนไม่มีสิทธิ์แก้ไข ผลกระทบหลักคือความถูกต้องของบทสนทนาและหลักฐานการอนุมัติงาน ไม่ควรสรุปจากข้อมูลนี้ว่าเป็นช่องทางรันคำสั่งบนเซิร์ฟเวอร์หรือเข้าถึงฐานข้อมูลทั้งหมด

CVE-2026-115322 อยู่ใน GetTaskRunLog, GetTaskRunSession และ PreviewTaskRunRollback รายงานระบุว่าตัวจัดการรับข้อมูลโปรเจกต์หรือแผนจากเส้นทางคำขอ แต่ก่อนแก้ไขกลับดึง task หรือ task run ด้วย UID โดยไม่ตรวจความเป็นเจ้าของให้สอดคล้องกับโปรเจกต์ที่ผ่านการตรวจสิทธิ์ ผู้ใช้ที่มีสิทธิ์ในโปรเจกต์หนึ่งจึงอาจอ่านบันทึกการรัน รายละเอียด session ของฐานข้อมูล และ SQL สำหรับ rollback ของงานในอีกโปรเจกต์ได้ หากทราบ UID ที่เกี่ยวข้อง ผลกระทบหลักของรายการนี้คือการเปิดเผยข้อมูลข้ามขอบเขตโปรเจกต์ โดยเฉพาะในระบบที่แยกทีมและสิทธิ์เข้าถึงฐานข้อมูลกันอย่างเคร่งครัด

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

ผู้พัฒนาแก้ด้วยการผูก UID เข้ากับทรัพยากรแม่

ใน pull request สำหรับความเห็น ผู้พัฒนาอธิบายว่าเปลี่ยนการค้นหาความเห็นให้กำหนด IssueUID จาก issue ที่ผ่านการตรวจสิทธิ์แล้วด้วย ทำให้ UID ของความเห็นจาก issue อื่นไม่ตรงเงื่อนไข แม้ผู้เรียกจะระบุเลขความเห็นที่มีอยู่จริงก็ตาม ส่วน pull request สำหรับ task run เพิ่มการตรวจความสัมพันธ์ระหว่าง plan กับ project และจำกัดการค้นหา task/task run ให้อยู่ใน plan ที่ยืนยันแล้ว แนวแก้ทั้งสองส่วนสะท้อนปัญหาแบบ IDOR: การรู้รหัสทรัพยากรไม่ควรแทนสิทธิ์ในการเข้าถึงทรัพยากรนั้น

หน้า issue ต้นทางของโครงการ เชื่อมปัญหาสองกลุ่มเข้าด้วยกัน และ pull request ทั้งสองถูกรวมเข้าก่อนการออก Bytebase 3.16.0 ผู้ดูแลจึงควรยึดรุ่นแก้ไขที่ระบุในระเบียน CVE และตรวจ image tag หรือ binary ที่รันจริง ไม่ควรดูเพียงไฟล์กำหนดค่าที่อาจต่างจาก deployment ใน production

วิธีตรวจและรับมือในระบบที่ใช้งานอยู่

เริ่มจากทำรายการทุก instance ของ Bytebase ทั้ง production, staging และระบบที่แยกไว้ให้แต่ละทีม ตรวจเวอร์ชันที่แสดงในแอปและเวอร์ชันของ container image หรือแพ็กเกจที่นำขึ้นใช้งาน หากต่ำกว่า 3.16.0 ให้วางแผนอัปเกรดเป็น 3.16.0 หรือรุ่นใหม่กว่าที่โครงการรองรับ โดยอ่าน release note ของ 3.16.0 ก่อน เพราะรุ่นนี้มีการเปลี่ยน API และ resource ID บางส่วนที่อาจกระทบ integration และ Terraform provider การอัปเกรดควรผ่านสภาพแวดล้อมทดสอบตามขั้นตอนของทีม

ระหว่างรออัปเกรด ให้ทบทวนจำนวนบัญชีที่มีสิทธิ์เข้าแต่ละโปรเจกต์ โดยเฉพาะบัญชีที่ไม่ได้ใช้งานแล้ว และจำกัดการเข้าถึง Bytebase ตามนโยบายองค์กร วิธีนี้ลดพื้นที่เสี่ยงของผู้ใช้ที่ผ่านการยืนยันตัวตน แต่ไม่ใช่การแก้ช่องโหว่แทนการอัปเกรด สำหรับระบบที่แยกข้อมูลสำคัญระหว่างทีม ควรทบทวนบันทึกการแก้ไขความเห็นและการเรียกดู task run หากมี log ที่เก็บข้อมูลเพียงพอ โดยพิจารณาคำขอที่อ้างอิง project หรือ plan ไม่สัมพันธ์กับ UID ของทรัพยากร การไม่พบบันทึกผิดปกติไม่ใช่หลักฐานยืนยันว่าไม่เคยมีการเข้าถึง

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

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

แหล่งต้นทาง: CVE-2026-115321, CVE-2026-115322, Bytebase issue #19369, PR #19552, PR #19554 และ Bytebase 3.16.0 release