git clone --recursive kod çalıştırabilir: Git 2.56.1 ile kapatılan altı açık ve CI hattınız için yapılacaklar

Çoğumuz için git clone bir komuttan çok refleks. Bir kütüphaneyi incelemek, bir PR'ı yerelde denemek ya da CI'da projeyi derlemek için hiç düşünmeden çalıştırırız. 10 Kasım 2026'da Git projesinin duyurduğu güvenlik güncellemesi bu refleksi bir süreliğine sorgulamamız gerektiğini gösteriyor: Submodule'lerle birlikte yapılan bir klonlama, depo kötü niyetliyse saldırganın kodunu sizin makinenizde çalıştırabiliyor.

Güncelleme tek bir açığı değil, altı ayrı sorunu kapatıyor. Aşağıda neyin değiştiğini, hangi senaryoların gerçekten risk taşıdığını ve özellikle CI/CD tarafında neleri kontrol etmeniz gerektiğini özetliyorum.

Ne oldu?

Git 2.56.1 yayımlandı; aynı düzeltmeler 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 ve 2.50.2 bakım sürümlerine de taşındı. GitHub, github.com ve GitHub Enterprise Cloud tarafındaki düzeltmeleri devreye aldığını, GitHub Enterprise Server için ise 3.19.15, 3.20.11, 3.21.9 ve 3.22.4 sürümlerini yayımladığını duyurdu. GitHub Desktop, Copilot uygulaması, Codespaces ve Actions da güncellenen Git'i alacak.

Duyuruda açıkların sahada istismar edildiğine dair bir bilgi yok. Ama ayrıntılar artık herkese açık; bu tür açıklarda yama yayımlandıktan sonra çalışan bir istismar ortaya çıkması genellikle uzun sürmüyor.

Asıl mesele: CVE-2026-111760

En dikkat çeken açık, Git'in index'i işlerken yaptığı bir tamsayı kırpmasından (integer truncation) kaynaklanıyor. Mekanizma kabaca şöyle:

1. Saldırgan depoya aşırı uzun bir yol (path) yerleştiriyor.
2. Git bu yolu güvenlik kontrolünden uzun hâliyle geçiriyor; kontrol yolu zararsız buluyor.
3. Diske yazarken ise uzunluk bilgisi kırpıldığı için dosya çok daha kısa bir adla oluşuyor. Saldırgan bu kısa adı .git olacak şekilde ayarlayabiliyor.
4. Böylece bir submodule'ün .git dosyası, saldırganın hazırladığı hook'ları ya da config'i içeren bir dizine işaret eden symlink ile değiştiriliyor.
5. Git o dizini kullandığı anda saldırganın hook'u çalışıyor.

Buradaki ders, Git'e özgü olmanın ötesinde: Bir değeri bir biçimde doğrulayıp başka bir biçimde kullanmak, güvenlik kontrollerini atlatmanın klasik yollarından biri. Düzeltme de bunu yansıtıyor; yamalı sürümler aşırı uzun index yollarını kırpma gerçekleşmeden reddediyor.

Kritik koşul şu: İstismar için kötü niyetli bir deponun submodule'leriyle birlikte, yani recursive olarak klonlanması gerekiyor. Yani şu komutlar risk altında:

git clone --recurse-submodules <depo>
git submodule update --init --recursive

Düz bir git clone bu açık için tetikleyici değil. Ama birçok araç ve CI adımı submodule'leri sizin yerinize, siz fark etmeden başlatabiliyor.

Diğer beş açık

Aynı sürümde kapatılan diğer sorunlar daha çok sunucu ve barındırma servislerini ilgilendiriyor:

• CVE-2026-113408: Boş bir depo protocol v2 üzerinden klonlanırken sunucunun bildirdiği HEAD hedefi doğrulanmıyordu. Kötü niyetli bir sunucu path traversal içeren bir ad gönderirse, files referans backend'inde sonraki bir dal güncellemesi refs dizininin dışına yazabiliyor.
• CVE-2026-105437: Çok sayıda çakışma ve büyük bir conflict-marker-size değeri içeren merge'lerde bellek hesabı taşıyor ve heap bozulması oluşuyor. The Hacker News'e göre bu CVE'yi GitLab atadı ve en olası hedef git merge-tree çalıştıran kod barındırma sunucuları.
• CVE-2026-114467: İkiden fazla GPG imzası içeren bir tag'i merge etmek stack bozulmasına ve hizmet kesintisine yol açabiliyor.
• CVE-2026-114469: Sıkıştırılmış bir binary patch, Git'in yaklaşık 1 GiB'lık sınırını aşacak kadar açılabiliyor ve sınır dışı okuma ile çökmeye sebep oluyor.
• CVE-2026-114466: git fast-import'un üç özelliği (rewrite-submodules-from, rewrite-submodules-to, export-pack-edges) güvenilmeyen girdide keyfi dosya okumaya ya da dosya oluşturmaya izin veriyordu. Artık --allow-unsafe-features verilmedikçe reddediliyorlar.

Kendi Gitea, GitLab ya da benzeri bir sunucu işletiyorsanız, merge işlemlerini kullanıcı adına yapan her servis bu listeyle doğrudan ilgili.

Neden önemli?

Git artık yalnızca geliştiricinin terminalinde çalışan bir araç değil. IDE'lerin, masaüstü istemcilerinin, paket yöneticilerinin, CI runner'larının ve son dönemde kod ajanlarının içinde de çalışıyor. Bu da üç pratik sonuç doğuruyor:

• "Sistemdeki Git" tek bir Git değil. İşletim sistemi paketini güncellemek, IDE'nizin ya da masaüstü istemcinizin kendi içinde taşıdığı Git kopyasını güncellemiyor. Hem GitHub hem de The Hacker News, kendi Git kopyasını paketleyen uygulamaların ayrıca güncellenmesi gerektiğini vurguluyor. The Hacker News'in kontrol ettiği sırada Git for Windows'un 2.56.1 tabanlı sürümü henüz yayımlanmamıştı; Windows kullanıyorsanız bunu takip edin.
• CI, en geniş saldırı yüzeyi. Fork'lardan gelen PR'ları derleyen bir pipeline, tanımı gereği güvenilmeyen depoyu işliyor. Runner'da deploy anahtarları ya da geniş yetkili token'lar varsa, klonlama aşamasında çalışan bir hook bunlara erişebilir.
• Kod ajanları yeni bir tetikleyici. Bir ajana "şu depoyu incele" dediğinizde, ajan submodule'leri başlatmak için recursive bir komut çalıştırabilir. Ajanın çalıştığı ortamdaki Git sürümü de artık envanterinizin parçası olmalı.

Pratikte ne yapmalı?

1. Her ortamdaki Git sürümünü kontrol edin. Yalnızca dizüstü bilgisayarınızda değil; CI imajlarında, Docker base image'larında, self-hosted runner'larda ve sunucularda:

git --version

Sonucun 2.56.1 ya da kendi serinizin yamalı sürümü (örneğin 2.55.1, 2.51.3, 2.50.2) olması gerekiyor. Dağıtımınızın paketlediği sürümde yamanın geri taşınıp taşınmadığını dağıtımın güvenlik duyurusundan doğrulayın; sürüm numarası tek başına yanıltıcı olabilir.

2. Recursive submodule kullanımını envanterleyin. Script'lerinizde ve pipeline tanımlarınızda --recurse-submodules ve --recursive geçen yerleri arayın. GitHub Actions'ta actions/checkout için submodules: recursive, GitLab CI'da GIT_SUBMODULE_STRATEGY: recursive ayarlarına bakın. Gerçekten gerekmiyorsa kapatın.

3. Güvenilmeyen depoları adım adım açın. Yamayı hemen uygulayamıyorsanız önce düz klonlayın, .gitmodules dosyasında submodule kaynaklarının beklediğiniz yerler olduğunu kontrol edin, sonra submodule'leri başlatın.

4. CI'da yetkileri ayırın. Yalnızca derleme ve test yapan işlerde gizli anahtar tutmayın, mümkünse geçici (ephemeral) runner kullanın ve deploy yetkisini ayrı bir işe taşıyın. Bu, bu açıktan bağımsız olarak iyi bir alışkanlık; bir sonraki benzer açıkta da etkiyi sınırlar.

5. Sunucu tarafında geçici önlem. CVE-2026-105437 için yama yapılana kadar her deponun info/attributes dosyasına conflict-marker-size=7 eklemek ya da güvenilmeyen depolarda merge kontrollerini kapatmak öneriliyor. Bunlar yamanın yerini tutmuyor, yalnızca aradaki süreyi kapatıyor.

Son söz

Bu güncellemede panik gerektiren bir durum yok; bilinen bir istismar raporu yok ve en kritik açık belirli bir koşul gerektiriyor. Ama o koşul, yani submodule'leriyle birlikte yapılan klonlama, CI hatlarında ve otomasyonda sandığımızdan daha sık karşımıza çıkıyor. Bu haftayı, ekipteki her makinede, imajda ve araçta hangi Git sürümünün çalıştığını bir kez netleştirmek için fırsat olarak kullanmak bence en mantıklısı.