CVE-2026-58420 nedir?

Gitea, kurumların kendi altyapılarında Git servisleri, CI/CD entegrasyonları ve kaynak kod depoları çalıştırmak için kullandığı yaygın bir platformdur. Bu nedenle Gitea örneğinin ele geçirilmesi yalnızca tek bir uygulamayı değil; kaynak kodu, dağıtım sırlarını, SSH anahtarlarını ve geliştirme tedarik zincirini etkileyebilir.

CVE-2026-58420, Gitea'nın restore-repo işlemindeki release attachment geri yükleme akışında ortaya çıkan bir yerel dosya dahil etme (Local File Inclusion / LFI) zafiyetidir. Resmî GitHub Security Advisory, etkilenen sürümleri <= 1.26.4, düzeltilmiş sürümü ise 1.27.0 olarak listeliyor. Duyuru, bulguyu Eresus Security araştırmacılarına atfediyor.

Bu yazı bir saldırı rehberi değildir. Amaç, güvenlik ekiplerinin riskin nerede doğduğunu, hangi sistemlerin öncelikli olduğunu ve düzeltmenin nasıl doğrulanması gerektiğini anlamasına yardımcı olmaktır.

Bulgu nasıl ortaya çıkarıldı?

Araştırma, Gitea'nın geniş yetkiyle çalışan fakat görece az kullanılan yönetimsel veri geri yükleme yollarına odaklanan bir kaynak kodu incelemesiyle başladı. Bu tür akışlar özellikle değerlidir: normal kullanıcı isteği gibi görünmezler, ancak arşivden gelen veriyi dosya sistemi, ağ istemcisi veya servis hesabı yetkileriyle buluşturabilirler.

İzlenen soru basitti: Migration arşivinden gelen hangi alanlar, sunucuda kaynak açan bir fonksiyona ulaşabiliyor? İnceleme, release metadata'sındaki asset indirme konumunun uri.Open() yardımcısına aktarıldığını gösterdi. Yardımcının tek bir kullanım için yazılmamış olması kritik ayrıntıydı; ağ kaynaklarının yanında yerel kaynak şemasını da destekliyordu. Ardından çağrı noktasında restore bağlamına özgü bir http/https izin listesi bulunup bulunmadığı değerlendirildi.

Bu yöntem, kelime bazlı "tehlikeli fonksiyon ara" yaklaşımı değildir. Veri kaynağı, dönüştürüldüğü yer, yetkili işlem bağlamı ve sonucun nerede kalıcılaştığı birlikte takip edilir. Buradaki zincir; arşiv metadata'sı → indirme konumu → çok şemalı kaynak açıcı → release attachment depolaması şeklindedir. Yani riskin anlaşılması için tek bir satıra değil, bileşenler arasındaki güven sınırına bakmak gerekir.

Neler doğrulandı, neler bu yayının kapsamı dışında?

Resmî duyuruda belirtilen etki, restore işini başlatabilen veya operatöre güvenilmeyen bir arşiv sağlayabilen tarafın, Gitea işlem kullanıcısının okuyabildiği içeriği release attachment olarak yazdırabilmesidir. Bu nedenle doğrulama; çağrı zinciri, desteklenen şemalar, servis hesabı bağlamı ve oluşan attachment'ın uygulama içindeki yaşam döngüsü üzerinden yapıldı.

Bu makale belirli bir kurumun anahtarlarına erişildiğini, uzaktan anonim bir kullanıcının bu işlemi yapabildiğini veya her Gitea kurulumunun aynı etkiye sahip olduğunu iddia etmez. Gerçek etki; restore yetkisi, arşivin nereden geldiği, Gitea'nın hangi kullanıcıyla çalıştığı, container/host sınırları ve dosya izinlerine bağlıdır. Bu ayrımı korumak, hem teknik raporun hem de müşteri iletişiminin güvenilirliği için önemlidir.

Teknik veri akışı: migration arşivinden release attachment'a

Resmî duyurudaki teknik akış üç ayrı bileşenin birleşiminden oluşur:

1. restore-repo, kullanıcı tarafından sağlanan migration arşivindeki release.yml verisini işler.
2. Release asset'inin DownloadURL alanı, kaynak açma yardımcısına bağlama özgü bir şema kısıtlaması olmadan ulaşır.
3. Yardımcı hem ağ hem de yerel kaynak şemalarını desteklediği için, Gitea işlem kullanıcısının okuyabildiği içerik release attachment olarak depolanabilir.

Bu, klasik bir "dosya yolu temizleme" hatasından daha spesifiktir: sınır, güvenilmeyen arşiv verisinin çok amaçlı bir kaynak-açma fonksiyonuna iletilmesindedir. Dosyanın okunabilmesi tek başına son etki değildir; içeriğin Gitea tarafında bir attachment'a dönüşmesi, erişilebilir bir uygulama nesnesi yaratır. Bu nedenle olay müdahalesi hem host erişimlerini hem de geçmiş release attachment kayıtlarını kapsamalıdır.

Risk puanı ile iş etkisini birlikte okumak

GitHub duyurusu bulguyu CVSS v4 6.7 / Moderate olarak sınıflandırır: saldırı vektörü yereldir ve yüksek ayrıcalık gerekir, ancak gizlilik etkisi yüksektir. Bu sınıflandırma "önemsiz" anlamına gelmez. Gitea çoğu ortamda CI sırları, deployment anahtarları, altyapı manifestleri ve bulut kimlikleriyle yakın çalışır. Bu nedenle önceliklendirme, yalnızca CVSS puanına değil Gitea işlem hesabının gerçek erişimlerine ve restore arşivlerinin kökenine dayanmalıdır.

Tehdit modeli: bu risk hangi koşullarda anlamlı hâle gelir?

Bu vakada saldırgan modeli, internetten anonim bir istek gönderen sıradan kullanıcı değildir. Daha gerçekçi iki model vardır. Birincisi, restore işlemini başlatabilen veya bu işlemi yürüten makineye erişebilen operatördür. İkincisi ise doğrudan bu yetkiye sahip olmadan, bir ekip üyesinin çalıştıracağı migration paketini hazırlayabilen tedarikçi, danışman, eski çalışan hesabı ya da iç sistemdir. İkinci model özellikle önemlidir; operasyon ekibi arşivi "veri" olarak görürken, uygulama onu sunucu tarafında kaynak açtıran talimata dönüştürebilir.

Bu yüzden değerlendirme yalnızca Gitea yönetici sayfası izinlerinden başlamamalıdır. Restore komutuna nereden erişildiği, arşivlerin hangi depodan/nesne deposundan geldiği, bütünlük veya onay zinciri bulunup bulunmadığı ve üretim ortamına aktarımın kim tarafından yapıldığı ayrı ayrı incelenmelidir. CI/CD sisteminin, uzak destek bağlantısının veya paylaşımlı operasyon hesabının bu zincire girmesi, teknik ön koşulu iş sürecindeki zayıflıkla birleştirir.

Varlık etkisi de homojen değildir. Kısıtlı bir container içinde, sır dosyalarından ayrılmış bir Gitea kullanıcısının etkisi ile host üzerinde geniş okuma yetkisi olan, bulut kimlik bilgileri veya runner token'larıyla aynı kullanıcı bağlamını paylaşan bir kurulumun etkisi aynı kabul edilmemelidir. Bu nedenle CVSS başlangıç noktasıdır; müşteri özelindeki karar, erişilebilir veri sınıfları ve kimlik sınırlarıyla verilmelidir.

Etki zinciri: dosya okunmasından iş riskine

Yerel dosya okuma bulgularında sık yapılan hata, etkiyi yalnızca okunabilecek örnek dosya ile anlatmaktır. Asıl soru, okunan içeriğin sonraki adımda neye izin verdiğidir. Bir uygulama yapılandırmasındaki veritabanı parolası, bir deploy anahtarı veya bulut kimliği tek başına olaya son vermez; bunlar sırasıyla kaynak koduna, pipeline'a, altyapıya veya müşteri verisine erişen başka güven sınırlarını etkileyebilir.

Bu nedenle olay analizi, bir "etki grafiği" üretmelidir: Gitea servis hesabı → okunabilir dosya sınıfları → dosyanın içerdiği kimlik/sır → o sırrın erişebildiği sistem → iş yükü veya veri. Her ok, varsayım değil kanıtla desteklenmelidir. Örneğin bir sır bulunmuş olması onun hâlâ geçerli olduğu; bir anahtarın varlığı da üretim yetkisi verdiği anlamına gelmez. Bu disiplin, gereksiz paniği azaltır ve gerçekten döndürülmesi gereken kimlikleri doğru sıraya koyar.

Düzeltmeyi teknik olarak nasıl doğrulamalısınız?

Güncellemenin başarılı olduğunu söylemek için paket sürümüne bakmak yeterli değildir. Değişiklik kaydında en az dört ayrı kanıt bulunmalıdır:

1. Çalışan süreç kanıtı: Yalnızca imaj etiketi veya paket yöneticisi değil, çalışan Gitea işlemindeki sürüm doğrulanır.
2. Akış kanıtı: Restore işlemi için beklenmeyen şemaların reddedildiği veya güvenilen kaynaklarla sınırlı olduğu yetkili test/inceleme ile kayda geçirilir.
3. Yetki kanıtı: Gitea servis kullanıcısının dosya erişimi ve ona bağlı sırlar gözden geçirilir; gereksiz izinler kaldırılır veya kimlikler döndürülür.
4. Geriye dönük kanıt: İlgili zaman aralığındaki restore işleri, release attachment'ları ve yönetici faaliyetleri anomali açısından incelenir.

Bu kanıtlar, hem teknik ekibin gerçek kapanışı görmesini hem de denetim sırasında "hangi risk, hangi kontrolle, ne zaman kapatıldı?" sorusunu cevaplamasını sağlar. Eresus Guard kaydı, bu dört kanıt türünü tek bir bulgu altında ilişkilendirmek için kullanılabilir.

Sorunun kök nedeni: güvenilmeyen veri ile dosya erişimi arasındaki sınır

Gitea'nın yedekten geri yükleme süreci, arşiv içindeki release metadata'sını işler. Zafiyetli akışta bir release attachment için belirtilen indirme adresi, yeterli şema doğrulaması olmadan kaynak açma fonksiyonuna iletilebiliyordu.

Bu önemli bir tasarım dersi içeriyor: Bir fonksiyonun http, https ve yerel dosya şemalarını desteklemesi tek başına hata değildir. Risk, kullanıcı veya arşiv kontrolündeki verinin bu fonksiyona bağlama özgü bir izin listesi olmadan ulaşmasıyla oluşur.

Geri yükleme işlemini çalıştırabilen veya bu işlemi çalıştıracak operatöre kötü amaçlı bir arşiv sağlayabilen kişi, Gitea işleminin okuyabildiği dosyaları release attachment olarak depolamaya zorlayabilirdi. Etki; uygulama yapılandırmalarına, bulut kimlik bilgilerine veya anahtar materyallerine erişim şeklinde ortaya çıkabilir.

Neden yalnızca "yüksek yetki gerekiyor" diye kapatılmamalı?

Güvenlik ekipleri bazen yüksek yetki gerektiren açıkları ikinci plana iter. Bu yaklaşım, yedek geri yükleme ve yönetici operasyonlarında yanıltıcı olabilir.

Yönetici erişimi şunlardan biriyle birleşebilir:

• Tedarikçiden veya başka bir ekipten gelen, yeterince incelenmemiş bir migration arşivi
• Acil kurtarma anında uygulanan kısaltılmış değişiklik ve onay süreci
• Paylaşımlı operasyon hesapları veya geniş dosya izinleri
• Gitea servis hesabının gereğinden fazla erişime sahip olması

Sonuçta risk yalnızca "kim komutu çalıştırır?" sorusu değildir. "Komut, güvenilmeyen girdiyi hangi yetkiyle işler?" sorusudur.

Etki alanını nasıl önceliklendirmelisiniz?

İlk iş, Gitea'nın sürümünü ve restore-repo kullanımını envantere bağlamaktır. Özellikle aşağıdaki ortamlar önceliklidir:

1. Üretim kaynak kodu, deployment manifestleri veya altyapı kodu barındıran Gitea sunucuları
2. Gitea işleminin bulut kimlik bilgilerine, CI sırlarına ya da SSH anahtarlarına erişebildiği hostlar
3. Migration ve geri yükleme işlerinin düzenli yapıldığı ya da dış kaynaktan arşiv kabul ettiği ortamlar
4. Servis hesabının geniş dosya sistemi izinleriyle çalıştığı sistemler

Ardından güncelleme planı çıkarılmalıdır. Duyurudaki düzeltme sürümü 1.27.0 olduğundan, yalnızca bağımlılık envanterinde riskli sürüm görülmesi değil, güncellemenin başarılı şekilde uygulanması da kayda geçirilmelidir.

Düzeltme: sürüm yükseltme + operasyonel kontrol

Sürüm güncellemesi temel adımdır; ama tek başına yeterli kanıt değildir. Güvenilir bir kapatma kaydı şu sorulara yanıt vermelidir:

• Etkilenen örneklerin tamamı bulundu mu?
• Her örnekte çalışan sürüm doğrulandı mı?
• Restore-repo işlemi kimler tarafından, hangi onayla çalıştırılabiliyor?
• Arşiv içeriği için güven zinciri veya manuel inceleme var mı?
• Gitea servis hesabının dosya izinleri gerekli en az düzeyde mi?
• Olağandışı release attachment'lar geçmişte incelendi mi?

Bu kontroller, "patch yapıldı" ile "sömürülebilir yol kapatıldı" arasındaki farkı oluşturur.

Eresus Guard burada ne sağlar?

Eresus Guard, uygulama güvenliği çalışmalarını tek bir kanıt akışında toplamak için tasarlanmıştır: DAST, SAST, SCA, IaC ve secrets değerlendirmeleri; ajan destekli planlama ile bir araya gelirken, bulgular denetlenebilir kanıta bağlanır.

Bu vaka için Guard yaklaşımı şunları destekler:

• Gitea sürümü ve ilgili bileşenlerin envanterde görünür hâle getirilmesi
• Kaynak kodu ve bağımlılık bağlamında sürüm / düzeltme incelemesi
• Restore veya migration akışlarında kullanıcı kontrollü URL, dosya yolu ve şema doğrulaması için kod denetimi
• Bulgunun etki, kapsam ve düzeltme adımıyla birlikte kaydedilmesi
• Güncelleme sonrası tekrar değerlendirme ve kanıtlı kapanış kaydı

Ürün, güvenlik ekibinin yerini alan "sihirli tarayıcı" değildir. Ama doğru soruların aynı iş akışında sorulmasına, teknik bulgunun yönetim ve mühendislik ekipleri tarafından tekrar incelenebilmesine yardımcı olur.

Ekipler için kısa kontrol listesi

• [ ] Gitea sürümünüzü doğrulayın; <= 1.26.4 kullanıyorsanız 1.27.0 veya daha yeni desteklenen sürüme geçiş planı oluşturun.
• [ ] Restore-repo yetkilerini sınırlayın ve işlemi yalnızca güvenilen, incelenmiş arşivlerle yapın.
• [ ] Gitea servis kullanıcısının dosya sistemi ve bulut kimliği izinlerini gözden geçirin.
• [ ] Release attachment geçmişinde beklenmedik dosya adlarını ve erişim kayıtlarını araştırın.
• [ ] Güncelleme sonrası ilgili akışı yeniden test edip bulgu kapanışını kanıtla kaydedin.

Gitea, CI/CD veya özel Git altyapınız için bu tür bir doğrulama akışı kurmak istiyorsanız, Eresus Guard çalışma alanını inceleyebilir veya kapsam görüşmesi planlayabilirsiniz.

İlk 72 saatte ne yapmalısınız?

Bu tür bir zafiyette hız, rastgele güncelleme yapmak anlamına gelmez. İlk 24 saatte tüm Gitea örnekleri, sürümleri, servis hesapları ve restore-repo kullanan ekipler envantere bağlanmalıdır. Sonraki 24 saatte kritik örnekler güncellenmeli; migration arşivlerinin kökeni, erişim izinleri ve geçmiş attachment kayıtları gözden geçirilmelidir. Üçüncü gün ise güncellemenin gerçekten çalıştığını, restore sürecinin beklenen şemalarla sınırlandığını ve hizmet hesabının gereksiz sırları okuyamadığını doğrulamak gerekir.

Bu yaklaşım, kesinti baskısı altında atlanan adımları görünür kılar. Özellikle Gitea'nın CI/CD, altyapı kodu ya da bulut kimlik bilgileriyle yakın çalıştığı yapılarda, bir sürüm yükseltmesi değişiklik kaydı ve tekrar test olmadan "tamamlandı" sayılmamalıdır.

Olay avcılığı ve kayıt saklama: neye bakılmalı?

Bu bulgu bir dosya okuma yoluna ilişkindir; bu nedenle log incelemesi yalnızca web istekleriyle sınırlandırılmamalıdır. Restore-repo çalıştırma kayıtları, arşivin geldiği konum, işleme alınan repository ve release metadata değişiklikleri aynı zaman çizelgesinde birleştirilmelidir. Ardından beklenmeyen boyutta, isimde veya kökende release attachment'lar; restore sırasında kullanılan yönetici hesapları; servis hesabının dosya erişim hataları ve sır erişimlerine ilişkin altyapı kayıtları değerlendirilmelidir.

Kayıtların eksik olması tek başına ihlal kanıtı değildir. Ancak bu belirsizlik açıkça risk kaydına yazılmalıdır: "tespit yeteneği yetersiz" ile "olay yaşanmadı" aynı ifade değildir. İlerisi için restore işlemlerinde değiştirilemez denetim kaydı, arşiv kaynağına ilişkin ilişkilendirme ve release attachment olaylarını izleyen alarmlar, müdahale süresini ciddi biçimde düşürür.

Yönetim için iş etkisi

Kaynak kodu platformları, yalnızca geliştirici aracı değildir; tedarik zincirinin güven sınırıdır. Bir Gitea olayında etki, uygulama kodundan deploy anahtarlarına, pipeline token'larından altyapı manifestlerine kadar uzanabilir. Bu nedenle güvenlik liderinin sorusu yalnızca "kaç sunucu güncellendi?" olmamalıdır. Asıl soru, "hangi iş yükleri bu örneğe güveniyor ve hangi sırlar bu işlem hesabının erişiminde?" olmalıdır.

Eresus Guard'ın değeri bu bağlamı tek kayıtta birleştirmesidir: varlık, teknik bulgu, sorumlu ekip, düzeltme hedefi ve yeniden doğrulama. Bu, operasyon ekibinin riskin ne zaman gerçekten kapandığını yönetim ve denetim ekiplerine kanıtlamasını kolaylaştırır.

Sık sorulan sorular

Sadece internetten erişilebilen Gitea örnekleri mi öncelikli?

Hayır. İç ağdaki bir örnek de kaynak kodu, CI sırları veya bulut kimlikleri taşıyabilir. Öncelik, ağ görünürlüğü ile birlikte varlıkların hassasiyeti ve restore akışının kimlerce kullanılabildiği değerlendirilerek belirlenmelidir.

Güncelleme sonrası neden yeniden test gerekli?

Çünkü doğru sürümün paket yöneticisinde görünmesi, çalışan servisin doğru sürümde olduğu veya operasyonel kontrolün uygulandığı anlamına gelmez. Yeniden test; sürümü, yapılandırmayı ve iş akışını aynı kapanış kaydında birleştirir.

Bu yazı saldırı tarifi veriyor mu?

Hayır. İçerik, resmi duyurudaki etkiyi savunma ve önceliklendirme açısından açıklar; istismar adımı ya da örnek komut vermez.

Kaynak

• GHSA-5ggr-2f2h-jmvm / CVE-2026-58420 — GitHub Security Advisory