GitLab ออกแพตช์ฉุกเฉิน CVSS 10 อีกรอบ: อัปเป็น 19.5.1, 19.4.3, 19.3.6 ด่วน

อัปเดต 27 ต.ค. 2026: ยังไม่มีแพตช์ใหม่หลังรอบ 21 ต.ค. แต่ผมแก้สามจุด หน้าเช็กรุ่นตามเอกสาร GitLab คือ Help > Help ไม่ใช่หน้า Admin, รุ่น backport (18.11.13–19.2.9) ได้แค่การแก้ตัว CVSS 10 ส่วนช่องโหว่ high อีกสองตัวแก้เฉพาะ 19.3.6 / 19.4.3 / 19.5.1 และเพิ่มจุดตรวจ log จากกฎตรวจจับของ GitLab ดูวิธีเช็กและแก้ทีละขั้นใน คู่มือเช็กและแก้แพตช์สายเดฟ

GitLab ออก Critical Patch Release เมื่อ 21 ตุลาคม 2026 แก้ช่องโหว่ CVE-2026-110264 คะแนน CVSS 10.0 ซึ่งเป็นระดับสูงสุด ช่องโหว่นี้อาจทำให้คนที่ ยังไม่ได้ล็อกอิน สั่งรันโค้ดบนเซิร์ฟเวอร์ GitLab ได้ (GitLab) ถ้าบริษัทคุณตั้ง GitLab ไว้ใช้เอง (self-managed) ให้อัปเป็น 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 หรือ 18.11.13 ตามสายที่ใช้อยู่ครับ

สรุป 30 วินาที

• ช่องโหว่ integer overflow ในตัวคอมไพล์ regular expression ทำให้คนไม่ล็อกอินรันโค้ดบนเซิร์ฟเวอร์ได้ภายใต้เงื่อนไขบางอย่าง (GitLab)
• รุ่นที่โดนกว้างมาก คือ ทุกรุ่นตั้งแต่ 7.0 จนถึงก่อนรุ่นที่แก้แล้วในแต่ละสาย (CERT-EU)
• GitLab.com แพตช์แล้ว คนที่ต้องลงมือคือคนที่ตั้งเซิร์ฟเวอร์เอง (GitLab)
• ใครเพิ่งแพตช์ช่องโหว่ regex ตัวก่อน (CVE-2026-97229) เมื่อ 12 ต.ค. ต้องอัปอีกรอบ เพราะเป็นคนละช่องโหว่ (TechTarget)

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

GitLab คือที่เก็บซอร์สโค้ดและระบบ CI/CD ของหลายบริษัท ทั้งสตาร์ทอัพ หน่วยงาน และโรงงานซอฟต์แวร์ในไทยที่ไม่อยากเอาโค้ดขึ้นคลาวด์สาธารณะ เครื่อง GitLab ที่ตั้งเองมักเก็บของสำคัญทั้งซอร์สโค้ด รหัสลับใน pipeline โทเคน และสิทธิ์เชื่อมไปเซิร์ฟเวอร์จริง (TechTarget) ถ้าคนร้ายเข้าเครื่องนี้ได้ ความเสียหายไม่ได้หยุดแค่ที่ GitLab แต่ลามไปถึงแอปที่ build ออกจากเครื่องนี้ด้วย

ถ้าคุณใช้ GitLab.com แบบคลาวด์ ไม่ต้องทำอะไรเพิ่ม แต่ถ้าทีมไอทีเคยติดตั้ง GitLab ไว้ในห้องเซิร์ฟเวอร์หรือบน VPS เรื่องนี้ต้องถามวันนี้ครับ

รุ่นที่ต้องอัป

สาย GitLab CE/EE	รุ่นที่แก้แล้ว
19.5	19.5.1
19.4	19.4.3
19.3	19.3.6
19.2	19.2.9
19.1	19.1.9
19.0	19.0.10
18.11 และเก่ากว่า (ตั้งแต่ 7.0)	18.11.13

ข้อมูลจากประกาศของ GitLab และ CERT-EU (GitLab, CERT-EU) GitLab บอกว่าคราวนี้ backport การแก้ไขย้อนไปถึงสาย 18.11, 19.0, 19.1 และ 19.2 ด้วย (GitLab) ส่วนประโยคที่ว่าปกติ GitLab แทบไม่แพตช์สายเก่าขนาดนี้ เป็นความเห็นของนักวิเคราะห์ที่ TechTarget อ้างถึง ไม่ใช่คำของ GitLab เอง (TechTarget)

อีกเรื่องที่ควรรู้คือ ลูกค้า GitLab Dedicated ที่รัน 19.3.5-internal0 และ 19.4.2-internal0 ขึ้นไปได้รับการแก้ไขแล้ว ไม่ต้องทำอะไรเพิ่ม (GitLab) ส่วนคนที่ใช้สายที่ไม่อยู่ในตาราง เช่น 18.10 หรือเก่ากว่านั้น ทางเดียวที่ได้แพตช์คือขยับขึ้นไปที่ 18.11.13 หรือสายที่ใหม่กว่า เพราะ CERT-EU ระบุว่าทุกรุ่นตั้งแต่ 7.0 จนถึงก่อน 18.11.13 อยู่ในกลุ่มที่โดน (CERT-EU)

ทำไมต้องรีบกว่าแพตช์รอบปกติ

GitLab มีรอบแพตช์ตามตารางเดือนละสองครั้ง คือวันพุธที่สองและสี่ของเดือน แต่ครั้งนี้เป็นแพตช์แบบ ad-hoc ที่ออกนอกรอบ สำหรับช่องโหว่ร้ายแรงโดยเฉพาะ (GitLab) การที่ผู้ผลิตยอมออกนอกรอบและย้อนไปแก้สายเก่าหลายสายพร้อมกัน เป็นสัญญาณว่าเขาเองก็มองว่าเรื่องนี้รอไม่ได้ ช่องโหว่ระดับ CVSS 10 ที่ยิงจากระยะไกลได้โดยไม่ต้องล็อกอินเป็นเป้าที่น่าสนใจสำหรับคนร้าย เพราะเครื่อง GitLab ที่ตั้งเองมักเปิดออกอินเทอร์เน็ตให้ทีมทำงานจากนอกออฟฟิศได้ (TechTarget)

ทำงานยังไง (พร้อมอุปมาไทย)

นึกถึงเครื่องคิดเงินในร้านที่มีช่องตัวเลขแค่ 4 หลัก ถ้าใครกดยอด 10,000 บาท ตัวเลขจะวนกลับเป็น 0000 แล้วเครื่องก็เปิดลิ้นชักผิดจังหวะ integer overflow ก็คล้ายกัน คือตัวเลขที่ระบบใช้นับเกินขนาดที่จองไว้แล้ววนกลับ ทำให้โปรแกรมจองหน่วยความจำผิดขนาด

ในเคสนี้ จุดที่ตัวเลขล้นอยู่ในขั้นตอนคอมไพล์ regular expression (รูปแบบค้นหาข้อความ) เมื่อเจอ regex ที่ถูกจัดมาเป็นพิเศษ ผลคือคนร้ายอาจรันโค้ดของตัวเองบนเซิร์ฟเวอร์ได้โดยไม่ต้องมีบัญชี (GitLab) บันทึกการเปลี่ยนแปลงของทุกรุ่นที่แก้มีรายการแพตช์ regex ของ Ruby รวมอยู่ด้วย (GitLab)

ถ้าโดนเจาะ เสียหายแค่ไหน

ลองนึกภาพว่า GitLab ของบริษัทคือห้องเก็บแบบแปลนและกุญแจสำรองของทั้งอาคาร คนที่เข้าห้องนี้ได้ไม่ได้แค่เห็นแบบแปลน แต่หยิบกุญแจไปเปิดห้องอื่นต่อได้ด้วย นักวิจัยของ SOC Prime ที่ TechTarget อ้างถึง ประเมินว่าถ้าช่องโหว่นี้ถูกใช้สำเร็จ ผลที่ตามมาได้แก่ การขโมยรหัสผ่านและโทเคน การแก้ไข repository การโจมตีแบบ supply chain การฝังตัวอยู่ในระบบระยะยาว และการขยับไปเครื่องอื่นในเครือข่าย (TechTarget)

จุดที่น่ากลัวที่สุดคือเรื่อง supply chain ถ้าคนร้ายแอบแก้โค้ด สคริปต์ build หรือ container image ที่ออกจาก GitLab ได้ แอปที่ส่งให้ลูกค้าก็อาจมีของแปลกปลอมติดไปด้วย และความเสี่ยงนี้ยังค้างอยู่แม้จะแพตช์เครื่องต้นทางเสร็จแล้ว ทีมวิจัยจึงแนะนำให้ตรวจด้วยว่าโค้ด artifact image template ของโครงสร้างพื้นฐาน และ workflow การ deploy ถูกแก้ไขหรือไม่ (TechTarget)

ช่องโหว่อื่นที่แก้มาในแพตช์เดียวกัน

แพตช์รอบนี้ไม่ได้มีแค่ตัว CVSS 10 แต่รวมช่องโหว่อื่นอีก 11 รายการ (CERT-EU) สองตัวที่ระดับ high ควรรู้ไว้ด้วย

• CVE-2026-15723 (CVSS 8.2) เมื่อเปิดใช้ OmniAuth SAML คู่กับ LDAP auto-linking ผู้ใช้ที่ล็อกอินแล้วอาจยึดบัญชีที่ผูกกับ LDAP ของคนอื่นได้ โดยเจ้าของบัญชีไม่ต้องทำอะไรเลย (GitLab)
• CVE-2026-112212 (CVSS 7.5) คนไม่ล็อกอินอาจวางยาแคชของหน้า OAuth/OIDC discovery เพื่อพาขั้นตอนล็อกอินบางแบบไปที่เซิร์ฟเวอร์ภายนอกได้ (GitLab)

ข้อควรระวังคือ สองตัวนี้รวมถึงอีก 9 รายการที่เหลือแก้เฉพาะใน 19.3.6, 19.4.3 และ 19.5.1 เท่านั้น ส่วนรุ่น backport อย่าง 18.11.13, 19.0.10, 19.1.9 และ 19.2.9 ได้แค่การแก้ตัว CVSS 10 (GitLab) องค์กรที่ใช้ระบบล็อกอินกลางผ่าน SAML หรือ LDAP และยังอยู่สายเก่า จึงยังเปิดรับสองช่องโหว่นี้อยู่ ถ้าอยากได้ครบต้องขยับขึ้นสาย 19.3 ขึ้นไป

ข้อมูลที่ยังไม่ชัด

• ณ เที่ยงวันที่ 22 ต.ค. ยังไม่มีหลักฐานว่ามีการโจมตีจริง (TechTarget) แต่นี่คือสถานะตอนเขียน ไม่ใช่คำรับรองว่าปลอดภัย
• issue ของช่องโหว่ยังไม่เปิด ปกติ GitLab จะเปิด issue หลังแพตช์ 90 วัน (GitLab) แต่ทีม GitLab Security เผยกลไกไว้แล้วในเอกสารกฎตรวจจับ คือ gem org-ruby ที่ใช้เรนเดอร์ไฟล์ .org นำบรรทัด #+TODO: ไปสร้าง regex แบบดิบ ถ้าคำซ้ำเกิน 32,767 ครั้งตัวนับจะล้นจนรันคำสั่งในฐานะผู้ใช้ git ได้ และไม่ต้องล็อกอิน ขอแค่มีโปรเจกต์สาธารณะที่เก็บไฟล์ .org ได้หนึ่งโปรเจกต์ (GitLab Security)
• แพตช์รอบนี้ยังแก้อีก 2 ช่องโหว่ระดับ high และ 5 ระดับ medium (CERT-EU) บทความนี้เน้นแค่ตัว CVSS 10

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

1. เช็กรุ่น ที่แถบซ้ายด้านล่างของ GitLab เลือก Help > Help รุ่นจะแสดงอยู่บนสุดของหน้า (GitLab) หรือรัน sudo gitlab-rake gitlab:env:info บนเครื่องที่ติดตั้งแบบ Linux package (GitLab) แล้วเทียบกับตารางด้านบน
2. อัปเดตทันที ตามคู่มือ upgrade ของ GitLab โดยเริ่มจากเครื่องที่เปิดออกอินเทอร์เน็ตก่อน ตามที่ CERT-EU แนะนำ (CERT-EU)
3. เผื่อเวลา downtime เครื่องแบบ single-node จะดับช่วงอัปเพราะต้องรัน database migration ก่อน (GitLab)
4. ตรวจร่องรอย GitLab ปล่อยกฎตรวจจับ 2 ตัว คือ Onigmo native worker crash และ Org mode render error burst (GitLab) ตัวแรกดูบรรทัด [BUG] ที่มี org-ruby หรือ onig_ ใน /var/log/gitlab/puma/puma_stderr.log (GitLab Security) ตัวที่สองดู Timeout::Error จาก OtherMarkup บนไฟล์ .org ใน /var/log/gitlab/gitlab-rails/exceptions_json.log ถ้าไคลเอนต์เดียวทำให้เกิดห้าครั้งขึ้นไปใน 30 นาทีถือว่าเข้าข่าย (GitLab Security) คำสั่ง grep เต็มอยู่ในคู่มือที่ลิงก์ไว้ด้านบน และ GitLab เตือนว่าการโจมตีที่สำเร็จมักเงียบ ไม่เจอร่องรอยไม่ได้แปลว่าปลอดภัย ให้ดูไฟล์ของผู้ใช้ git ใน /tmp process ลูกแปลกๆ ของ Puma หรือ Sidekiq การเชื่อมต่อออกนอก และ crontab หรือ SSH key ของผู้ใช้ git ที่เปลี่ยนไปด้วย (GitLab Security)
5. ถ้าสงสัยว่าโดน ให้เช็กด้วยว่าโค้ด pipeline หรือ artifact ถูกแก้หรือเปล่า และเปลี่ยนโทเคน/รหัสลับใน CI (TechTarget)

ผมมองว่า…

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

Recap

• อัปเป็น 19.5.1 / 19.4.3 / 19.3.6 / 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13 ตามสาย
• แพตช์เมื่อ 12 ต.ค. ไม่พอ ต้องอัปซ้ำ
• เครื่องที่เปิดออกอินเทอร์เน็ตทำก่อน
• ไล่ log ตามกฎตรวจจับ 2 ตัวของ GitLab
• ใช้ GitLab.com ไม่ต้องทำอะไร