GitLab CVE-2026-85706 ถูกใช้งานโจมตีจริง: แพตช์ Self-Managed ทันที

CVE-2026-85706 เป็นช่องโหว่ path traversal ระดับร้ายแรงสูงสุดใน GitLab Community Edition (CE) และ Enterprise Edition (EE) แบบติดตั้งและดูแลเอง (self-managed) มีคะแนน CVSS 3.1 ที่ 10.0 ภายใต้เงื่อนไขบางอย่าง ผู้โจมตีที่ยังไม่ได้ยืนยันตัวตนอาจอ่านไฟล์ตามอำเภอใจจากเซิร์ฟเวอร์ GitLab ได้ นี่ไม่ใช่ความเสี่ยงเชิงทฤษฎีอีกต่อไป: CISA ของสหรัฐฯ เพิ่มรายการนี้ในบัญชี Known Exploited Vulnerabilities (KEV) แล้ว ขณะที่นักวิจัยพบความพยายามสแกนและโจมตีต่ออินสแตนซ์ที่เปิดออกสู่อินเทอร์เน็ตไม่นานหลังมีแพตช์ 32122

สิ่งที่ต้องทำทันที

หากใช้ GitLab แบบ self-managed และอยู่ในเวอร์ชันที่ได้รับผลกระทบ ให้รีบอัปเกรดเป็นเวอร์ชันที่แก้ไขแล้วโดยเร็วที่สุด:

• 19.1.8 หรือใหม่กว่า
• 19.2.6 หรือใหม่กว่า
• 19.3.2 หรือใหม่กว่า

ช่วงเวอร์ชันที่ได้รับผลกระทบคือ GitLab CE/EE ตั้งแต่ 18.7 แต่ก่อน 19.1.8, สาย 19.2 แต่ก่อน 19.2.6 และสาย 19.3 แต่ก่อน 19.3.2 โดย GitLab ออกแพตช์เมื่อวันที่ 10 กันยายน 2026 37

CISA เพิ่ม CVE-2026-85706 ลงใน KEV เมื่อวันที่ 11 กันยายน และกำหนดวันดำเนินการภายใน 14 กันยายนสำหรับหน่วยงานพลเรือนของรัฐบาลกลางสหรัฐที่อยู่ภายใต้ข้อกำหนดดังกล่าว เส้นตายนี้ไม่ได้บังคับใช้กับองค์กรเอกชนโดยอัตโนมัติ แต่สะท้อนระดับความเร่งด่วนของความเสี่ยงสำหรับระบบ self-managed ที่เข้าถึงได้จากอินเทอร์เน็ต 3

ช่องโหว่นี้ทำอะไรได้

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

โดยหลักแล้ว นี่คือช่องโหว่ การเปิดเผยไฟล์ ไม่ใช่หลักฐานว่า CVE-2026-85706 เพียงตัวเดียวทำให้รันโค้ดจากระยะไกล (RCE) ได้ อย่างไรก็ตาม การอ่านไฟล์ตามอำเภอใจอาจทำให้ข้อมูลที่ใช้ต่อยอดการบุกรุกหลุดออกมาได้ ขึ้นอยู่กับการตั้งค่าเซิร์ฟเวอร์ เช่น การตั้งค่าแอปพลิเคชัน โทเค็น กุญแจ SSH ข้อมูลรับรองฐานข้อมูล และความลับอื่นที่โปรเซส GitLab อ่านได้ 925

เหตุใดการโจมตีจริงจึงเปลี่ยนระดับการรับมือ

watchTowr รายงานว่าพบการ probe ช่องโหว่นี้ในสภาพแวดล้อมจริง รวมถึงในเครือข่ายฮันนีพอตเมื่อวันที่ 11 กันยายน ขณะที่รายการ KEV ของ CISA ก็เป็นสัญญาณสำคัญ เพราะบัญชีนี้ใช้ระบุช่องโหว่ที่มีหลักฐานว่าถูกใช้โจมตีในโลกจริง 222

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

มองระบบที่เปิดเผยต่ออินเทอร์เน็ตว่าอาจมีข้อมูลลับรั่วแล้ว

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

ควรให้ความสำคัญกับการตรวจสอบและหมุนเวียนข้อมูลรับรองต่อไปนี้:

• ความลับของแอปพลิเคชันและไฟล์คอนฟิก GitLab
• ข้อมูลรับรองฐานข้อมูล, Redis, object storage, registry, SMTP, directory service และ identity provider ที่อยู่ในคอนฟิก
• ตัวแปร CI/CD, deploy token, access token, runner token, deploy key และข้อมูลรับรองที่เมานต์ให้ job หรือ integration ใช้งาน
• คีย์คลาวด์ ข้อมูลรับรอง package registry กุญแจลงนาม รวมถึง private key ของ SSH หรือ TLS ที่โฮสต์หรือโปรเซส GitLab เข้าถึงได้

ต้องวางแผนการหมุนเวียนอย่างรอบคอบ การเปลี่ยน application secret หรือค่าที่เกี่ยวข้องกับการเข้ารหัสอาจทำให้ session ใช้ไม่ได้ และรบกวนการตั้งค่าหรือ integration ที่เข้ารหัสไว้ ควรเก็บ log และหลักฐานคอนฟิกที่เกี่ยวข้องก่อน กำหนดขั้นตอนกู้คืน และทยอยเปลี่ยนข้อมูลลับที่เสี่ยงสูงตามลำดับที่ควบคุมได้

การตรวจจับ: จุดที่ควรค้นหา

ตัวบ่งชี้เบื้องต้นที่มีประโยชน์คือ HTTP POST ไปยังเส้นทาง Repository Commits API:

/api/v4/projects/<id>/repository/commits/

รายงานแนะนำให้ค้นหาคำขอที่มีพารามิเตอร์ file.path ตรวจสอบ reverse proxy, load balancer, WAF และ GitLab Rails access log เพื่อหาคำขอที่ไม่ยืนยันตัวตน ค่าที่เข้ารหัสซึ่งดูคล้าย path traversal, project ID ที่ผิดปกติ ความพยายามซ้ำ ๆ ที่ล้มเหลว รูปแบบการไล่ค้นหา หรือขนาด response ที่ผิดปกติ 212426

ควรสืบหากิจกรรมที่อาจเกี่ยวข้องหลังช่วงเวลาที่สงสัยว่าถูกเข้าถึงด้วย เช่น การสร้างหรือใช้งานโทเค็นใหม่ การลงทะเบียน runner การแก้ไขตัวแปร CI/CD หรือนิยาม pipeline การ import ที่ผิดปกติ กิจกรรม GraphQL และการเชื่อมต่อขาออกที่ไม่คาดคิด แนวทางที่รายงานหลังการออกแพตช์ยังระบุให้ตรวจสอบ commit, GraphQL subscription, project import และ CI/CD pipeline ด้วย 23

การค้นหา log แล้วไม่พบรายการตรงกันไม่ใช่ข้อยืนยันว่าปลอดภัย เพราะการเก็บ log อาจมีระยะเวลาจำกัด ตัวแอปพลิเคชันอาจไม่บันทึกรายละเอียดคำขอที่สำคัญ หรือบันทึกจาก proxy/WAF อาจเป็นหลักฐานเพียงส่วนเดียวที่เหลืออยู่

มาตรการชั่วคราวหากยังอัปเกรดไม่ได้

การอัปเกรดคือวิธีแก้ไขที่จำเป็น หากไม่สามารถทำ emergency upgrade ได้ทันที ให้ลดการเปิดเผยโดยจำกัดการเข้าถึงเว็บและ API ของ GitLab ไว้เฉพาะผ่าน VPN หรือเครือข่ายที่อนุญาต กฎ reverse proxy หรือ WAF ที่จำกัดเส้นทาง Repository Commits API ที่ได้รับผลกระทบอย่างรัดกุม อาจช่วยลดความเสี่ยงในระยะสั้นได้ แต่มีโอกาสทำให้ automation ที่ใช้งานปกติหยุดทำงาน และไม่ใช่สิ่งทดแทนการแพตช์

ลำดับการตอบสนองที่ใช้ได้จริงสำหรับทุกเซิร์ฟเวอร์ที่ได้รับผลกระทบคือ:

1. ระบุและจัดลำดับความสำคัญ ของอินสแตนซ์ self-managed ที่เข้าถึงได้จากภายนอก
2. อัปเกรด เป็น 19.1.8, 19.2.6, 19.3.2 หรือเวอร์ชันใหม่กว่า
3. ยืนยันเวอร์ชันที่กำลังรันอยู่ หลังเปลี่ยนแปลง
4. เก็บรักษาและตรวจสอบ log เพื่อหาสัญญาณการใช้ช่องโหว่
5. หมุนเวียนข้อมูลลับที่อาจถูกเปิดเผย ตามสิทธิ์ที่เซิร์ฟเวอร์เข้าถึงและผลกระทบต่อธุรกิจ

ช่องโหว่อื่นในชุดอัปเดตเดียวกัน

รายงานด้านความปลอดภัยชุดเดียวกันกล่าวถึงปัญหาใน Enterprise Edition อีก 2 รายการที่ได้รับการแก้ไข:

• CVE-2026-87719 มีรายงานว่าเป็นช่องโหว่ insecure deserialization สำหรับผู้ใช้ที่ยืนยันตัวตนแล้ว คะแนน CVSS 9.9 และบางรายงานเชื่อมโยงกับการเปิดเผยคอนฟิกและข้อมูลรับรองของ Advanced Search 6
• CVE-2026-88765 มีรายงานว่าเป็นความเสี่ยง RCE สำหรับผู้ใช้ที่ยืนยันตัวตนแล้ว โดยเกี่ยวข้องกับการนำเข้า Git project export ที่ถูกสร้างมาเป็นพิเศษ มีคะแนน CVSS ที่รายงานไว้ 8.5 625

ทั้งสองช่องโหว่มีเงื่อนไขและผลกระทบต่างจาก CVE-2026-85706 แต่สำหรับ GitLab self-managed ที่เปิดออกสู่อินเทอร์เน็ต ช่องโหว่อ่านไฟล์โดยไม่ต้องยืนยันตัวตนที่กำลังถูกโจมตีควรยังคงเป็นลำดับแรกของการควบคุมเหตุและตอบสนองเหตุการณ์