ช่องโหว่ GitLab AI Gateway ได้ 9.9—ผู้ใช้คลาวด์ไม่ต้องแก้เหมือนกัน

วันที่ 5 ตุลาคม 2569 ThaiCERT เผยแพร่คำเตือนเรื่องช่องโหว่ CVE-2026-90970 ใน GitLab AI Gateway ซึ่ง GitLab เปิดเผยเมื่อ 2 ตุลาคม และให้คะแนนความรุนแรง CVSS 9.9 ผู้ที่ต้องจัดการแพตช์เองคือองค์กรที่ติดตั้ง AI Gateway ในระบบของตน ส่วนเงื่อนไขการโจมตีที่เปิดเผยระบุถึงผู้ใช้ที่ยืนยันตัวตนแล้วและเข้าถึง Duo Agent Platform ได้

ประกาศแพตช์ของ GitLab ระบุว่ารุ่น AI Gateway ที่แก้ไขแล้วคือ 19.2.4, 19.3.2 และ 19.4.1 ขณะที่เกตเวย์ซึ่ง GitLab จัดการได้รับการแก้ไขแล้ว ลูกค้า GitLab.com, GitLab Dedicated และผู้ใช้ GitLab Self-Managed ที่เชื่อมต่อกับเกตเวย์ของ GitLab จึงไม่ต้องอัปเดตเกตเวย์สำหรับช่องโหว่นี้ ความแตกต่างอยู่ที่ผู้ดำเนินการเกตเวย์ซึ่งรับคำขอจริง ไม่ใช่เพียงรูปแบบการติดตั้ง GitLab instance

ใครต้องอัปเดต AI Gateway

คำว่า GitLab Self-Managed หมายถึงองค์กรดูแล GitLab instance เอง แต่ไม่ได้บอกว่าองค์กรดูแล AI Gateway ด้วย ระบบลักษณะนี้อาจส่งคำขอไปยังเกตเวย์ที่ GitLab ให้บริการ หรือใช้เกตเวย์ที่ติดตั้งไว้ในโครงสร้างพื้นฐานขององค์กรก็ได้ การดูเฉพาะชื่อแพ็กเกจหรือเวอร์ชันของ GitLab หลักจึงตอบคำถามเรื่องแพตช์เกตเวย์ไม่ได้

หาก Duo Agent Platform ใช้เกตเวย์ที่ GitLab จัดการ การแก้ไขส่วนประกอบดังกล่าวอยู่ฝั่งผู้ให้บริการตามสถานะที่ GitLab แจ้งไว้ ผู้ดูแลไม่จำเป็นต้องนำแพตช์ AI Gateway ไปติดตั้งบนเครื่องของตนเพื่อแก้ช่องโหว่นี้ แต่หากคำขอวิ่งผ่านเกตเวย์ที่องค์กรติดตั้งเอง ความรับผิดชอบเปลี่ยนทันที: ต้องระบุรุ่นที่กำลังทำงานและอัปเดตเกตเวย์นั้น

บางองค์กรใช้ทั้งเกตเวย์ของตนและบริการที่ GitLab จัดการ โดยเลือกเส้นทางตามฟีเจอร์หรือโมเดลที่ใช้งาน กรณีนี้สถานะว่า GitLab แพตช์บริการของตนแล้วครอบคลุมเฉพาะคำขอที่ผ่านบริการนั้น เกตเวย์ที่องค์กรเดินระบบเองยังต้องตรวจแยกต่างหาก แม้ทั้งสองเส้นทางจะเชื่อมกับ GitLab instance เดียวกัน

จุดเริ่มที่แม่นยำจึงเป็นการระบุปลายทางของ Duo Agent Platform ในการตั้งค่าที่ใช้งานจริง จากนั้นจับคู่ปลายทางนั้นกับผู้รับผิดชอบระบบ ถ้าเป็นบริการของ GitLab ไม่ต้องแก้เกตเวย์เอง ถ้าเป็นเกตเวย์ขององค์กร ให้ใช้เลขเวอร์ชันของเกตเวย์ที่รับคำขออยู่เป็นตัวตัดสิน ไม่ใช้เลขเวอร์ชันบนหน้า GitLab หลักแทน

ช่วงเวอร์ชันที่ได้รับผลกระทบ

ขอบเขตที่ประกาศเริ่มจาก AI Gateway 18.1.6 และแยกปลายช่วงตามสายรุ่น รุ่นตั้งแต่ 18.1.6 แต่ก่อน 19.2.4 อยู่ในข่าย รวมถึงสายที่อยู่ระหว่างนั้น ส่วนสาย 19.3 ได้รับผลกระทบก่อน 19.3.2 และสาย 19.4 ก่อน 19.4.1 ตัวเลขทั้งหมดนี้เป็นของ AI Gateway ไม่ใช่การยืนยันสถานะแพตช์ของ GitLab instance

• ถ้าเกตเวย์อยู่ตั้งแต่ 18.1.6 และยังต่ำกว่า 19.2.4 ให้วางแผนอัปเดตไปยังรุ่นที่แก้ไขแล้ว โดยตรวจความเข้ากันได้กับ GitLab instance ที่ใช้อยู่ด้วย
• ถ้าอยู่ในสาย 19.3 และยังต่ำกว่า 19.3.2 ให้ใช้รุ่นแก้ไขของสาย 19.3
• ถ้าอยู่ในสาย 19.4 และยังต่ำกว่า 19.4.1 ให้ใช้รุ่นแก้ไขของสาย 19.4

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

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

เหตุใดคะแนนสูงจึงไม่ได้หมายถึงการเจาะแบบไม่ต้องเข้าสู่ระบบ

ช่องโหว่อยู่ที่การจัดการ prompt template ของ custom flow ผู้โจมตีตามเงื่อนไขที่เปิดเผยต้องเป็นผู้ใช้ที่ยืนยันตัวตนแล้วและเข้าถึง Duo Agent Platform ได้ จึงจะส่งการกำหนดค่า Flow ที่สร้างขึ้นเป็นพิเศษเพื่อหลุดจาก prompt-template sandbox ผลที่อาจเกิดขึ้นคือการรันคำสั่งบนโฮสต์ซึ่งให้บริการ AI Gateway ไม่ใช่เพียงการเปลี่ยนข้อความตอบกลับของโมเดล

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

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

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

อัปเดตให้ถึงเกตเวย์ที่กำลังรับคำขอ

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

1. ระบุว่า Duo Agent Platform ส่งคำขอผ่านเกตเวย์ของ GitLab หรือเกตเวย์ที่องค์กรติดตั้งเอง รวมถึงกรณีที่มีหลายเส้นทาง
2. บันทึกรุ่นของ AI Gateway ที่กำลังทำงานในแต่ละเส้นทาง แล้วเทียบกับช่วงได้รับผลกระทบและรุ่นแก้ไข
3. อัปเดตเกตเวย์ที่อยู่ในช่วงได้รับผลกระทบ พร้อมตรวจว่ากระบวนการที่เริ่มใหม่ใช้รุ่นแก้ไขจริง
4. ตรวจการเชื่อมต่อระหว่าง GitLab, Duo Agent Platform และเกตเวย์หลังเปลี่ยนรุ่น ก่อนปิดงานอัปเดต

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

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

คีย์และรหัสผ่านหลังลงแพตช์

การเปลี่ยนซอฟต์แวร์ปิดช่องโหว่สำหรับคำขอใหม่ แต่ไม่ย้อนคืนความลับที่อาจถูกเข้าถึงก่อนอัปเดต คำเตือน SK-CERT วันที่ 5 ตุลาคม แนะนำให้อัปเดตระบบที่ได้รับผลกระทบทันที และระบุว่าหลังแก้ช่องโหว่ซึ่งอาจเปิดทางให้เข้าถึงข้อมูลอ่อนไหวหรือรันโค้ด ควรเปลี่ยนรหัสผ่านและคีย์บนระบบที่เกี่ยวข้อง รวมถึงระบบอื่นที่ใช้ข้อมูลลับชุดเดียวกัน คำแนะนำนี้เป็นมาตรการลดความเสี่ยง ไม่ใช่รายงานว่าคีย์ของทุกองค์กรรั่วไหลแล้ว

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

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

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

อ่านเพิ่มเติม:

• Prompt caching ลดค่า LLM ได้ แต่ต้นพรอมป์ที่เปลี่ยนอาจทำให้พลาดแคช