สรุปสั้น

Gitea แพลตฟอร์มจัดการซอร์สโค้ดแบบ Git ที่องค์กรนิยมติดตั้งใช้งานบนเซิร์ฟเวอร์ของตัวเอง มีช่องโหว่ระดับวิกฤตที่เปิดให้ผู้โจมตีซึ่งไม่ต้องยืนยันตัวตนใดๆ อ่านไฟล์ใดก็ได้ที่บัญชีระบบของบริการ Gitea มีสิทธิ์เข้าถึง ช่องโหว่นี้ถูกติดตามในหมายเลข CVE-2026-59774 จัดระดับวิกฤตด้วยคะแนน CVSS 9.8 และได้รับคำแนะนำด้านความปลอดภัยอย่างเป็นทางการเมื่อวันที่ 2 สิงหาคม 2569 โดยกระทบเวอร์ชัน 1.22.1 ไปจนถึง 1.27.0 และแก้ไขแล้วในเวอร์ชัน 1.27.1

เงื่อนไขการโจมตีต่ำผิดปกติ คือไม่ต้องล็อกอิน ไม่ต้องมีสิทธิ์เขียน repository ขอเพียงมี repository สาธารณะอยู่บนระบบและส่ง Org-mode markup ที่ประดิษฐ์ขึ้นไปยัง endpoint ที่ใช้เรนเดอร์ข้อความก็เพียงพอ ทางโครงการระบุว่าอินสแตนซ์บน Gitea Cloud จะถูกอัปเกรดให้อัตโนมัติในช่วงหน้าต่างบำรุงรักษาของการปล่อยเวอร์ชัน ส่วนผู้ดูแลระบบที่ติดตั้งเองต้องอัปเกรดเป็น 1.27.1 ทันที ทั้งนี้เวอร์ชัน 1.27.1 เป็นตัวเดียวกับที่ปิดช่องโหว่รันโค้ดระยะไกล CVE-2026-60004 ที่ Cloud Thunder เคยรายงานไว้แล้ว หมายความว่าใครที่อัปเดตตามข่าวก่อนหน้านี้ก็ได้แพตช์ตัวนี้ไปพร้อมกัน

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 5 สิงหาคม 2569 ว่า มีการเปิดเผยช่องโหว่อ่านไฟล์บนเซิร์ฟเวอร์ใน Gitea ที่ผู้โจมตีไม่ต้องมีบัญชีใดๆ ก็ใช้งานได้ โดยจุดสำคัญที่ต้องแยกให้ชัดคือช่องโหว่นี้ไม่ใช่การรันโค้ดระยะไกลแบบยิงคำสั่งเดียวจบ ทาง Gitea ระบุว่ามันสามารถ กลายเป็น การรันคำสั่งได้ หากผู้โจมตีอ่านไฟล์ app.ini ออกมาแล้วดึงค่า INTERNAL_TOKEN ไปแทรก Git hook ผ่านตัวบันทึกล็อกภายใน แล้วกระตุ้นให้ hook นั้นทำงานระหว่างการ clone แบบไม่ระบุตัวตน อย่างไรก็ตาม ห่วงโซ่การโจมตีนี้ถูกอธิบายไว้ในคำแนะนำของ Gitea เท่านั้น และ The Hacker News ระบุว่าไม่พบโค้ดสาธิตจากภายนอกที่เผยแพร่ต่อสาธารณะเพื่อยืนยันว่าทำได้จริง

Gitea ระบุในคำแนะนำว่ายังไม่พบการโจมตีในธรรมชาติ และ ณ วันที่ 5 สิงหาคม 2569 CVE-2026-59774 ยังไม่ปรากฏในแคตตาล็อก Known Exploited Vulnerabilities ของ CISA แต่มีข้อเท็จจริงที่ควรรับรู้คือความสามารถในการอ่านไฟล์นี้ถูกเปิดเผยต่อสาธารณะบางส่วนก่อนที่คำแนะนำอย่างเป็นทางการจะออก ซึ่งหมายความว่าช่วงเวลาที่ผู้โจมตีอาจรู้ก่อนผู้ดูแลระบบนั้นมีอยู่จริง ส่วนห่วงโซ่จากโทเค็นไปสู่การรันคำสั่งนั้นยังมีแหล่งข้อมูลเดียวคือคำแนะนำของ Gitea เอง

ผู้ค้นพบช่องโหว่คือ XBOW Security ซึ่งเป็นระบบทดสอบเจาะระบบเชิงรุกแบบอัตโนมัติ และผ่านการตรวจสอบเบื้องต้นโดยนาย Guido Leo ขณะเดียวกันนาย Shai Rod นักวิจัยที่ใช้ชื่อออนไลน์ว่า NightRang3r ก็รายงานปัญหาเดียวกันเข้ามาอย่างเป็นอิสระด้วย ซึ่งนาย Shai Rod คือคนเดียวกับที่รายงานช่องโหว่ RCE CVE-2026-60004 ก่อนหน้านี้ (2026/07/298 )

ช่องโหว่ตัวนี้เกิดขึ้นในช่วงที่ Gitea มีงานด้านความปลอดภัยหนาแน่นต่อเนื่อง ก่อนหน้านี้ในเดือนมิถุนายน Gitea แก้ช่องโหว่ข้ามการยืนยันตัวตนผ่าน reverse proxy ในอิมเมจ Docker (CVE-2026-20896) ซึ่งพบผู้โจมตีเริ่มสำรวจหาระบบที่มีช่องโหว่หลังเปิดเผยเพียง 13 วัน (2026/07/077 ) และในเดือนพฤษภาคมมีช่องโหว่การควบคุมสิทธิ์ใน container registry (CVE-2026-27771) ที่ประเมินว่ากระทบการติดตั้งมากกว่า 30,000 แห่งในกว่า 30 ประเทศ (2026/05/071 )

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

เส้นทางการอ่านไฟล์วิ่งผ่าน endpoint ที่ Gitea ใช้เรนเดอร์ markup คือ POST /{owner}/{repo}/markup โดยเส้นทางนี้อนุญาตให้ล็อกอินหรือไม่ก็ได้ จากนั้นจะระบุ repository และตรวจสิทธิ์ระดับผู้อ่าน ซึ่งคำขอแบบไม่ระบุตัวตนจะผ่านการตรวจนี้ได้ทันทีหากยิงไปที่ repository สาธารณะที่เปิดหน่วยแสดงโค้ดไว้ เงื่อนไขข้อนี้เป็นตัวจำกัดความเสี่ยงที่สำคัญ นั่นคืออินสแตนซ์ที่ไม่มี repository สาธารณะเลยจะไม่มีช่องทางโจมตีแบบไม่ระบุตัวตนผ่าน endpoint นี้

จุดที่พังจริงอยู่ที่ตัวเรนเดอร์ Org-mode ของ Gitea โดยเวอร์ชัน 1.27.0 เรียกใช้ไลบรารี go-org ด้วยคำสั่ง org.New() แต่ไม่ได้เขียนทับ callback ชื่อ ReadFile ที่เป็นค่าเริ่มต้นของไลบรารี ซึ่งใน go-org เวอร์ชัน 1.9.1 callback ดังกล่าวคือ ioutil.ReadFile ตรงๆ ขณะเดียวกันไวยากรณ์ Org-mode มีคำสั่ง #+INCLUDE ที่รับพาธแบบสัมบูรณ์ได้และส่งต่อพาธนั้นเข้า callback ผลคือผู้โจมตีเพียงส่ง Org-mode markup ที่เลือกโหมด Mode: file ก็จะได้เนื้อหาไฟล์ใดก็ตามที่บัญชีระบบของ Gitea อ่านได้กลับมา

การแก้ไขอยู่ใน PR #38642 และถูก backport ผ่าน PR #38645 โดย Gitea เขียนทับ ReadFile เสียใหม่ให้พาธที่ระบุใน #+INCLUDE ถูกส่งกลับเป็นเนื้อหาที่เรนเดอร์ตามปกติ แทนที่จะไปอ่านจากระบบไฟล์ของเซิร์ฟเวอร์จริง พร้อมเพิ่มการทดสอบถดถอยสำหรับการเรนเดอร์พาธ include เข้าไปด้วย

ในด้านการตรวจจับ Gitea ไม่ได้เผยแพร่แนวทางอย่างเป็นทางการไว้ในคำแนะนำ สิ่งที่ผู้ดูแลระบบทำได้คือย้อนดูคำขอ POST แบบไม่ระบุตัวตนที่ยิงเข้า /{owner}/{repo}/markup โดยเฉพาะคำขอที่เลือกเรนเดอร์แบบ Org-mode หรือส่งพาธระบบไฟล์แบบสัมบูรณ์เข้ามา และหากสงสัยว่ามีการพยายามยกระดับตามห่วงโซ่ที่คำแนะนำอธิบายไว้ ให้ตรวจไดเรกทอรี hook ของ repository ว่ามีไฟล์ปฏิบัติการแปลกปลอมหรือไม่

ผลกระทบ

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

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

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

คำแนะนำ

อัปเกรด Gitea เป็นเวอร์ชัน 1.27.1 ทันทีสำหรับทุกอินสแตนซ์ที่ติดตั้งเอง ส่วนผู้ใช้ Gitea Cloud ให้ตรวจยืนยันว่าอินสแตนซ์ได้รับการอัปเกรดในหน้าต่างบำรุงรักษาแล้วจริง

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

หากพบร่องรอยการเข้าถึง ให้ออกข้อมูลรับรองใหม่ทั้งชุดก่อนถือว่าระบบสะอาด ได้แก่ INTERNAL_TOKEN วัตถุที่เกี่ยวข้องกับ OAuth คีย์ที่ใช้ลงลายมือชื่อ JWT และข้อมูลรับรองฐานข้อมูล พร้อมตรวจไดเรกทอรี hook ของทุก repository ว่ามีสคริปต์ที่ไม่ได้ตั้งใจสร้างขึ้นหรือไม่

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

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