GitLab CE/EE ถูกโจมตีจริง 2 ช่อง รวม CVE-2026-97229 (CVSS 10.0)

พอดีเห็น CISA ใส่ GitLab ลงรายการ KEV เป็นครั้งที่สองในรอบสองเดือน คือ CVE-2026-97229 เมื่อ 29 ต.ค. 2026 ต่อจาก CVE-2026-85706 ที่เข้าไปตั้งแต่ 11 ก.ย. ทั้งสองตัวได้ CVSS 10.0 เต็มและไม่ต้องล็อกอินทั้งคู่ เลยรวบมาไว้ในโพสต์เดียว พร้อมแยกให้ชัดว่าสายรุ่นไหนต้องไปรุ่นไหน เพราะรุ่นที่แก้ของตัวแรกไม่ครอบคลุมตัวที่สอง

เกิดอะไรขึ้น

CVE-2026-85706 เป็น path traversal ใน repository commits API ตามที่ GitLab เขียนไว้ สาเหตุคือการจำกัด path ไม่รัดกุมและ API ไม่บังคับให้ยืนยันตัวตน ผลคือผู้ที่ไม่ได้ล็อกอินอ่านไฟล์ใดๆ บนเซิร์ฟเวอร์ได้ GitLab ออกแพตช์เมื่อ 10 ก.ย. 2026 เป็น 19.3.2, 19.2.6 และ 19.1.8 แล้วเมื่อ 23 ก.ย. ย้อนแพตช์ไปสายเก่าเป็น 19.0.9 และ 18.11.12 CISA ใส่ KEV วันถัดมา (11 ก.ย.) กำหนดให้หน่วยงานรัฐบาลกลางสหรัฐแก้ภายใน 14 ก.ย.

CVE-2026-97229 เป็น integer overflow ใน CI/CD regular expression compiler ผู้ที่ไม่ได้ล็อกอินส่ง regular expression ที่ออกแบบมาเป็นพิเศษในค่า CI/CD แล้วรันโค้ดบนเซิร์ฟเวอร์ได้ สาเหตุที่ GitLab ระบุคือการตรวจ regex ไม่เพียงพอ แก้ในแพตช์วันที่ 12 ต.ค. 2026 CISA ใส่ KEV เมื่อ 29 ต.ค. กำหนดแก้ภายใน 1 พ.ย. และหมายเหตุใน KEV บอกว่าผลิตภัณฑ์อื่นอาจโดนบั๊ก integer overflow ตัวเดียวกันของ Ruby/Onigmo ได้

ที่มาของตัวหลังคือบั๊กในเอนจิน regex ของ Ruby ตามประกาศของ ruby-lang.org (23 ต.ค. 2026) แอปที่คอมไพล์ regex จากข้อความที่ผู้โจมตีควบคุมได้ (เช่น Regexp.new) เสี่ยง ส่วนแอปที่ใช้เฉพาะ regex ที่นักพัฒนาเขียนเองไม่โดน และ Regexp.timeout ป้องกันไม่ได้

ระดับความรุนแรง

ทั้งสองตัวได้ CVSS 3.1 ที่ 10.0 ตาม GitLab ตัวแรกเป็น AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N คือกระทบทั้งการอ่านและความถูกต้องของข้อมูลระดับสูง แต่ไม่กระทบความพร้อมใช้งาน ตัวที่สองเป็น AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H คือครบทั้งสามด้าน ทั้งคู่โจมตีผ่านเครือข่าย ไม่ซับซ้อน ไม่ต้องมีสิทธิ์ และไม่ต้องให้ใครกดอะไร

CISA ระบุในตาราง KEV ว่ามีการโจมตีจริงทั้งสองตัว ฟิลด์ ransomware เป็น Unknown ทั้งคู่ ผมเปิดไฟล์ KEV ที่ CISA ปล่อยเมื่อ 3 พ.ย. 2026 ตรวจเองแล้ว ส่วน CVE-2026-110264 (ตัวที่สี่ ดูหัวข้อถัดไป) ไม่ได้อยู่ใน KEV ตามไฟล์เดียวกัน

คำว่าอ่านไฟล์ได้ของตัวแรกไม่ใช่เรื่องเล็ก เพราะ GitLab เองออก detection ที่เฝ้าดูความพยายามอ่าน gitlab.yml ซึ่งแปลว่าไฟล์ตั้งค่าของระบบคือเป้าหมายที่คาดไว้

ใครโดนบ้าง รุ่นไหนต้องไปรุ่นไหน

GitLab ระบุรุ่น 19.3.4 มีบั๊กที่หน้า merge request เมื่อเปิดอินทิเกรชัน Ona แก้ใน 19.3.5 รุ่นที่แก้ CVE-2026-97229 ในสาย 19.3 คือ 19.3.5 ไม่ใช่ 19.3.4 ซึ่งตรงกับชื่อหน้า patch release ของ GitLab (19.4.2, 19.3.5, 19.2.8)

ตาราง "แพตช์ล่าสุดของสาย" ผมแนะนำเป็นเป้าหมาย เพราะ 21 ต.ค. GitLab ออกอีกชุด (19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13) แก้ CVE-2026-110264 ตัวที่สี่ในตระกูล regex compiler ที่ CVSS 10.0 เช่นกัน รอบนี้กระทบกว้างกว่า คือตั้งแต่ 7.0 ขึ้นมาก่อนรุ่นที่แก้ และ GitLab ระบุว่าใครใช้ Ruby ของตัวเองแทนตัวที่มากับแพ็กเกจทางการ ต้องอัป Ruby เป็น 3.3.13, 3.4.12, 4.0.9 หรือใหม่กว่าด้วย เพราะแก้ที่ Ruby ไม่ใช่โค้ด GitLab

ก่อนหน้านั้นเมื่อ 23 ก.ย. 19.4.1 / 19.3.3 / 19.2.7 แก้ regex สองตัวที่ผู้โจมตีต้องล็อกอิน (CVE-2026-89078 double free และ CVE-2026-93577 integer overflow ที่ 9.9) ใครหยุดที่รุ่นนั้นยังโดน CVE-2026-97229 อยู่

GitLab.com แพตช์แล้ว และ GitLab Dedicated แพตช์ภายในก่อนประกาศ ลูกค้าสองกลุ่มนี้ไม่ต้องทำอะไร ส่วน self-managed ต้องอัปเอง

วิธีแก้

1. เช็กรุ่นปัจจุบัน แล้วเทียบกับตารางด้านบนว่าสายไหนต้องไปรุ่นไหน
2. สำรองข้อมูล ด้วย gitlab-backup ก่อนอัปทุกครั้ง
3. อัปเป็นแพตช์ล่าสุดของสาย และอัป Ruby ด้วยถ้าใช้ Ruby ของตัวเอง
4. ตรวจร่องรอย ย้อนหลังตั้งแต่ก่อนแพตช์ ถ้าเครื่องเปิดออกอินเทอร์เน็ต

เช็กรุ่นปัจจุบันก่อน

sudo gitlab-rake gitlab:env:info | head -20
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
dpkg -l | grep -E 'gitlab-(ce|ee)'

จากนั้นสำรองข้อมูลแล้วอัป ตัวอย่างข้างล่างเป็นสาย 19.4 ให้เปลี่ยนเลขตามตารางด้านบน และเปลี่ยน ce เป็น ee ถ้าใช้ Enterprise

sudo gitlab-backup create
sudo apt update
apt-cache madison gitlab-ce | head
sudo apt install gitlab-ce=19.4.3-ce.0
sudo gitlab-ctl status

ถ้ารันเป็น Docker ให้เปลี่ยน tag แล้วสร้าง container ใหม่ด้วยโวลุ่มเดิม

docker pull gitlab/gitlab-ce:19.4.3-ce.0

ข้อควรรู้ตามหน้า patch release ของ GitLab แพตช์ชุดนี้มี database migration เครื่องเดี่ยว (single-node) ต้องยอมรับว่าจะหยุดให้บริการระหว่าง migrate ส่วนระบบหลายเครื่องใช้ขั้นตอนอัปแบบ zero-downtime ของ GitLab ได้ ถ้าต้องข้ามหลาย minor ให้ดู upgrade path ของ GitLab ก่อน ผมไม่ได้ไล่เส้นทางนี้ให้

เช็กว่าโดนหรือยัง

GitLab เผยแพร่ threat detection สำหรับ self-managed ไว้ในหน้า patch release (หน้าของ CVE-2026-97229 ลิงก์ไปที่ repository gitlab-security-oss/tldr) ของ CVE-2026-85706 มีสามตัวคือ LFI พยายามอ่าน gitlab.yml, LFI ผ่านพารามิเตอร์ metadata.path และ LFI แบบไล่ path ของ CVE-2026-97229 มีหกตัวคือ Onigmo native worker crash, GraphQL CI lint hostile regexp, CI regexp oversized non-ASCII path, CI regexp guard rejection, CI lint Workhorse worker crash และ CI lint scripted client error burst หน้าของ GitLab บอกชื่อและลิงก์ไปที่นิยาม ไม่ได้อธิบายว่าไปดูที่ log ไหน

GitLab ไม่ได้ประกาศ IOC เป็น path หรือ request ที่จับด้วย grep ได้ ผมเลยให้ตัวอย่างหาแบบหยาบๆ ที่เป็นของผมเอง ไม่ใช่ของ GitLab ใช้ได้เฉพาะเมื่อพารามิเตอร์ปรากฏใน URL ถ้าส่งผ่าน body จะไม่เห็นใน access log

# ตัวอย่างหยาบ (ของผมเอง) path ของ Omnibus: คำขอไปที่ commits API ที่มีชื่อไฟล์ระบบหรือ ../
sudo zgrep -hiE 'repository/commits' /var/log/gitlab/nginx/gitlab_access.log* \
  | grep -iE 'gitlab\.yml|secrets|%2e%2e|\.\./|/etc/' | head -50

# worker ล้ม หรือ 500 ต่อเนื่องที่ CI lint / GraphQL
sudo grep -hE '"status":500' /var/log/gitlab/gitlab-rails/production_json.log* | grep -iE 'lint|graphql' | tail -20

ถ้าเจอร่องรอยจริงหรือสงสัยว่าเครื่องเปิดออกอินเทอร์เน็ตตอนยังไม่แพตช์ ควรถือว่าไฟล์ในเครื่องที่ GitLab อ่านได้อาจรั่ว ผมจะพิจารณาหมุนเวียนความลับที่เก็บในเครื่อง เช่นค่าใน /etc/gitlab/gitlab-secrets.json และ token ของ runner ซึ่งเป็นการตัดสินใจของผม ไม่ใช่คำแนะนำของ GitLab ส่วนแนวทางไล่ตรวจเครื่องทั้งหมดดูที่ Debian server security scan

GitLab ระบุว่ารายละเอียดของช่องโหว่ชุดนี้จะเปิดสาธารณะใน issue tracker 90 วันหลังออกรุ่น ซึ่งแปลว่ายังมีข้อมูลให้ผู้โจมตีเรียนรู้เพิ่มอีก

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

ปล. GitLab ออกแพตช์ชุดถัดมาเมื่อ 29 ต.ค. 2026 (19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11, 18.11.14) หน้า patch release ของชุดนั้นรายการเดียวคือ CVE-2026-111943 เรื่อง GitLab ถอนความเชื่อถือใบรับรอง CA ระดับกลาง 8 ใบของ eMudhra ที่ private key รั่ว ไม่เกี่ยวกับ regex ตารางด้านบนยังเป็นเลขที่ครอบคลุม CVE ในโพสต์นี้ แต่ถ้าจะอัปเพิ่มก็ใช้เลขของชุด 29 ต.ค. ได้เลย ส่วน GitLab Runner ที่ host เองต้องอัปแยก (หน้าชุดนั้นระบุ 19.5.1)

ที่มา: GitLab Critical Patch Release 19.3.2 / 19.2.6 / 19.1.8 (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-3-2-released/), 19.4.1 / 19.3.3 / 19.2.7 (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-1-released/), 19.4.2 / 19.3.5 / 19.2.8 (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/), 19.5.1 (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/), CISA Known Exploited Vulnerabilities Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), ประกาศ Ruby "Regexp fixes for GitLab CVEs" (https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves) ข้อมูลถึง 5 พ.ย. 2026 ส่วน KEV ตรวจจากไฟล์ที่ CISA ปล่อยเมื่อ 3 พ.ย. 2026 เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ