Argo CD tồn tại lỗ hổng chưa vá, nguy cơ chiếm quyền toàn bộ Kubernetes

Các nhà nghiên cứu tại Synacktiv vừa công bố một lỗ hổng chưa được vá trong Argo CD (nền tảng GitOps phổ biến được sử dụng để tự động triển khai ứng dụng lên Kubernetes). Điều đáng chú ý là lỗ hổng này chưa được cấp mã CVE, cũng chưa có bản vá chính thức, mặc dù đã được báo cáo cho nhóm phát triển từ tháng 01/2025.
​

Theo Synacktiv, nếu kẻ tấn công có thể truy cập đến thành phần repo-server trong mạng nội bộ của cụm Kubernetes, chúng có thể thực thi mã tùy ý mà không cần xác thực, từ đó tiến tới chiếm quyền kiểm soát toàn bộ Kubernetes Cluster. Mặc dù điều kiện khai thác yêu cầu quyền truy cập vào mạng nội bộ của cụm, các chuyên gia cảnh báo đây vẫn là một rủi ro nghiêm trọng, đặc biệt đối với những hệ thống Argo CD được triển khai với cấu hình mặc định hoặc chưa kích hoạt các chính sách cô lập mạng.​

Argo CD là gì và vì sao lỗ hổng này đáng lo ngại?​

Argo CD là một công cụ GitOps mã nguồn mở được sử dụng rộng rãi để quản lý và tự động triển khai ứng dụng trên Kubernetes. Thay vì cấu hình trực tiếp trên máy chủ, Argo CD sẽ theo dõi các kho mã nguồn Git, đọc các tệp cấu hình Kubernetes (Manifest) và tự động đồng bộ chúng với trạng thái của cụm Kubernetes.

Nhờ khả năng quản lý tập trung và tự động hóa triển khai, Argo CD được nhiều doanh nghiệp sử dụng trong môi trường DevOps, Cloud Native và Kubernetes. Tuy nhiên, chính việc nắm giữ quyền triển khai ứng dụng, thông tin truy cập kho mã nguồn và quyền tương tác với Kubernetes cũng khiến Argo CD trở thành mục tiêu hấp dẫn đối với tin tặc.​

Lỗ hổng nằm ở đâu?​

Lỗ hổng được phát hiện trong repo-server, một thành phần quan trọng của Argo CD chịu trách nhiệm đọc dữ liệu từ các kho Git và chuyển đổi chúng thành các tệp Manifest để Kubernetes triển khai.

Theo Synacktiv, dịch vụ gRPC nội bộ của repo-server không yêu cầu xác thực. Điều này đồng nghĩa nếu kẻ tấn công có thể kết nối tới cổng dịch vụ này trong mạng nội bộ, chúng có thể gửi các yêu cầu đặc biệt nhằm buộc repo-server thực thi các lệnh tùy ý trên hệ thống.

Nhóm nghiên cứu đã xác nhận lỗ hổng có thể khai thác trên Argo CD phiên bản 2.13.3. Tuy nhiên, do chưa có bản vá, phạm vi ảnh hưởng có thể rộng hơn và hiện chưa có danh sách đầy đủ các phiên bản bị tác động.​

Nguyên nhân của lỗ hổng​

Về bản chất, lỗ hổng không xuất phát từ Kubernetes mà đến từ cách Argo CD sử dụng Kustomize, công cụ chuẩn dùng để xây dựng các tệp cấu hình Kubernetes.

Trong quá trình tạo Manifest, Kustomize hỗ trợ tham số –helm-command, cho phép chỉ định chương trình Helm sẽ được gọi để xử lý các biểu đồ Helm.

Synacktiv phát hiện rằng thông qua dịch vụ GenerateManifest của repo-server, kẻ tấn công có thể thay đổi tham số này và trỏ nó đến một tập lệnh (script) do chúng kiểm soát trong một kho Git độc hại.

Khi Kustomize thực thi, thay vì gọi chương trình Helm hợp lệ, hệ thống sẽ chạy trực tiếp tập lệnh của kẻ tấn công, từ đó dẫn đến thực thi mã tùy ý trên repo-server.​

Quá trình khai thác diễn ra như thế nào?​

Theo Synacktiv, chuỗi tấn công có thể diễn ra theo các bước sau:​

Sau khi có quyền trên repo-server, cuộc tấn công không dừng lại ở đó. Nhóm nghiên cứu tiếp tục chứng minh có thể đọc mật khẩu Redis được lưu trong biến môi trường của Argo CD, sử dụng mật khẩu này để truy cập Redis và sửa đổi dữ liệu triển khai ứng dụng.

Khi Argo CD thực hiện chu kỳ đồng bộ tiếp theo, hệ thống sẽ tự động triển khai khối lượng công việc (Workload) do kẻ tấn công tạo ra, giúp chúng giành quyền kiểm soát toàn bộ cụm Kubernetes.​

Lỗ hổng còn “hồi sinh” một CVE đã được vá trước đây​

Một điểm đáng chú ý là cuộc tấn công này còn làm sống lại CVE-2024-31989. Trước đó, năm 2024, các nhà nghiên cứu của Cycode phát hiện Redis của Argo CD không sử dụng mật khẩu, cho phép bất kỳ Pod nào cũng có thể sửa đổi bộ nhớ đệm triển khai ứng dụng. Argo CD đã khắc phục bằng cách bổ sung mật khẩu cho Redis.

Tuy nhiên, Synacktiv chỉ ra rằng bộ nhớ đệm Redis vẫn chưa được ký hoặc xác thực tính toàn vẹn. Khi chiếm được repo-server, tin tặc có thể lấy lại mật khẩu Redis từ biến môi trường, sau đó tiếp tục thao túng dữ liệu trong bộ nhớ đệm và tái sử dụng kỹ thuật tấn công của CVE-2024-31989.

Điều này cho thấy việc khắc phục từng lỗ hổng riêng lẻ chưa đủ nếu kiến trúc bảo mật tổng thể vẫn còn tồn tại các điểm yếu có thể kết hợp thành chuỗi khai thác.​

Vì sao lỗ hổng này đặc biệt nguy hiểm?​

Thoạt nhìn, nhiều người có thể cho rằng đây chỉ là một lỗ hổng trong mạng nội bộ. Tuy nhiên, Synacktiv cho biết trên thực tế, nhiều hệ thống Argo CD được triển khai thông qua Helm Chart với cấu hình mặc định, trong đó tùy chọn networkPolicy.create được đặt là false. Điều này đồng nghĩa các chính sách cô lập mạng của Kubernetes không được kích hoạt.

Nếu một Pod bất kỳ trong cụm Kubernetes bị xâm nhập, kẻ tấn công hoàn toàn có thể kết nối đến repo-server và Redis để khai thác lỗ hổng. Trong các môi trường Kubernetes nhiều ứng dụng hoặc nhiều nhóm phát triển cùng sử dụng chung một cụm, nguy cơ này càng trở nên đáng lo ngại vì chỉ cần một ứng dụng bị xâm nhập cũng có thể trở thành bàn đạp để tấn công toàn bộ hạ tầng.​

Argo CD tiếp tục đối mặt với nhiều lỗ hổng liên quan đến dữ liệu nhạy cảm​

Đây không phải lần đầu Argo CD xuất hiện các lỗ hổng nghiêm trọng.Tháng 9/2025, dự án đã vá CVE-2025-55190, cho phép người dùng chỉ có quyền đọc lấy được thông tin xác thực của kho Git.

Đến tháng 5/2026, CVE-2026-42880 tiếp tục cho phép người dùng chỉ có quyền đọc truy cập vào các Kubernetes Secret dưới dạng văn bản thuần (plaintext).

Theo Synacktiv, điểm chung của các lỗ hổng này là đều liên quan đến những thành phần lưu trữ các thông tin có giá trị như khóa truy cập Git, bí mật Kubernetes hoặc quyền triển khai ứng dụng. Điều đó cho thấy các bề mặt tấn công nội bộ của Argo CD đang trở thành mục tiêu hấp dẫn đối với tin tặc.​

Hiện đã có bản vá hay chưa?​

Tính đến thời điểm công bố, Argo CD vẫn chưa phát hành bản vá chính thức và lỗ hổng cũng chưa được cấp mã CVE.

Để giúp cộng đồng đánh giá mức độ ảnh hưởng, Synacktiv đã phát triển công cụ argo-cdown, có khả năng tự động hóa toàn bộ chuỗi khai thác. Tuy nhiên, nhóm nghiên cứu cho biết sẽ tạm thời chưa công bố mã nguồn nhằm tạo thêm thời gian để các tổ chức triển khai các biện pháp phòng vệ trước khi công cụ được phát hành trên GitHub.​

Chuyên gia khuyến nghị gì?​

Trong khi chờ bản vá chính thức, các chuyên gia khuyến nghị quản trị viên:​