สรุปสั้น
GitLab ปล่อยอัปเดตความปลอดภัยเพื่อแก้ช่องโหว่ระดับวิกฤตที่กระทบทั้งรุ่น Community Edition (CE) และ Enterprise Edition (EE) ซึ่งภายใต้เงื่อนไขบางอย่างเปิดทางให้ผู้โจมตีที่ไม่ผ่านการยืนยันตัวตนแก้ไขหรือลบโปรเจกต์สาธารณะและข้อมูลผู้ใช้ได้จากระยะไกล ช่องโหว่ตัวนี้ถูกติดตามในหมายเลข CVE-2026-19478 และ GitLab จัดระดับเป็นวิกฤตพร้อมให้คะแนน CVSS 9.4 คำอธิบายของบริษัทระบุเพียงว่าเป็นปัญหาที่เกิดผ่าน GraphQL directive โดยไม่บอกว่า directive ตัวใดและเงื่อนไขที่จำเป็นต่อการโจมตีคืออะไร
แพตช์ชุดนี้ออกเมื่อวันที่ 17 สิงหาคม 2569 ซึ่งอยู่นอกตารางปกติของบริษัทที่ปล่อยอัปเดตเดือนละสองครั้งในวันพุธที่สองและที่สี่ และตามมาห้าวันหลังแพตช์ตามรอบที่ไม่มีรายการระดับวิกฤตเลย เวอร์ชันที่แก้แล้วคือ 19.2.4, 19.1.6, 19.0.8 และ 18.11.11 โดยมีเพียงการติดตั้งแบบ self-managed ที่ต้องลงมือ เพราะ GitLab.com และ GitLab Dedicated รันเวอร์ชันที่แพตช์แล้ว จุดที่ต้องสังเกตคือการแก้ไขไม่ครอบคลุมสาขา 18.2 ถึง 18.10 ซึ่งอยู่ในช่วงที่ได้รับผลกระทบ
แพตช์เดียวกันยังแก้ปัญหาอีกตัวคือ CVE-2026-19650 ที่ GitLab จัดระดับสูงด้วยคะแนน CVSS 7.1 เป็นช่องโหว่ cross-site request forgery (CSRF) ในตัวจัดการคำสั่งแบบ multiplex ของ GraphQL ซึ่งต่างจากตัววิกฤตเพราะต้องอาศัยการกระทำของผู้ใช้ ส่วนคำแถลงของ GitLab ระบุว่ายังไม่พบการโจมตีจริงกับช่องโหว่ทั้งสองตัว และจนถึงวันที่ 18 สิงหาคม 2569 ยังไม่มีโค้ดโจมตีสาธารณะปรากฏบน GitHub
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 18 สิงหาคม 2569 ว่า GitLab ได้ปล่อยอัปเดตความปลอดภัยเพื่อจัดการช่องโหว่ระดับวิกฤตที่กระทบซอฟต์แวร์รุ่น Community Edition และ Enterprise Edition ซึ่งภายใต้เงื่อนไขบางอย่างอาจเปิดทางให้ผู้โจมตีที่ไม่ผ่านการยืนยันตัวตนแก้ไขหรือลบโปรเจกต์สาธารณะและข้อมูลผู้ใช้จากระยะไกลได้
ช่องโหว่ที่ถูกติดตามในหมายเลข CVE-2026-19478 ได้รับการจัดระดับเป็นวิกฤตโดย GitLab เอง พร้อมคะแนน CVSS 9.4 คำอธิบายของบริษัทระบุว่า “GitLab ได้แก้ไขปัญหาที่ภายใต้เงื่อนไขบางอย่างอาจเปิดทางให้ผู้ใช้ที่ไม่ผ่านการยืนยันตัวตนแก้ไขหรือลบโปรเจกต์สาธารณะและข้อมูลผู้ใช้จากระยะไกลผ่าน GraphQL directive” ขณะที่เวกเตอร์ CVSS ที่เผยแพร่ออกมาชี้ว่าช่องโหว่นี้ใช้โจมตีผ่านเครือข่ายได้โดยผู้โจมตีไม่ต้องถือข้อมูลรับรองใด ๆ และไม่ต้องอาศัยการกระทำจากฝั่งเหยื่อ
การปล่อยแพตช์ครั้งนี้เกิดขึ้นนอกตารางปกติ เพราะ GitLab ปล่อยอัปเดตตามรอบเดือนละสองครั้งในวันพุธที่สองและวันพุธที่สี่ของเดือน และแพตช์ระดับวิกฤตชุดนี้มาหลังแพตช์ตามรอบก่อนหน้าเพียงห้าวัน ซึ่งรอบนั้นไม่มีรายการที่ถูกจัดระดับวิกฤตเลย
เวอร์ชันที่แก้ไขแล้วคือ GitLab 19.2.4, 19.1.6, 19.0.8 และ 18.11.11 ส่วนเวอร์ชันที่ได้รับผลกระทบคือทุกเวอร์ชันตั้งแต่ 18.2 จนถึงก่อน 18.11.11, 19.0 จนถึงก่อน 19.0.8, 19.1 จนถึงก่อน 19.1.6 และ 19.2 จนถึงก่อน 19.2.4 โดย GitLab ระบุว่า “GitLab.com และ GitLab Dedicated รันเวอร์ชันที่แพตช์แล้วอยู่ ลูกค้าของ GitLab.com และ GitLab Dedicated ไม่จำเป็นต้องดำเนินการใด” เท่ากับภาระตกอยู่กับผู้ที่ติดตั้งและดูแลเซิร์ฟเวอร์เองทั้งหมด และการแก้ไขนี้ไม่ครอบคลุมสาขา 18.2 ถึง 18.10 ซึ่งอยู่ในช่วงที่ได้รับผลกระทบ
ปัญหาตัวที่สองที่แก้ในรุ่นเดียวกันคือ CVE-2026-19650 ซึ่ง GitLab จัดระดับสูงพร้อมคะแนน CVSS 7.1 เป็นช่องโหว่ CSRF ในตัวจัดการคำสั่งแบบ multiplex ของ GraphQL โดยบริษัทระบุว่า “GitLab ได้แก้ไขปัญหาที่ภายใต้เงื่อนไขบางอย่างอาจเปิดทางให้ผู้ใช้ที่ไม่ผ่านการยืนยันตัวตนสั่ง mutation ผ่านคำขอแบบ GET ได้ เนื่องจากการตรวจสอบคำขอที่ไม่เหมาะสมในการจัดการคำสั่งแบบ multiplex ของ GraphQL” ต่างจากตัววิกฤตที่ไม่ต้องอาศัยเหยื่อ ตัวนี้ต้องมีการกระทำของผู้ใช้จึงจะทำงานได้ นอกจากนี้ GitLab ยังระบุว่าอัปเดตชุดนี้ไม่มี migration ใหม่ และไม่คาดว่าจะต้องหยุดให้บริการในระบบแบบหลายโหนด
การเปิดเผยครั้งนี้เกิดขึ้นหลังรายงานเมื่อเดือนกรกฎาคม 2569 ที่นักวิจัยเผยแพร่โค้ดโจมตีที่ใช้งานได้จริงกับช่องโหว่ GitLab อีกตัวซึ่งกระทบเซิร์ฟเวอร์แบบ self-managed (เราเคยรายงานไว้ใน นักวิจัยปล่อย PoC เจาะ GitLab รันคำสั่งในสิทธิ์ git — แพตช์เงียบไม่ระบุเป็นช่องโหว่ความปลอดภัย ) ส่วนคำประกาศฉบับนี้ไม่ได้เปิดเผยว่ามีการโจมตีจริงกับช่องโหว่ทั้งสองตัว และจนถึงวันที่ 18 สิงหาคม 2569 ยังไม่มีโค้ดโจมตีสาธารณะปรากฏบน GitHub ทั้งนี้ GitLab ไม่ได้ตอบคำขอความเห็นในทันที
รายละเอียดช่องโหว่
ข้อมูลเชิงเทคนิคของ CVE-2026-19478 ที่เปิดเผยออกมามีน้อยมาก GitLab ไม่ได้ระบุว่า GraphQL directive ตัวใดเป็นต้นเหตุ และไม่ได้อธิบายว่า “เงื่อนไขบางอย่าง” ที่จำเป็นต่อการโจมตีคืออะไร สิ่งที่พอสรุปได้จากคำอธิบายและเวกเตอร์ CVSS คือการโจมตีทำได้ผ่านเครือข่าย ไม่ต้องมีบัญชีหรือโทเคน และไม่ต้องหลอกให้ผู้ใช้คลิกอะไร ผลลัพธ์อยู่ในระดับแก้ไขหรือลบข้อมูลได้ ซึ่งอธิบายว่าทำไมคะแนนถึงสูงถึง 9.4 แม้จะไม่ใช่การรันโค้ดระยะไกล เพราะการลบโปรเจกต์คือความเสียหายที่กู้คืนได้ยากกว่าการอ่านข้อมูลในหลายกรณี
ในทางกลไก directive ของ GraphQL คือคำสั่งประกอบที่แนบไปกับคิวรีเพื่อสั่งให้เซิร์ฟเวอร์เปลี่ยนพฤติกรรมการประมวลผล เช่น ให้ข้ามหรือรวมฟิลด์บางฟิลด์ตามเงื่อนไข ปัญหาที่มักเกิดกับกลไกลักษณะนี้คือเส้นทางการประมวลผลผ่าน directive อาจไม่ถูกครอบด้วยการตรวจสิทธิ์ชุดเดียวกับเส้นทางปกติ ทำให้คำขอที่ควรถูกปฏิเสธเดินผ่านไปได้ แต่ต้องย้ำว่านี่เป็นการอธิบายลักษณะทั่วไปของกลไก ไม่ใช่คำอธิบายที่ GitLab ยืนยันสำหรับช่องโหว่ตัวนี้
ส่วน CVE-2026-19650 อธิบายชัดกว่าเล็กน้อย ปัญหาอยู่ที่การจัดการคำสั่งแบบ multiplex ของ GraphQL ซึ่งเป็นความสามารถที่ยอมให้ส่งหลายคิวรีรวมในคำขอเดียว การตรวจสอบคำขอที่ไม่เหมาะสมทำให้ผู้โจมตีสามารถทำให้ mutation ซึ่งเป็นการเขียนข้อมูล ถูกสั่งผ่านคำขอแบบ GET ได้ ปกติการเขียนข้อมูลควรผูกกับเมธอด POST ที่มีการตรวจโทเคนกัน CSRF การเปิดช่องให้เขียนผ่าน GET จึงเท่ากับเปิดทางให้ฝังคำสั่งไว้ในลิงก์หรือทรัพยากรที่โหลดอัตโนมัติ แล้วอาศัยเซสชันของเหยื่อที่ล็อกอินอยู่ทำงานแทน
GitLab ระบุว่าจะเปิดเผยประเด็นเชิงเทคนิคของแต่ละช่องโหว่บนระบบติดตามปัญหาของตัวเอง 90 วันหลังรุ่นที่แก้ไขออก ขณะที่แพตช์ของวันที่ 10 มิถุนายน 2569 เคยกำหนดกรอบนี้ไว้ที่ 30 วัน เมื่อคิดจากวันปล่อยแพตช์ครั้งนี้ รายละเอียดของทั้งสองช่องโหว่จะปรากฏราวกลางเดือนพฤศจิกายน 2569 ช่วงเวลาที่หายไปนี้คือช่วงที่ผู้ดูแลระบบต้องตัดสินใจโดยไม่มีรายละเอียด และเป็นเหตุผลที่การอัปเดตทันทีสำคัญกว่าการรอดูว่าช่องโหว่ทำงานอย่างไร
ผลกระทบ
ผู้ที่ได้รับผลกระทบจริงคือองค์กรที่รัน GitLab แบบ self-managed ซึ่งโดยธรรมชาติคือองค์กรที่เลือกเก็บซอร์สโค้ดและไปป์ไลน์ CI/CD ไว้ในโครงสร้างพื้นฐานของตัวเอง ความเสียหายที่ต้องกลัวไม่ใช่แค่ข้อมูลรั่ว แต่คือการทำลาย เพราะช่องโหว่นี้อยู่ในระดับแก้ไขหรือลบโปรเจกต์สาธารณะและข้อมูลผู้ใช้ได้ องค์กรที่ไม่มีสำเนาสำรองของรีโปนอกตัวเซิร์ฟเวอร์ GitLab หรือมีเพียงมิเรอร์ที่ซิงก์ตามต้นทางโดยอัตโนมัติ อาจสูญเสียประวัติการพัฒนา issue และ merge request ไปพร้อมกัน และการซิงก์อัตโนมัติอาจกลายเป็นตัวกระจายการลบไปยังสำเนาด้วย
กลุ่มที่อยู่ในสถานะลำบากที่สุดคือผู้ที่ยังใช้สาขา 18.2 ถึง 18.10 เพราะอยู่ในช่วงเวอร์ชันที่ได้รับผลกระทบแต่ไม่มีแพตช์ให้ ทางออกจึงไม่ใช่การแพตช์ย่อยแต่เป็นการยกระดับเวอร์ชันหลัก ซึ่งเป็นงานที่ต้องวางแผนและทดสอบ ไม่สามารถทำในชั่วโมงเดียว องค์กรกลุ่มนี้ควรถือว่าเซิร์ฟเวอร์ของตัวเองมีความเสี่ยงอยู่ตลอดจนกว่าจะอัปเกรดเสร็จ และจำกัดการเข้าถึงจากอินเทอร์เน็ตในระหว่างนั้น
ในด้านความเร่งด่วน สัญญาณที่ควรอ่านคือจังหวะการปล่อยแพตช์เอง การที่ GitLab ออกแพตช์นอกรอบเพียงห้าวันหลังรอบปกติ เป็นการบอกโดยพฤติกรรมว่าปัญหานี้รอถึงรอบถัดไปไม่ได้ ขณะเดียวกันข้อมูลที่ยังขาดก็มีมาก ทั้งชื่อ directive เงื่อนไขการโจมตี และผู้รายงานช่องโหว่ คำประกาศไม่ได้ระบุการโจมตีจริง ยังไม่มี PoC สาธารณะ และรายละเอียดทางเทคนิคจะถูกกลั้นไว้อีกราวสามเดือน สถานะปัจจุบันจึงเป็น “ยังไม่มีสัญญาณการโจมตี” ไม่ใช่ “ยืนยันว่าปลอดภัย” และประวัติของ GitLab ที่เคยมี PoC สาธารณะออกมาหลังแพตช์ในเดือนกรกฎาคมก็เป็นเครื่องเตือนว่าช่วงเงียบนี้อาจสั้นกว่าที่คิด
คำแนะนำ
- อัปเกรด GitLab แบบ self-managed เป็นเวอร์ชัน 19.2.4, 19.1.6, 19.0.8 หรือ 18.11.11 ตามสาขาที่ใช้อยู่โดยเร็วที่สุด GitLab ระบุว่าอัปเดตนี้ไม่มี migration ใหม่และไม่คาดว่าจะต้องหยุดให้บริการในระบบหลายโหนด
- ถ้ายังใช้สาขา 18.2 ถึง 18.10 ให้ถือว่าไม่มีแพตช์รองรับ และวางแผนยกระดับไปยังสาขาที่ได้รับการแก้ไขทันที ระหว่างนั้นควรจำกัดการเข้าถึงอินสแตนซ์จากอินเทอร์เน็ตเปิด
- ตรวจสอบว่ามีสำเนาสำรองของรีโปและข้อมูลประกอบที่แยกจากเซิร์ฟเวอร์ GitLab จริง และทดสอบการกู้คืนอย่างน้อยหนึ่งโปรเจกต์ เพราะผลกระทบของช่องโหว่นี้อยู่ในระดับลบข้อมูล
- ระวังการพึ่งมิเรอร์ที่ซิงก์อัตโนมัติจากต้นทางเป็นสำเนาสำรอง เพราะการลบที่ต้นทางอาจถูกซิงก์ตามไปด้วย ให้มีสำเนาแบบ snapshot ที่ไม่เปลี่ยนตามต้นทางควบคู่ไป
- ตรวจล็อกคำขอไปยัง endpoint ของ GraphQL โดยเฉพาะคำขอแบบ GET ที่มีพารามิเตอร์คิวรีขนาดใหญ่หรือมีคำว่า mutation และคำขอที่มาจากผู้ใช้ที่ไม่ได้ล็อกอิน เพื่อหาร่องรอยการทดลองโจมตี
- ทบทวนว่าอินสแตนซ์จำเป็นต้องเปิดโปรเจกต์เป็นสาธารณะและเปิด endpoint GraphQL ให้ผู้ที่ไม่ล็อกอินเข้าถึงหรือไม่ การลดพื้นผิวส่วนนี้ช่วยจำกัดผลของช่องโหว่ประเภทที่ยังไม่รู้รายละเอียด