Michael JohnsonGit’i terminalde güncellediyseniz işiniz henüz bitmiş değil: bazı uygulamalar ve derleme ortamları kendi kopyalarını çalıştırabilir. Git projesi 10 Kasım 2026’da, özyinelemeli klonlama sırasında kod çalıştırılmasından birleştirme sırasında bellek bozulmasına kadar uzanan altı güvenlik açığı için düzeltmeler yayımladı. Bu nedenle yalnızca kabuğunuzdaki git --version komutunun sonucunu değil, depoları veya içeriklerini işleyen her ortamı kontrol etmeniz gerekir.
Güncellemeyle neler değişti
Düzeltmeler Git 2.56.1 sürümüne eklendi ve desteklenen dallara da aktarıldı: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 ve 2.50.2. Güncelleme Git’in yollar, bağlantılar, imzalar, ikili yamalar, birleştirmeler ve içe aktarma akışlarıyla ilgili farklı bölümlerindeki altı sorunu gideriyor. GitHub, 10 Kasım’da güvenlik açıklarına ilişkin incelemeyi ve güncelleme önerisini yayımladı; Git 2.56.1 sürüm notlarında bu seride düzeltilen CVE’ler listeleniyor.
Uygulamada Git’in kullanıldığı üç yeri güncellemeniz gerekir: iş bilgisayarları, otomasyon sistemleri ve kendi Git derlemesini içeren uygulamalar. Özellikle sonuncusu kolayca gözden kaçabilir: sistem paketini güncellemek, her istemcideki veya derleme imajındaki sürümü otomatik olarak değiştirmez.
Özyinelemeli clone neden önemli
En belirgin saldırı zinciri, güvenilmeyen bir depoyu özyinelemeli olarak klonlamakla başlıyor. Yol uzunluğunun kırpılması nedeniyle çok uzun bir girdi bir adla denetimden geçip daha sonra diske kısaltılmış biçimiyle yazılabiliyordu. Git’in açıkladığı senaryoda bu, alt modülün .git dosyasının, kötü amaçlı yapılandırma veya kancalar içeren bir dizine işaret eden sembolik bir bağlantıyla değiştirilmesine olanak tanıyordu. Git’e daha sonra başvurulduğunda saldırganın belirlediği kod çalıştırılabiliyordu.
Uygulamada bunun özel olarak hazırlanmış bir depo ve ilgili işlemi gerektirdiğini unutmamak gerekir. Dış kaynaklardan gelen projeleri düzenli olarak --recurse-submodules parametresiyle klonlayan ekipler, istemci ve otomasyon ortamlarını öncelikli olarak güncellemelidir. Düzeltme, aşırı uzun yolların uzunlukları kırpılmadan önce reddedilmesini sağlıyor.
Git’in güvenilmeyen verileri işlediği diğer noktalar
Bir başka sorun, Git protocol v2 kullanılarak boş bir depo klonlandığında ortaya çıkabiliyordu. Sunucu, dal adında dizin geçişi bileşenleri bulunan bir HEAD referansı gönderebiliyor; daha sonra dalı güncelleme işlemi, beklenen referanslar dizininin dışına dosya yazabiliyordu. Düzeltilen Git sürümleri bu hedefi ve protokol üzerinden alınan diğer referans adlarını denetliyor.
Birleştirme ve yamalarla ilgili işlemler de ayrı güvenlik açıklarından etkileniyordu. İmzalar işlenirken sabit boyutlu bir dizi en fazla iki imza varsayıyordu; çok sayıda imza içeren özel olarak hazırlanmış bir ileti, dizi sınırlarının dışına yazılmasına ve bellek bozulmasına yol açabiliyordu. İkili yama uygulanırken boyut denetimi, sıkıştırılmış verilerin çok daha büyük bir hacme açılabileceğini göz ardı ederek özgün gösterimi dikkate alıyordu. Git artık verileri işlemeden önce belirtilen sıkıştırılmamış boyutu denetliyor.
Büyük birleştirmeler de gerekli arabellek boyutu hesaplanırken taşmaya ve ardından sınırların dışına yazılmasına neden olabiliyordu. Bu durum, güvenilmeyen içerikleri birleştiren barındırma hizmetlerini ve uygulamaları da etkiliyor. Son olarak, git fast-import içindeki üç özellik, girdi akışından gelen komutlara ilişkin kısıtlamalar aldı: rewrite-submodules-from ve rewrite-submodules-to rastgele dosyaları okuyabiliyor, export-pack-edges ise dosya oluşturabiliyor veya mevcut dosyalara veri ekleyebiliyordu. Artık --allow-unsafe-features bayrağı açıkça belirtilmediği sürece bu özellikler engelleniyor; bu bayrak yalnızca güvenilir bir akış üreticisi için kullanılmalı.
Ayrı Git kopyalarını nerede aramalı
Geliştiriciler için başlangıç noktası, Git’in nerelerden çalıştırıldığını envantere almaktır. Terminaldeki sürümü kontrol edin ve IDE’ler ile masaüstü Git istemcilerinin yerleşik güncelleme denetimini kullanın. Ardından dış depolardan clone veya merge yapan, ikili yamalar uygulayan ya da fast-import çalıştıran CI imajlarını, kapsayıcıları, runner’ları ve sunucu görevlerini kontrol edin. Ana makinede güncel Git’in bulunması, uygulamanın gerçekten onu kullandığını garanti etmez.
Kuruluşlarda yalnızca kaynak imajları değil, hâlihazırda dağıtılmış çalışma ortamlarını da kontrol etmek yararlı olur: kalıcı bir runner veya kurum içi hizmet, temel imaj güncellendikten sonra eski ikili dosyayı kullanmaya devam etmiş olabilir. GitHub, GitHub Enterprise Server için düzeltilmiş sürümlerin 3.19.15, 3.20.11, 3.21.9 ve 3.22.4 olduğunu belirtiyor. Şirket, düzeltmeleri veri yerleşimi seçenekleri de dâhil olmak üzere github.com ve GitHub Enterprise Cloud’a dağıttığını bildirdi. Düzeltilmiş Git’i içeren GitHub Desktop ve GitHub Copilot app sürümleri üzerinde eşgüdümlü olarak çalışılıyor; Codespaces ve GitHub Actions için düzeltilmiş sürümlerin de yayımlanması bekleniyor.
Güncellemeden önce risk nasıl azaltılır
Düzeltmeyi hemen yükleyemiyorsanız, güvenilmeyen verilerle yapılan işlemleri geçici olarak kısıtlayın: depoları yalnızca güvenilir sunuculardan klonlayın, doğrulanmamış projeleri özyinelemeli olarak klonlamaktan kaçının, içeriklerini birleştirmeyin ve bu projelerden alınan ikili yamaları veya fast-import akışlarını uygulamayın. Bu önlemler, belirli savunmasız senaryolara maruz kalmayı azaltır ancak güncellemenin yerini tutmaz.
Temel çıkarım basit: Git düzeltmesini, programın Git’i gerçekten çalıştırdığı yerde aramak gerekir. Terminaldeki komut bu noktalardan yalnızca biridir; geliştirme istemcileri, CI sistemleri ve depo işleme hizmetleri ayrı ayrı kontrol edilmelidir.
