สมมติว่าบริษัทของคุณมีทีมพัฒนาภายใน หรือจ้างผู้รับเหมาทำระบบให้ และโค้ดทั้งหมดเก็บไว้ใน GitLab ที่ติดตั้งบนเซิร์ฟเวอร์ของบริษัทเอง เครื่องนี้มักเก็บมากกว่าโค้ด ทั้งค่าตั้ง pipeline รหัสผ่านที่ใช้ deploy และสิทธิ์เชื่อมไปยังระบบ production
ถ้าคนภายนอกรันคำสั่งบนเครื่องนี้ได้โดยไม่ต้องล็อกอิน ความเสียหายจะไม่จบที่ตัว GitLab ข่าวสัปดาห์นี้เกี่ยวกับความเสี่ยงแบบนั้นโดยตรง
เกิดอะไรขึ้น
วันที่ 21 ตุลาคม 2569 GitLab ออกแพตช์พร้อมกัน 7 รุ่น ได้แก่ 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 และ 18.11.13 ใช้ได้ทั้ง Community Edition และ Enterprise Edition และแนะนำให้องค์กรที่ติดตั้งเองอัปเกรดโดยเร็วที่สุด
แพตช์รอบนี้แก้ช่องโหว่ 12 รายการ ตัวที่หนักที่สุดคือ CVE-2026-110264 คะแนน CVSS 10.0 ซึ่งเป็นคะแนนสูงสุดของมาตรฐานนี้ ต้นเหตุอยู่ที่ส่วนแปลง regular expression เมื่อเจอ regex ที่ประดิษฐ์มาเป็นพิเศษ ตัวเลขภายในจะล้นค่า (integer overflow) และภายใต้เงื่อนไขบางอย่าง ผู้ที่ไม่ได้ล็อกอินอาจรันโค้ดใดก็ได้บนเซิร์ฟเวอร์ GitLab
ช่วงรุ่นที่กระทบกว้างมาก คือตั้งแต่รุ่น 7.0 ขึ้นมาจนถึงก่อนรุ่นที่แก้ในแต่ละสาขา GitLab จึงทำแพตช์ย้อนให้สาขาเก่าอย่าง 18.11, 19.0, 19.1 และ 19.2 เพิ่มจากรอบปกติ
ช่องโหว่ระดับสูงอีก 2 รายการที่ควรทราบ
- CVE-2026-15723 คะแนน 8.2 เกี่ยวกับการผูกบัญชีจาก OmniAuth เข้ากับ LDAP โดยอัตโนมัติ
- CVE-2026-112212 คะแนน 7.5 เกี่ยวกับ cache poisoning ที่ endpoint สำหรับค้นหาค่า OAuth และ OIDC
ใครต้องทำอะไร
GitLab ระบุว่า GitLab.com ใช้รุ่นที่แก้แล้ว ลูกค้า GitLab Dedicated ที่อยู่บนรุ่น 19.3.5-internal0 หรือ 19.4.2-internal0 ขึ้นไปก็ไม่ต้องทำอะไร
กลุ่มที่ต้องลงมือคือองค์กรที่ติดตั้ง GitLab เอง (self-managed) ไม่ว่าจะอยู่บนเซิร์ฟเวอร์ในบริษัทหรือบน cloud ที่ทีมดูแลเอง
เรื่องสถานะการโจมตี ประกาศของ GitLab ไม่ได้ระบุว่ามีการโจมตีจริง ส่วน SecurityOnline รายงานเมื่อ 21 ตุลาคมว่ายังไม่มีการยืนยันการโจมตีและยังไม่มีโค้ดสาธิตการโจมตี (PoC) สาธารณะ ข้อนี้ไม่ได้แปลว่ารอได้ แพตช์ที่ออกมาแล้วเปิดให้คนนำไปเทียบหาจุดที่แก้ได้ และ GitLab จะเปิดรายละเอียดของแต่ละช่องโหว่หลังออกแพตช์ 90 วัน ยิ่งเครื่องค้างรุ่นเก่านาน ความเสี่ยงก็ยิ่งสูงขึ้น
