สรุปสั้น
Argo CD เครื่องมือยอดนิยมสำหรับ deploy ซอฟต์แวร์ลง Kubernetes มีช่องโหว่ที่ยังไม่ได้รับการแก้ไขในคอมโพเนนต์ repo-server ซึ่งเปิดทางให้ผู้โจมตีที่ไม่ต้องยืนยันตัวตน (unauthenticated) สามารถรันโค้ดได้ ขอเพียงเข้าถึงพอร์ตภายในเครือข่ายของคอมโพเนนต์นั้น บริษัท Synacktiv ผู้ค้นพบช่องโหว่ ระบุว่ามันนำไปสู่การยึดครอง cluster ได้ทั้งระบบ และที่น่ากังวลคือขณะนี้ยังไม่มีแพตช์และไม่มีรหัส CVE โดยบริษัทระบุว่าได้แจ้งช่องโหว่นี้ต่อผู้ดูแล Argo CD ตั้งแต่เดือนมกราคม 2025 แต่ผ่านไปราว 18 เดือนก็ยังไม่ได้รับการแก้ไข จึงตัดสินใจเผยแพร่รายละเอียดเพื่อเตือนผู้ใช้
จุดอันตรายเป็นพิเศษคือ Argo CD มาพร้อม Kubernetes network policy ที่กั้น repo-server ออกจากทุกอย่างยกเว้นคอมโพเนนต์ของตัวเอง แต่ Synacktiv พบว่า Helm chart ซึ่งเป็นวิธีติดตั้งที่นิยม กลับปิด network policy นี้ไว้เป็นค่าเริ่มต้น (networkPolicy.create ตั้งเป็น false) ในกรณีเช่นนี้ ผู้โจมตีที่ยึดพอดเพียงพอดเดียวใน cluster ได้ ก็สามารถเข้าถึง repo-server และกระตุ้นช่องโหว่ได้ เนื่องจากไม่มีแพตช์ ทางป้องกันเดียวในตอนนี้คือการทำ network isolation ให้เข้มงวด
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 2 กรกฎาคม 2026 ว่า บริษัท Synacktiv ค้นพบช่องโหว่ในคอมโพเนนต์ repo-server ของ Argo CD ซึ่งเป็นเครื่องมือ GitOps ที่ใช้กันอย่างแพร่หลายในการ deploy ซอฟต์แวร์ลง Kubernetes ช่องโหว่นี้อยู่ในส่วน repo-server ซึ่งเป็นคอมโพเนนต์ที่ทำหน้าที่อ่าน Git repository และสร้าง Kubernetes manifest หรือไฟล์ที่กำหนดว่า cluster จะ deploy อะไรบ้าง
ปัญหาคือบริการ gRPC ภายในของ repo-server ไม่มีการยืนยันตัวตนเลย ใครก็ตามที่เข้าถึงได้ก็สามารถส่งคำขอที่ประดิษฐ์ขึ้นเพื่อสั่งรันคำสั่งได้ Synacktiv สาธิตการโจมตีบน Argo CD v2.13.3 และรายงานว่าไม่มีเวอร์ชันใดที่ได้รับการแก้ไขแล้ว โดยไม่ได้เผยแพร่รายการเวอร์ชันที่ได้รับผลกระทบทั้งหมด บริษัทระบุว่าได้รายงานช่องโหว่นี้ต่อผู้ดูแล Argo CD ตั้งแต่เดือนมกราคม 2025 แต่ราว 18 เดือนผ่านไปก็ยังไม่ได้รับการแก้ไข จึงเลือกเปิดเผยรายละเอียดเพื่อเตือนผู้ใช้ให้ป้องกันตัวเอง
Synacktiv ยังได้พัฒนาเครื่องมือชื่อ argo-cdown ที่ทำการโจมตีทั้งกระบวนการโดยอัตโนมัติ แต่ยังชะลอการปล่อยเครื่องมือไว้ก่อนเพื่อให้ฝ่ายป้องกันมีเวลาล็อกดาวน์ network policy ของตน และระบุว่าจะเผยแพร่บน GitHub ในภายหลังเพื่อให้ผู้ดูแลระบบทดสอบระบบของตนเองได้
รายละเอียดช่องโหว่
เทคนิคการโจมตีอาศัยการใช้ประโยชน์จาก kustomize ซึ่งเป็นเครื่องมือมาตรฐานที่ Argo CD เรียกใช้เพื่อแปลงไฟล์ใน repository ให้เป็น manifest โดย kustomize มีออปชัน –helm-command ที่ระบุ path ของไบนารี helm ที่ควรเรียกใช้ Synacktiv พบว่าคำขอที่ไม่ต้องยืนยันตัวตนไปยังบริการ GenerateManifest ของ repo-server สามารถตั้งค่าออปชันนี้ให้ชี้ไปยังสคริปต์แทนได้ โดยสคริปต์นั้นถูกดึงมาจาก Git repository ที่ผู้โจมตีควบคุม เมื่อ kustomize ทำงาน มันจึงรันสคริปต์นั้นแทนที่จะเป็น helm
การรันโค้ดบน repo-server ยังไม่ใช่จุดสิ้นสุด Synacktiv ใช้การเข้าถึงนั้นอ่านรหัสผ่าน Redis ของ cluster จากตัวแปรสภาพแวดล้อม (environment variable) แล้วเชื่อมต่อไปยัง Redis cache ของ Argo CD และวางยา (poison) ข้อมูลการ deploy ที่เก็บไว้ เมื่อถึงรอบ sync อัตโนมัติครั้งถัดไป Argo CD ก็จะ deploy เวิร์กโหลดที่ผู้โจมตีจัดเตรียมไว้ ขั้นตอนนี้ทำให้ช่องโหว่ CVE-2024-31989 ในปี 2024 กลับมามีชีวิตอีกครั้ง ซึ่งเดิม Cycode พบว่า Redis ของ Argo CD ไม่มีรหัสผ่าน ทำให้พอดใดก็ได้ใน cluster วางยา cache ได้ แม้ Argo CD จะแก้โดยเพิ่มรหัสผ่าน Redis แล้ว แต่ตัว cache เองยังไม่ได้เซ็นลายเซ็นดิจิทัล การขโมยรหัสผ่านกลับคืนมาจึงเปิดช่องการโจมตีเดิมได้อีก
ทั้งนี้ช่องโหว่ดังกล่าวไม่ใช่ครั้งแรกที่ Argo CD เปิดเผยส่วนภายในของตัวเอง ในเดือนกันยายน 2025 เคยแพตช์ CVE-2025-55190 ที่ token ระดับอ่านพื้นฐานสามารถดึงข้อมูลรับรอง (credential) ของ Git repository ในโปรเจกต์ออกมาได้ และในเดือนพฤษภาคม 2026 ยังมี CVE-2026-42880 ที่ผู้ใช้ระดับอ่านอย่างเดียวสามารถอ่าน Kubernetes secret แบบ plaintext ได้
ผลกระทบต่อไทย
Argo CD เป็นเครื่องมือหลักในสาย GitOps ที่องค์กรไทยซึ่งใช้ Kubernetes โดยเฉพาะกลุ่มธนาคาร ฟินเทค อีคอมเมิร์ซ และผู้ให้บริการคลาวด์ นำมาใช้จัดการการ deploy อย่างแพร่หลาย ความน่ากังวลคือช่องโหว่นี้ยังไม่มีแพตช์และไม่มี CVE อย่างเป็นทางการ ทำให้ทีมความปลอดภัยอาจมองข้ามได้ง่าย ยิ่งไปกว่านั้นการติดตั้งผ่าน Helm chart ซึ่งเป็นวิธีที่นิยมที่สุด กลับปิด network policy ไว้เป็นค่าเริ่มต้น หมายความว่าหลายองค์กรอาจอยู่ในสถานะเสี่ยงโดยไม่รู้ตัว หากผู้โจมตียึดพอดใดพอดหนึ่งใน cluster ได้ ก็อาจลุกลามไปยึด cluster ทั้งระบบ ซึ่งอาจกระทบต่อบริการที่ทำงานอยู่บนนั้นทั้งหมด ทีม DevOps และ platform ในไทยจึงควรเร่งตรวจสอบ network policy ของ Argo CD โดยด่วน
คำแนะนำ
เนื่องจากยังไม่มีเวอร์ชันที่แก้ไข ทางป้องกันคือการทำ network isolation เปิดใช้งาน Kubernetes network policy เพื่อให้เฉพาะคอมโพเนนต์ของ Argo CD เท่านั้นที่เข้าถึงพอร์ตของ repo-server และ Redis ได้ โดย Argo CD มีไฟล์ policy ให้อยู่แล้ว แต่ผู้ที่ติดตั้งผ่าน Helm ต้องเปิดใช้เองเพราะ chart ปิดไว้เป็นค่าเริ่มต้น ตรวจสอบสถานะที่ใช้งานอยู่ด้วยคำสั่ง kubectl get networkpolicy -A การติดตั้งที่ปลอดภัยควรมี network policy หนึ่งชุดต่อหนึ่งคอมโพเนนต์ รวมถึง repo-server และ Redis หากไม่พบ policy เหล่านี้ แสดงว่าพอร์ตของ repo-server และ Redis สามารถเข้าถึงได้จากส่วนอื่นของ cluster จนกว่าจะมีแพตช์ออกมา การปฏิบัติต่อเครือข่ายภายใน cluster เสมือนว่าเป็นพื้นที่ที่ไม่ปลอดภัย (treat the cluster network as hostile) คือแนวป้องกันที่แท้จริงเพียงอย่างเดียว