Argo CD repo server'ında dört kritik açık; üçünde CVE numarası yok

CVE akışlarının büyük kısmında görünmeyen kritik düzeltme dalgası

7 Ekim 2026'da Argo CD projesi tek bir seferde altı güvenlik danışma belgesi yayınladı; dördü CVSS 9.9 ile kritik olarak derecelendirildi. dev.to üzerindeki bir güvenlik analizine göre yamalar v3.3.15, v3.4.10, v3.5.4 ve v3.6.0-rc2 sürümlerinde mevcut. CVE akışları üzerinden yükseltme önceliği belirleyenler için sorun yaratan kısım şu: yazım anında yalnızca bir açığın NVD kaydı var (CVE-2026-55797, GitHub tarafından 8.8 puanlandı), ikincisinin bir CVE tanımlayıcısı var ama NVD kaydı yok (CVE-2026-77459) ve 9.9 puanlı dört hatadan üçünün hiç CVE'si yok. dev.to yazarı, altı GitHub danışma belgesinden beşinin OSV veritabanında 404 döndürdüğünü de belirtiyor; yani tarayıcı tabanlı pipeline'lar bu sürümün yalnızca küçük bir kısmını yakalayabilirdi.

Ortak hedef repo server

Altı hatadan dördü argocd-repo-server üzerinde; bu bileşen Git içeriğini Kubernetes manifestolarına dönüştürür ve dolayısıyla kurulumdaki her deposunun Git, Helm ve OCI kimlik bilgilerini saklar. dev.to analizi, bir Application'ın sync yaptığı bir depoya commit erişiminden fazlasını gerektirmeyen üç saldırı yolu haritalıyor — bu, uygulama ekipleri, CI işleri ve giderek artan şekilde otonom agent'lar için sıradan bir izindir: 2018'deki v0.9.0'a kadar izlenebilen bir Jsonnet dosya okuma sorunu, v2.7.0'dan beri git fetch --upload-pack üzerinden istismar edilen bir Kustomize remote reference sorunu ve --enable-helm açıkken configHome aracılığıyla Helm plugin çalıştırma. Hepsi bir confused-deputy sorunu yaratıyor: tek bir namespace ile sınırlı bir geliştirici, tüm tenant'ların sırlarını elinde tutan bir sürece ulaşabiliyor; bu yüzden dört CVSS vektöründe de scope-change bileşeni yer alıyor.

SSH proxy URL'leri üzerinden komut enjeksiyonu

CVE-2026-55797 (GHSA-j6cw-g6p4-7hch, CWE-78) bir komut enjeksiyonu. SSH Git deposu bir proxy URL'si ile yapılandırıldığında, proxy host ve port bilgileri doğrulama yapılmadan bir SSH ProxyCommand içine kopyalanıyordu; bu yüzden shell metakarakterleri içeren bir host adı dışarı çıkıp repo server içinde kod çalıştırabiliyordu. v2.11.0'dan itibaren her sürüm etkileniyor; bu davranış Ocak 2024'te SOCKS5 proxy desteğiyle geldi. Tetiklemek için yalnızca depo veya kimlik bilgisi şablonu oluşturma yetkisi gerekiyor; bu, proje genelindeki depo izinlerini de kapsıyor. Düzeltme bir allowlist dayatıyor: socks5 veya socks5h şemaları, boş olmayan bir host, 1 ile 65535 arasında bir port ve yalnızca harfler, rakamlar, noktalar ve tirelerden oluşan host adları.

Hook atlatması çoklu kiracılığı zayıflatıyor

Paylaşımlı kurulumlar için CVE-2026-77459 (GHSA-fmxq-cgp8-87wp, CVSS 9.9, CWE-863) en sonuçları ağır olanı olabilir. Argo CD normalde kaynaklar oluşturulmadan önce bir Application'ın AppProject'ine uygunluğunu kontrol eder; ancak PreDelete ve PostDelete hook'ları bu doğrulamayı atlar ve hedef cluster'da Application Controller'ın kimlik bilgileriyle çalışır. Danışma belgesi, bu erişimin genellikle bir tenant'ın ClusterRoleBinding gibi cluster kapsamlı nesneler oluşturmasına yetecek kadar geniş olduğunu ve PostDelete yolunun v2.10.0'dan beri proje denetimini hiç uygulamadığını belirtiyor.

Hâlâ yamalanmamış, kimlik doğrulaması gerektirmeyen bir RCE

Ayrı olarak, 1 Temmuz 2026'da kamuoyuna duyurulan bir repo-server açığının hâlâ düzeltmesi yok. Synacktiv araştırmacıları Octopus Trap adını verdikleri, kimlik doğrulaması gerektirmeyen bir uzaktan kod çalıştırmayı gösterdi: repo server'ın dahili gRPC servisi çağıranları doğrulamıyor, bu yüzden hazırlanmış bir GenerateManifest isteği Kustomize seçenekleri olan --enable-helm ve --helm-command'ı saldırganın deposunda barındırılan bir script'e yönlendirebiliyor. Porta erişebilen herkes bir shell elde ediyor; The Hacker News bu açığın cluster ele geçirmeyi mümkün kılabileceğini bildirdi. Synacktiv, hatayı Ocak 2025'te açıkladığını ve yaklaşık 18 aydır açık kaldığını söylüyor. Kod çalıştırma elde ettikten sonra bir saldırgan ortamdan Redis parolasını okuyabilir, manifest önbelleğini zehirleyebilir ve Application Controller'ın bir sonraki sync'te saldırgan kontrollü işi dağıtmasını sağlayabilir — CVE-2024-31989'un bir tekrarı. Resmi Helm chart networkPolicy.create değerini false olarak gönderdiği için, Helm tabanlı birçok kurulumda repo server veya Redis çevresinde bir ağ sınırı yok.

Operatörlerin şimdi yapması gerekenler

dev.to analizi, imzalı sürüm artefaktlarıyla (Cosign, SLSA Level 3) v3.3.15, v3.4.10 veya v3.5.4'e yükseltmeyi öneriyor; Argo CD 2.x ile 3.0'dan 3.2'ye kadar sürümlerin destek dışı olduğunu ve bu yamaları hiçbir zaman almayacağını belirtiyor. Operatörler, yalnızca Argo CD'nin kendi bileşenlerinin repo server ve Redis'e erişebilmesi için NetworkPolicy'leri etkinleştirmeli, güvenilmeyen kullanıcılara depo oluşturma veya güncelleme hakları vermemeli ve repo server'da beklenmeyen shell'ler ile Git clone'lar, açıklanamayan Redis erişimi ve eşleşen bir commit olmayan sync'ler için tetikte olmalı.

Neden önemli

Argo CD, Kubernetes GitOps'unun yük hayvanı — 2023 Argo topluluk anketindeki katılımcıların yüzde 93'ü onu üretimde çalıştırdığını söyledi. Bu olay, güvenilmeyen depo içeriğini ayrıştırırken tüm tenant'ların kimlik bilgilerini elinde tutan repo server bileşeninin tier-zero muamelesi görmeyi hak ettiğini ve şiddet ile tarayıcı görünürlüğünün birbiriyle ilgisiz olduğunu gösteriyor: en tehlikeli dört hatadan üçü CVE tabanlı araçlara görünmez ve bilinen, kimlik doğrulaması gerektirmeyen bir RCE hâlâ bir düzeltme bekliyor. Ağ yalıtımı ve en az ayrıcalıklı depo erişimi, bir CVE numarası hiç gelmese bile ayakta kalan savunmalardır.