Git projesi 10 Kasım 2026’da, altı güvenlik açığını kapatan koordineli bir güvenlik sürümü yayımladı. En ciddisi CVE-2026-111760: kötü niyetli hazırlanmış bir depoyu alt modülleriyle birlikte “recursive” (özyinelemeli) klonlayan bir bilgisayarda saldırganın kodu çalışabiliyor. Düzeltme Git 2.56.1 ile geldi; eski dallar için de 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1 ve 2.55.1 sürümleri çıktı.

Haberi Junio C. Hamano’nun proje listesine gönderdiği duyuru, GitHub’ın aynı gün yayımladığı yazı ve The Hacker News’in 10 Kasım tarihli haberi üzerinden derledik. Yazının sonundaki kaynakçada üç kaynağın da bağlantısı var.

Bu açığı 30 saniyede izleyin:

Kısaca

  • Sürümler: Git 2.56.1 ve geriye dönük düzeltmeler (2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3, 2.50.2).
  • Ana açık: CVE-2026-111760. Çok uzun bir dosya yolu, Git’in güvenlik denetimini geçip diske daha kısa bir adla yazılabiliyor. Sonuçta alt modülün .git dosyası, kötü amaçlı ayar ya da “hook” içeren bir klasöre işaret eden bir sembolik bağa dönüşebiliyor.
  • Etki: Güvenilmeyen bir depoyu --recursive ile klonlayan kişinin bilgisayarında saldırgan kodu çalışabiliyor.
  • Aynı sürümlerle beş açık daha kapatıldı: CVE-2026-113408, CVE-2026-114466, CVE-2026-114467, CVE-2026-114469 ve CVE-2026-105437.
  • Keşif: Duyuruya göre açıkları Luke Martin ve pwn2addr buldu; düzeltmeleri Toon Claes, Karthik Nayak ve Kaartic Sivaraam yazdı.
  • İstismar: İncelediğimiz kaynaklarda bu açıkların gerçek saldırılarda kullanıldığına dair bir bilgi yok.

Sorun tam olarak nerede?

Git, bir depoyu klonlarken dosyaları çalışma klasörüne yazmadan önce yolları denetler. Bu denetimin görevlerinden biri, Git’in kendi üst verisinin tutulduğu .git alanının üzerine yazılmasını engellemek. GitHub’ın açıklamasına göre sorun, Git’in dizin (index) işleme kodundaki bir “tam sayı kırpılması”nda yatıyor. Aşırı uzun bir yol, denetimden bir adla geçiyor; ardından yazılırken uzunluk kırpıldığı için başka, daha kısa bir adla diske iniyor.

Alt modüller (submodule) bu açığın neden “klonlama anında” tehlikeli olduğunu açıklıyor. Git normalde bir .git klasörünün yerine sembolik bağ koymayı reddediyor. Ama yeni klonlanmış bir alt modülde .git bir klasör değil, küçük bir dosya. Açık, işte bu dosyanın sembolik bağla değiştirilmesine izin veriyor. Bağın gösterdiği klasörde kötü amaçlı bir ayar ya da “hook” varsa, Git o klasörü kullanmaya başladığında saldırganın hazırladığı kod çalışabiliyor. Hook’lar, Git’in belirli adımlarda kendiliğinden çalıştırdığı küçük programlar.

Burada saldırının adımlarını anlatmıyoruz; kaynaklardaki ayrıntı da bu düzeyde. Savunma açısından önemli olan şu: Zararlı kod, klonlanan deponun içindeki bir betik dosyasını sizin çalıştırmanıza bağlı değil. Klonlama işleminin kendisi yeterli olabiliyor. Düzeltme ise basit bir mantığa dayanıyor: Dizin kayıtlarındaki aşırı uzun yollar, uzunlukları kırpılmadan önce reddediliyor. Sürümler ayrıca ilgili bellek ayırma işlemlerine taşma denetimleri ekliyor.

Diğer beş açık

Aynı sürümler, günlük kullanımda daha az rastlanan ama sunucular için önemli beş açığı da düzeltiyor:

  • CVE-2026-113408: Boş bir depo Git protokol v2 ile klonlanırken kötü niyetli bir sunucu, yol aşırtma (path traversal) içeren bir dal adı gönderebiliyor. “Files” referans arka ucu kullanılıyorsa, o dala sonradan yapılan bir güncelleme Git’in referans klasörünün dışına yazabiliyor.
  • CVE-2026-114467: İkiden fazla GPG imzası taşıyan bir etiketi birleştirmek (merge) Git’in yığın belleğini bozuyor ve hizmet reddine yol açabiliyor. Kullanıcı adına bu tür birleştirmeleri yapan barındırma servisleri de etkilenebilir.
  • CVE-2026-114469: Çok büyük boyuta açılan ikili (binary) bir yama, yaklaşık 1 GiB’lık yama boyut sınırını aşıp Git’i çökertebiliyor (sınır dışı okuma).
  • CVE-2026-105437: Çok sayıda çakışması ve büyük bir “conflict-marker-size” özniteliği olan bir birleştirme, tamponun sonunun ötesine yazıyor; yığın belleği bozuluyor. Bu açığın CVE numarasını GitLab verdi.
  • CVE-2026-114466: git fast-import içindeki üç özellik (rewrite-submodules-from, rewrite-submodules-to ve export-pack-edges) rastgele dosya okumak ya da dosya oluşturup içine veri eklemek için kullanılabiliyordu. Git artık bu özellikleri, --allow-unsafe-features verilmedikçe girdi akışında reddediyor.

GitLab’ın değerlendirmesine göre kod barındırma sunucuları için en olası yol, bir birleştirme isteğinin uygun olup olmadığını denetlemek için çalışan git merge-tree komutu. Özniteliği depoya eklenen bir .gitattributes dosyasıyla belirlemek mümkün olduğundan, dal gönderip birleştirme isteği açabilen herhangi bir kullanıcı sunucudaki bu açığı tetikleyebilir. Hemen güncelleyemeyen sunucular için geçici çözüm, her deponun info/attributes dosyasına conflict-marker-size=7 eklemek ya da güvenilmeyen depolarda bu birleştirme denetimlerini kapatmak.

GitHub ve diğer araçlar ne durumda?

GitHub, düzeltmeleri github.com ve GitHub Enterprise Cloud’a (veri yerleşimli sürüm dâhil) uyguladığını açıkladı. Kendi sunucusunda GitHub Enterprise Server çalıştıranlar için düzeltmeler 3.19.15, 3.20.11, 3.21.9 ve 3.22.4 sürümlerinde. GitHub Desktop ve GitHub Copilot uygulaması için düzeltilmiş sürümler hazırlanıyor; GitHub Codespaces ve GitHub Actions da düzeltilmiş Git’i alacak.

The Hacker News, 10 Kasım’da 19.09 UTC itibarıyla Git for Windows’un 2.56.1’e dayanan bir sürüm yayımlamadığını kendi kontrolüyle belirtti. Bu, Windows’ta Git kullanan çok sayıda geliştirici için önemli bir ayrıntı: Güncelleme duyurusu geldiğinde elle kurmak gerekecek. Bu yazı yayımlanırken o durumun değişip değişmediğini bağımsız olarak doğrulamadık; kendi sürümünüzü git --version komutuyla kontrol etmek ve Git for Windows sayfasını izlemek doğru yol.

Ne yapmalısınız?

  • Sürümünüzü kontrol edin. Terminalde git --version yazın. 2.56.1 ya da kendi dalınızın düzeltilmiş sürümü (örneğin 2.55.1, 2.54.1) görünmeli.
  • İşletim sisteminizin paket yöneticisinden güncelleyin. GitHub’ın önerisi de bu: Düzeltilmiş sürümü işletim sisteminizden ya da Git dağıtıcınızdan kurun.
  • Kendi Git kopyasını getiren uygulamaları da güncelleyin. Bazı arayüzler ve geliştirme ortamları Git’i kendi içinde taşır; sistemdeki Git’i güncellemek bunları korumaz.
  • CI/CD ve otomasyon sunucularına bakın. Kullanıcılar adına depo işleyen servislerdeki Git kurulumları da güncellenmeli.
  • Güncelleme gelene kadar: Yalnızca güvendiğiniz sunuculardan klonlayın; güvenmediğiniz depoları --recursive ile klonlamayın; güvenmediğiniz içerik ya da etiketleri birleştirmeyin; güvenilmeyen kaynaklardan ikili yama ya da fast-import akışı işlemeyin. GitHub bu önlemlerin güncellemenin yerini tutmadığını özellikle belirtiyor.

Türkiye açısından

Git, Türkiye’deki yazılım ekiplerinin, yazılım firmalarının ve kurumsal BT birimlerinin de yaygın biçimde kullandığı bir araç. Bu yüzden bu sürüm yalnızca bir geliştirici sorunu değil; kurumsal güvenlik ekiplerinin envanterinde olması gereken bir güncelleme. Özellikle bir kuruma yeni bir bağımlılık, örnek proje ya da açık kaynak bileşen eklerken “recursive” klonlama yapan ekipler ilk risk grubunda. Dışarıdan gelen bir depoyu yönetilen bir iş istasyonunda klonlamak, o istasyondaki kimlik bilgilerine ve kaynak koduna uzanan bir kapı açabilir.

Kişisel veri işleyen kurumlar için ayrıca hukuki bir boyut var: 6698 sayılı KVKK’nın 12. maddesi, veri sorumlusunu kişisel verilerin güvenliğini sağlamak için uygun teknik tedbirleri almakla yükümlü kılıyor. Geliştirici bilgisayarları ve derleme sunucuları müşteri verisine erişiyorsa, bilinen bir açığın kapatılmaması bu “uygun tedbir” tartışmasında zayıf bir nokta olur. Türkiye’ye özgü bir saldırı ya da bu açıkla ilgili yerel bir olay bildirilmiş değil; bunu uydurmuyoruz. Ama yamanın dağıtımı ne kadar hızlı olursa, risk penceresi o kadar kısa kalır.

Daha önce GitLab’ın CI/CD tarafındaki kritik açığını ve tedarik zinciri güncellemesi sorununu ele almıştık. Ortak ders aynı: Kod yaşam döngüsündeki araçlar, saldırganlar için doğrudan hedef.

Sonuç

Git, çoğu geliştiricinin günde onlarca kez çalıştırdığı bir araç. Bu yüzden içindeki bir açığın etkisi geniş, ama iyi haber de net: Düzeltmeler hazır, ayrıntılı bir geçici çözüm listesi var ve kaynaklarda bir istismar bildirimi yok. Yapılacak iş sıradan ama gecikmemesi gereken bir iş: Sürümü kontrol edin, güncelleyin, Windows için Git for Windows’un yayımlayacağı sürümü bekleyip kurun ve o güne kadar güvenmediğiniz depoları özyinelemeli klonlamayın.