ช่องโหว่ GitLab CVSS 10 ถูกใช้โจมตีจริงแล้ว — Alpine Linux อัปเกรดแล้วยังโดน เพราะตัวแก้อยู่ใน Ruby

CVE-2026-97229 เป็นช่องโหว่ระดับ CVSS 10.0 ใน GitLab CE/EE ที่อาจให้ผู้ไม่ได้ยืนยันตัวตนรันโค้ดบนเซิร์ฟเวอร์ได้ ผ่าน regular expression ที่สร้างมาเฉพาะในค่าตั้ง CI/CD GitLab ออกแพตช์เมื่อ 12 ต.ค. 2026 และ CISA เพิ่มเข้าแค็ตตาล็อก Known Exploited Vulnerabilities เมื่อ 29 ต.ค. พร้อมกำหนดให้หน่วยงานรัฐบาลกลางสหรัฐแก้ภายใน 1 พ.ย.

เหตุที่ควรอ่านต่อคือรายงานของ Alpine Linux เมื่อ 28 ต.ค. ซึ่งถูกโจมตีด้วยช่องโหว่นี้จริง และพบว่าการอัปเกรด GitLab ตามปกติไม่ได้ปิดช่องโหว่ เพราะตัวแก้ไม่ได้อยู่ในโค้ดของ GitLab แต่อยู่ในแพตช์ของ Ruby

ใครได้รับผลกระทบ

• GitLab จากแพ็กเกจทางการ: เวอร์ชันตระกูล 19.2 ก่อน 19.2.8, 19.3 ก่อน 19.3.5 และ 19.4 ก่อน 19.4.2 ต้องอัปเกรด ส่วน GitLab.com และ Dedicated แก้ให้แล้ว
• GitLab ที่ใช้ Ruby ของตัวเอง: ถ้าติดตั้งจากซอร์สหรือสร้าง container image เอง การอัปเกรด GitLab อย่างเดียวไม่พอ ต้องใช้ Ruby 3.3.13, 3.4.12, 4.0.9 หรือใหม่กว่า ซึ่งออกเมื่อ 23 ต.ค.
• image alpinelinux/gitlab: Alpine ระบุว่าทุก tag เก่า และ 19.3.6 ที่ดึงก่อน 27 ต.ค. ยังมีช่องโหว่ ต้องดึง 19.3.6 ใหม่
• โปรแกรม Ruby อื่น: บั๊กอยู่ใน Onigmo ซึ่งเป็น regex engine ของ Ruby Alpine เตือนว่าโปรแกรมใดก็ตามที่คอมไพล์ regex จาก input ที่ไม่น่าเชื่อถือก็เสี่ยงเช่นกัน ไม่ใช่แค่ GitLab

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

• 13 ต.ค.: อัปเกรดผิดเวอร์ชันเป็น 19.3.4 แทน 19.3.5 ที่มีตัวแก้
• 20–21 ต.ค.: บัญชีที่เพิ่งสมัครส่งค่าตั้ง CI ที่สร้างมาเฉพาะ ทำให้ GitLab worker ล่ม 8 ครั้ง ใน 4 ครั้งนั้นผู้โจมตีไปได้ครึ่งทางก่อนล้มเหลว และยังดาวน์โหลด container image ของ Alpine ไปด้วย
• 22 ต.ค.: อัปเกรดเป็น 19.3.6 แต่ไม่ได้ปิดช่องโหว่ เพราะ image ใช้ Ruby มาตรฐาน ไม่มีแพตช์ที่ GitLab ใส่ไว้ในแพ็กเกจทางการ
• 25–26 ต.ค.: ผู้โจมตีกลับมาอีกแต่ไม่สำเร็จ และ Alpine พบว่าระบบยังมีช่องโหว่อยู่
• 27–29 ต.ค.: ปิดระบบ สร้างใหม่ทั้งหมด รีเซ็ตรหัสผ่านทุกบัญชี เปลี่ยน secret key แล้วเปิดใหม่บน 19.3.7

Alpine ไม่พบหลักฐานว่าโค้ดของผู้โจมตีรันสำเร็จ แต่ก็ยืนยันไม่ได้ว่าไม่สำเร็จ เพราะการโจมตีที่สำเร็จจะไม่ทิ้งร่องรอยการล่มหรือ web log, log บางส่วนหายไปแล้ว และไม่มีการบันทึกการเชื่อมต่อขาออก ผลตรวจระบุว่า aports, แพ็กเกจที่สร้างช่วง 20–24 ต.ค. และรีลีส 21 ต.ค. ไม่ถูกแก้ไข และ signing key ไม่เคยอยู่บนเซิร์ฟเวอร์ GitLab แต่ข้อมูลที่อาจรั่วถ้าโจมตีสำเร็จมีทั้ง password hash, 2FA secret, CI/CD variable และ runner token

สิ่งที่ควรทำตอนนี้

1. ตรวจเวอร์ชัน GitLab และอัปเกรดเป็นรุ่นที่แก้แล้วหรือใหม่กว่า
2. ถ้าใช้ source install หรือ image ที่สร้างเอง ให้ตรวจเวอร์ชัน Ruby ด้วย
3. ถ้า instance เปิดรับอินเทอร์เน็ตโดยไม่ได้แพตช์หลัง 12 ต.ค. ให้ตรวจ worker crash, บัญชีใหม่ และ CI config ที่ผิดปกติ
4. ถ้ายืนยันไม่ได้ ให้ถือว่าถูกเจาะแล้ว และหมุนเวียน CI/CD variable, runner token และ integration credential

Shadowserver ติดตาม GitLab CE ที่เปิดสู่อินเทอร์เน็ตราว 2,800 instance แต่ไม่ได้บอกว่าแพตช์แล้วกี่แห่ง

มุมมอง AI Curator

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

อีกข้อคือความกล้าของ Alpine ที่เขียนตรง ๆ ว่า “พิสูจน์ไม่ได้” แล้วสร้างใหม่ทั้งหมด CI server ถือ secret ของทั้งองค์กร และเมื่อ log ขาดไป การสรุปเองว่าไม่โดนคือความเสี่ยงที่แพงกว่าการรื้อทำใหม่ ถ้า GitLab ของคุณไม่มี log การเชื่อมต่อขาออกและเก็บ log ไม่ถึงเดือน เรื่องนี้เป็นงานที่ควรเริ่มก่อนเหตุการณ์ครั้งหน้า

แหล่งข่าว

• GitLab security incident: attempted exploitation of CVE-2026-97229 — Alpine Linux
• GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8 — GitLab
• CISA says max severity GitLab flaw now exploited in the wild — BleepingComputer
• CVE-2026-97229 — NVD