Carnegie Mellon Üniversitesi doktora öğrencisi ve Cure53 cryptographic auditor’ı Jacob Ginesin, GitHub’un “Verified” rozetiyle ilgili çarpıcı bir bulgu yayınladı. 2 Temmuz 2026’da arXiv’e yüklenen beş sayfalık makaleye göre, imzalı bir Git commit’i aynı içerik, aynı yazar ve aynı zaman damgasıyla farklı hash’ler üretecek şekilde yeniden yazılabiliyor. Ve tüm bu varyantlar GitHub’da “Verified” olarak görünmeye devam ediyor.
Sorunun özü: signature malleability
Zafiyet signature malleability kavramına dayanıyor. Yani içeriği ya da imzalayan kimliği değiştirmeden, kriptografik imzayı geçerli alternatif biçimlere dönüştürebilme. Aynı içerik, farklı hash, hepsi geçerli, hepsi Verified.
Önemli bir noktayı baştan koymak lazım: bu bir hash collision değil. “Bir commit, birçok geçerli encoding” durumu. Yani signature verification kimin imzaladığını kanıtlıyor, ama hash’in ne imzalandığı için tekil bir tanımlayıcı olduğunu kanıtlamıyor.
Üç saldırı yolu
- ECDSA anahtarlar: İmzadaki
sdeğerinin - sile değiştir. Her iki form da kriptografik olarak geçerli doğruluyor. Yerel Git verification ve GitHub sonucu kabul ediyor. - RSA ve EdDSA anahtarlar: İmzanın unhashed bölümüne ekstra imzasız bir alan ekle. Commit byte’ları ve hash değişse bile imza geçerli kalıyor.
- S/MIME (X.509) anahtarlar: İmzanın DER encoding’indeki length alanlarını standart olmayan formlara yeniden yaz. Sıkı yerel kontroller reddediyor, ama GitHub yine de “Verified” olarak işaretliyor.
Hash chain’in tümü etkileniyor
Commit’ler ebeveynlerini hash ile referans aldığı için, bir commit üzerinde malleation yapmak zincir yukarı doğru tüm hash’leri değiştirmeye zorluyor. Ginesin’in aracı zincir tutarlılığını koruyor ve zincir sonundaki tüm commit’ler yine doğrulanmış olarak kalıyor.
Teknik kök neden
GitHub imzaları doğrulamadan önce normalize etmiyor. Canonical olmayan ECDSA değerlerini kabul ediyor, OpenPGP alanlarını temizlemiyor ve non-standard DER encoding’e izin veriyor. Bir de “Verified” kayıtlarını commit hash’i üzerinden tutuyor ve tekrar kontrol etmiyor. Bu yüzden iptal edilmiş anahtarlar bile mevcut Verified rozetlerini geçersiz kılmıyor.
Pratik saldırı senaryoları
- Zararlı bir commit’i hash ile bloklarsınız, saldırgan aynı içeriği farklı ama hâlâ “Verified” bir hash altında tekrar push edebilir
- Deduplication sistemleri, provenance log’ları ve reproducible-build kayıtları commit hash’ine güveniyorsa zafiyeti miras alır
- Düşmanca mirror’lar, canonical kaynaklardan farklı hash’lerle geçerli imzalı commit’ler dağıtabilir
Kritik bir sınır: bu zafiyet, imza kontrollerinden farklı kod geçirmenize izin vermiyor. Tüm hash varyantları aynı dosyaları içeriyor.
Etkilenen sistemler
- Bağımlılık takibi için verified commit hash’lerini pin’leyen supply chain araçları
- Verified rozeti değişmez bir referans olarak kabul eden CI/CD pipeline’ları
- Provenance kayıtları için commit hash kullanan reproducible-build altyapıları
- Verified’ı commit bütünlüğünün kesin kanıtı olarak kabul eden GitHub kullanıcıları
Proof-of-Concept
Ginesin, GitHub’da git-chain-malleator adında açık kaynaklı bir araç yayınladı. Üç saldırı yolunun tümünü gösteriyor. Ayrıca malleate edilmiş commit’lerin GitHub üzerinde hâlâ “Verified” göründüğünü kanıtlayan demo repository’ler de mevcut.
Bildirim zaman çizelgesi
- Ocak 2026: GNU ve Git ekibine bildirildi
- Mart 2026: GitHub’a bildirildi
- 2 Temmuz 2026: arXiv üzerinden makale ve public PoC aracı yayınlandı
- 8 Temmuz 2026: Kamuoyu ile paylaşıldığında hâlâ herhangi bir vendor fix yayınlanmamış durumda
Bitcoin ile paralel
Ginesin’in çalışması, Bitcoin’in 2014’teki ECDSA transaction malleability krizini akla getiriyor. Kullanıcılar imza s değerini flip ederek transaction ID’lerini değiştirebiliyordu. Bitcoin bunu önce sadece “low-S” formlarını kabul ederek, sonra da SegWit ile imzayı ID’nin dışına çıkararak çözmüştü.
Ne yapılmalı?
Forge operatörleri için (GitHub’ın sorumluluğunda):
- Verified kaydını almadan önce imza encoding’ini canonicalize et
- Sıkı S/MIME encoding validation uygula, non-standard DER’i reddet
- Hash’lemeden önce normalize OpenPGP alanlarını strip et
- Sadece “low-S” ECDSA formlarını kabul et
Geliştiriciler için (rahat olun):
- Tam commit hash’e pin’lemek hâlâ doğru kodu çekiyor, bu mekanizma bozulmuyor
- Reproducible build’lerde pin edilmiş hash’ler güvenli kalıyor
- Actions/module’leri tag yerine commit hash’e pin’leme tavsiyesi geçerliliğini koruyor
Tooling geliştiricileri için: Commit hash ile blokladığı, dedupe ettiği ya da provenance kaydettiği sistemler önce imzayı doğrulayıp canonicalize etmeli. Fetched dosyaların bağımsız hash’lerine pin’leyen sistemler (Nix’in fixed-output derivation’ları gibi) korunuyor.
Zafiyetin somut özeti: “Geçerli imza kimliği kanıtlar, tekilliği değil.” Verified commit hash’lerini kalıcı, tampering-proof kayıtlar olarak muamele eden sistemler önce imza canonicalization yapmalı. GitHub bu sorunu çözdüğü zaman zaten olması gereken bir tasarım kararı yerine oturacak. Ama şu ana kadar aylardır bilinen bir konu ve düzeltme gelmemiş olması, supply chain güvenliği konusunda hâlâ ne kadar temel meselelerle uğraştığımızın somut bir kanıtı.
Kaynak: https://thehackernews.com/2026/07/github-verified-commits-can-be.html
