สรุปสั้น

ผู้โจมตีกำลังใช้ช่องโหว่ระดับร้ายแรงสูงสุดใน GitLab ที่เพิ่งถูกเปิดเผยเมื่อสัปดาห์ก่อนโจมตีจริง ซึ่งอาจเปิดทางลัดให้ผู้ไม่หวังดีเข้าถึงห่วงโซ่อุปทาน (Supply Chain) ซอฟต์แวร์ขององค์กรได้ ช่องโหว่ CVE-2026-85706 ที่บริษัท GitLab เปิดเผยและออกแพตช์เมื่อวันที่ 10 กันยายน 2569 เป็นช่องโหว่ประเภท path traversal ที่เปิดให้ผู้ไม่ผ่านการยืนยันตัวตนอ่านไฟล์ใดก็ได้จากเซิร์ฟเวอร์ GitLab และได้คะแนนความรุนแรง CVSS เต็ม 10 เต็ม

ต้นเหตุมาจากการจำกัดขอบเขต path ที่ไม่รัดกุมและการขาดการตรวจสอบการยืนยันตัวตนใน repository commits API ของแพลตฟอร์ม โดยกระทบทั้ง GitLab Community Edition (CE) และ Enterprise Edition (EE) ที่องค์กรนำไปติดตั้งเป็น instance บนระบบของตัวเอง หน่วยงาน CISA เพิ่มช่องโหว่นี้เข้าบัญชี Known Exploited Vulnerabilities เมื่อวันที่ 11 กันยายน และสั่งให้หน่วยงานรัฐบาลกลางแพตช์หรือปิด GitLab ที่ดูแลเองภายในกำหนด แม้ช่องโหว่จะให้สิทธิ์แค่อ่านไฟล์ แต่ผู้เชี่ยวชาญเตือนว่าเพียงเท่านี้ก็เพียงพอให้ผู้โจมตีดึง credential และความลับของระบบ CI/CD ออกไป จนอาจนำไปสู่การยึดครอง GitLab ทั้งชุดและการรุกเข้าสู่สภาพแวดล้อมการพัฒนาซอฟต์แวร์ที่เชื่อมโยงกันได้

รายละเอียดข่าว

เว็บไซต์ Dark Reading รายงานเมื่อวันที่ 15 กันยายน 2569 ว่า นาย Jake Knott หัวหน้าฝ่ายข่าวกรองภัยคุกคามของบริษัท watchTowr เปิดเผยว่ากิจกรรมมุ่งร้ายลุกลามอย่างรวดเร็วในวันศุกร์ที่ผ่านมา จากการหยั่งเชิงกลายเป็นการโจมตีเต็มรูปแบบและมีการขโมยไฟล์ที่มีความอ่อนไหวออกไปจริง โดยในช่วงสุดสัปดาห์ทีมงานยังพบผู้โจมตีดูดไฟล์ตั้งค่าที่เก็บความลับ พร้อมกับไฟล์ตั้งค่า SSH ของระบบเหยื่อออกไปด้วย

นาย Knott อธิบายว่าการผสมผสานนี้อันตรายมาก เพราะอาจเปิดให้ผู้โจมตีสกัดรหัสผ่าน เชื่อมต่อไปยัง instance ที่อนุญาตการยืนยันตัวตนด้วยรหัสผ่าน และเข้าถึงเครื่องโฮสต์ได้ภายใต้เงื่อนไขที่เหมาะสม ก่อนหน้านี้ในวันที่ 11 กันยายน นักวิจัยของ watchTowr ก็สังเกตเห็นการหยั่งเชิงพฤติกรรมเพื่อทดสอบช่องโหว่บนเครือข่าย honeypot ของบริษัท ทั้งนี้ watchTowr ยังตั้งข้อสังเกตว่า CVE-2026-85706 เป็นช่องโหว่ระดับวิกฤตตัวที่สองใน GitLab ที่ถูกเล็งโจมตีในช่วงหลัง โดยเมื่อเดือนก่อนหน้าผู้โจมตีก็เพิ่งใช้ CVE-2026-19478 ซึ่งเป็นช่องโหว่ code injection ผ่าน GraphQL ไม่นานหลังถูกเปิดเผยต่อสาธารณะ

รายละเอียดช่องโหว่

CVE-2026-85706 เป็นช่องโหว่ path traversal ที่เกิดจากการจำกัดขอบเขต path ไม่รัดกุมและขาดการตรวจสอบการยืนยันตัวตนใน repository commits API ของ GitLab ทำให้ผู้ที่ไม่ต้องล็อกอินสามารถอ่านไฟล์ใดก็ได้บนเซิร์ฟเวอร์ ตามคำแนะนำของ GitLab ช่องโหว่นี้มีอยู่ในทั้ง Community Edition และ Enterprise Edition ที่องค์กรใช้ตั้ง instance แบบดูแลเอง (self-hosted)

นาย Knott ระบุว่าเงื่อนไขหนึ่งที่ช่วยจำกัดความเสียหายคือการโจมตีต้องอาศัยองค์กรเป้าหมายมีโปรเจกต์สาธารณะ (public project) อย่างน้อยหนึ่งโปรเจกต์บนเซิร์ฟเวอร์ GitLab แต่เขาก็เตือนว่านี่น่าจะเป็นการตั้งค่าที่พบได้ค่อนข้างบ่อย และบางองค์กรอาจไม่รู้ตัวว่าตนเองมีโปรเจกต์สาธารณะอยู่ เขาอธิบายเพิ่มว่าองค์กรที่รัน GitLab อาจกั้นการเข้าถึงระบบไว้ ทำให้คนนอกมองไม่เห็นโปรเจกต์หากไม่ยืนยันตัวตน แต่นั่นไม่ได้แปลว่าโปรเจกต์ที่ถูกสร้างเป็น “public” จะพ้นจากการเข้าถึง บางครั้งบริษัทอาจตั้งใจเปิดโค้ดบางส่วนสู่สาธารณะ ขณะที่บางกรณีก็เข้าใจผิดว่าโปรเจกต์ยังเป็น “ภายใน” ทั้งที่ถูกตั้งเป็นสาธารณะภายในระบบ GitLab ของตน แม้ช่องโหว่จะให้สิทธิ์แบบอ่านอย่างเดียว แต่ผู้โจมตีสามารถใช้การเข้าถึงนั้นดึงข้อมูลอ่อนไหวอย่าง credential และความลับ CI/CD ซึ่ง นาย Knott จัดว่าช่องโหว่นี้เป็นช่องโหว่ที่เอื้อต่อการโจมตีห่วงโซ่อุปทาน

ผลกระทบ

ผลกระทบตกอยู่ที่องค์กรที่รัน GitLab แบบดูแลเอง โดยเฉพาะทีมพัฒนาซอฟต์แวร์ที่ใช้ GitLab เป็นศูนย์กลางของซอร์สโค้ดและไปป์ไลน์ CI/CD เพราะการเข้าถึงเพียงระดับอ่านไฟล์ก็สามารถแปรเป็นการรั่วไหลของ credential กุญแจ SSH และความลับที่ฝังในไปป์ไลน์ ซึ่งเป็นวัตถุดิบตั้งต้นให้ผู้โจมตีต่อยอดเข้าไปยังระบบปลายทางที่สำคัญกว่าได้ ความน่ากังวลอยู่ที่ลักษณะ “ห่วงโซ่อุปทาน” คือเมื่อยึดจุดกลางอย่าง GitLab ได้ ผู้โจมตีก็อาจแทรกเข้าสู่โครงสร้างการพัฒนาและการส่งมอบซอฟต์แวร์ที่เชื่อมโยงกันได้ทั้งสาย และเนื่องจากช่องโหว่นี้ถูกใช้โจมตีจริงและอยู่ในบัญชี KEV แล้ว องค์กรที่ยังไม่แพตช์จึงถือว่ามีความเสี่ยงเฉพาะหน้าอย่างชัดเจน

คำแนะนำ

watchTowr แนะนำให้ลูกค้า GitLab อัปเดต instance ที่ดูแลเองเป็นเวอร์ชัน 19.3.2, 19.2.6 หรือ 19.1.8 สำหรับทั้ง Community Edition และ Enterprise Edition หากยังอัปเดตไม่ได้ ให้รีบลบการเข้าถึงแบบสาธารณะทั้งหมดออกจาก instance ทันที ส่วนลูกค้า GitLab Dedicated ไม่ต้องดำเนินการใด ๆ ตามที่ GitLab ระบุ และแพลตฟอร์มออนไลน์ GitLab.com ก็ได้แพตช์ช่องโหว่นี้ไปแล้ว นอกจากนี้ทีมความปลอดภัยควรตรวจสอบล็อกการเข้าถึงบน repository commits API เพื่อหาคำขอที่น่าสงสัยหรือไม่ผ่านการยืนยันตัวตน ซึ่งอาจบ่งชี้ถึงการหยั่งเชิงหรือการพยายามโจมตี

แหล่งอ้างอิง