GitLab เตือนช่องโหว่รุนแรงสูงสุด บริษัทที่ตั้งเซิร์ฟเวอร์เองต้องรีบแพตช์

GitLab ให้ช่องโหว่ในระบบประกอบซอฟต์แวร์คะแนนความรุนแรง 10.0 แปลว่าอยู่ระดับสูงสุดตามมาตรวัด CVSS ที่ใช้จัดระดับช่องโหว่ครับ GitLab ประกาศแพตช์เมื่อ 12 ต.ค. 2026 เพื่อแก้ปัญหาที่อาจให้ผู้ยังไม่ล็อกอินรันโค้ดบนเซิร์ฟเวอร์ได้ภายใต้เงื่อนไขบางอย่าง

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

สรุป 30 วินาที: เกิดอะไรขึ้น

ช่องโหว่นี้มีรหัส CVE-2026-97229 โดย CVE คือรหัสกลางที่ใช้ระบุช่องโหว่ให้ทุกฝ่ายคุยถึงเรื่องเดียวกัน BleepingComputer รายงานว่าเกิดจากการคำนวณจำนวนเต็มล้นในส่วนอ่านกฎจับคู่ข้อความของระบบ CI/CD ซึ่งเป็นระบบตรวจและประกอบซอฟต์แวร์อัตโนมัติ

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

ทั้ง Community Edition หรือ CE และ Enterprise Edition หรือ EE อยู่ในขอบเขตประกาศ โดย CERT-EU แนะนำให้เครื่องที่องค์กรดูแลเองอัปเกรดโดยเร็ว เริ่มจากเครื่องที่เปิดให้เข้าถึงผ่านอินเทอร์เน็ตก่อน ชื่อรุ่นต่างกันจึงไม่ได้ทำให้ฝ่ายใดฝ่ายหนึ่งพ้นจากการตรวจสอบ

เลขแพตช์สายกลางมีรายละเอียดที่ต้องระวังครับ BleepingComputer ระบุรุ่น 19.3.4 แปลว่าเป็นเลขที่ปรากฏในรายงานข่าว แต่ เอกสาร GitLab ที่ตรวจรอบนี้ ระบุรุ่น 19.3.5 แปลว่าผู้ดูแลควรอ่านประกาศปัจจุบันก่อนตัดสินว่าการอัปเดตเสร็จแล้ว

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

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

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

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

ทำงานยังไง

Regular expression หรือ regex คือกฎสำหรับตรวจว่าข้อความตรงกับรูปแบบที่กำหนดหรือไม่ ส่วน compiler ในข่าวนี้คือส่วนที่แปลงกฎให้ระบบนำไปประมวลผลได้ BleepingComputer อธิบายว่าส่วนดังกล่าวอ่าน แปลง และประเมินกฎที่อยู่ในค่าตั้งสายงานของโครงการ

Integer overflow แปลว่าการคำนวณจำนวนเต็มเกินขอบเขตที่ระบบรองรับครับ CERT-EU ระบุว่าการตรวจ regex ที่ไม่แข็งแรงพอทำให้เกิดปัญหานี้ และกฎที่สร้างขึ้นเป็นพิเศษอาจนำไปสู่การรันโค้ดบนเซิร์ฟเวอร์ได้ เราจึงควรแยกข้อผิดพลาดในการประมวลผลออกจากเรื่องรหัสผ่านของพนักงาน

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

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

จุดหักมุม: ล็อกอินแน่นหนา ก็ยังต้องแพตช์

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

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

เรื่องเงิน / ผลกระทบ

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

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

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

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

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

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

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

เรื่องเลขรุ่นต่างกันจริง CERT-EU และ BleepingComputer ระบุสาย 19.3 ว่าแก้ที่ 19.3.4 แปลว่ารายงานสองแห่งใช้เลขนี้ แต่ GitLab และ OpenCVE ระบุขอบเขตก่อน 19.3.5 ว่าได้รับผลกระทบ แปลว่าเอกสารที่ตรวจรอบนี้ให้ไปต่อถึงแพตช์ที่ใหม่กว่า

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

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

ยังไม่มีรายงานการโจมตีจริงในแหล่งที่อ่าน ส่วน OpenCVE ระบุว่าช่องโหว่นี้ยังไม่อยู่ในบัญชี KEV ของ CISA ซึ่งเป็นบัญชีช่องโหว่ที่พบการใช้โจมตีแล้ว แต่ส่วนอธิบายความเสี่ยงบนหน้านั้นระบุว่า AI สร้างขึ้น จึงไม่ควรใช้เป็นคำรับรองว่าไม่มีใครโจมตีอยู่ที่อื่น

บริบทจากข่าวเก่าต้องแยกให้ชัด: BleepingComputer รายงานว่าช่องโหว่ GitLab ก่อนหน้า CVE-2026-85706 ถูกเพิ่มเข้า CISA KEV ซึ่ง Showkhun เคยเล่าใน บทความก่อนหน้า แต่เรื่องนั้นไม่ใช่หลักฐานการใช้โจมตีช่องโหว่ใหม่ครั้งนี้

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

แล้วเราควรทำอะไร

คนทั่วไปและเจ้าของกิจการ: ทำตามได้เลย

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

ทีม IT ที่ดูแลเซิร์ฟเวอร์: ทำตามได้เลย

ตรวจเลขรุ่นในพื้นที่ผู้ดูแลระบบหรือ Admin area และจดว่าเครื่องใดเปิดให้เข้าถึงจากอินเทอร์เน็ต ข้อนี้เป็นขั้นตอนตรวจของผู้ดูแลเพื่อจัดคิวแพตช์ โดย CERT-EU ให้เริ่มจากเครื่องที่เปิดสู่อินเทอร์เน็ตก่อน
ยึดแพตช์ล่าสุดตาม เอกสาร GitLab ที่ตรงกับสายรุ่นของตน แทนการใช้เลขจากพาดหัวเก่าอย่างเดียว รายการที่เอกสารระบุในรอบตรวจนี้อยู่ด้านล่างครับ
- 19.4.2 แปลว่าเป็นแพตช์ที่ระบุสำหรับสาย 19.4
- 19.3.5 แปลว่าเป็นแพตช์ที่เอกสารปัจจุบันระบุสำหรับสาย 19.3 แม้ข่าวและ CERT-EU ใช้เลขก่อนหน้า
- 19.2.8 แปลว่าเป็นแพตช์ที่ระบุสำหรับสาย 19.2
วางแผนอัปเกรดตามรูปแบบติดตั้ง โดยคำนึงถึงการปรับฐานข้อมูลที่ GitLab แจ้งไว้ อย่ารับรองเวลาหยุดบริการก่อนตรวจขั้นตอนของระบบตนเอง และตรวจรุ่นที่รันจริงอีกครั้งหลังดำเนินการ
ทบทวนว่าใครส่งหรือแก้ค่าตั้ง CI/CD ได้ พร้อมตรวจบันทึกการทำงานของสายงาน OpenCVE เสนอแนวทางจำกัดสิทธิ์และตรวจบันทึกไว้ในส่วนคำแนะนำที่สร้างด้วย AI ให้ใช้ประกอบการป้องกัน ไม่ใช้แทนแพตช์จากผู้ผลิต
ถ้าเครื่องเปิดสู่อินเทอร์เน็ตและยังไม่ได้แพตช์ ให้พิจารณาหมุนเวียน CI secrets คือเปลี่ยนรหัสหรือข้อมูลลับที่ระบบประกอบงานใช้ หลังประเมินการเข้าถึงและผลต่อระบบที่เกี่ยวข้อง ข้อนี้เป็นข้อเสนอเชิงระมัดระวังของบทความ ไม่ใช่คำยืนยันว่าข้อมูลลับจากช่องโหว่นี้รั่วแล้ว และไม่ใช่คำสั่งที่ประกาศผู้ผลิตระบุไว้

นักพัฒนา: ทำตามได้เลย

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

ผมมองว่า…

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

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

ปิดท้าย: สิ่งที่ต้องจับตา

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

ในที่ทำงานของคุณ มีใครเป็นผู้ยืนยันเลขรุ่น GitLab หลังแพตช์ และแจ้งคนที่ต้องส่งงานผ่านระบบนี้ครับ?