imgproxy'nin ICO yükleyicisindeki kritik açığa CVE atandı: tek bir görsel heap taşmasına yol açabiliyor
Açık kaynak görsel işleme sunucusu imgproxy'nin 4.0.0–4.0.15 sürümlerindeki tamsayı taşması CVE-2026-123614 kimliğini aldı (CVSS 9.8). Hazırlanmış bir ICO dosyası süreci çökertebiliyor ya da kod çalıştırmaya kapı açabiliyor; düzeltme 4.0.16'da.
CVE-2026-123614
Web sitelerinde ve uygulamalarda görselleri anlık boyutlandırmak için yaygın kullanılan açık kaynak imgproxy sunucusundaki kritik bir açık, 8 Kasım'da CVE-2026-123614 kimliğini aldı. Proje bu açığı 6 Ekim'de GHSA-hff9-5pqw-6w9f bildirimiyle duyurmuş ve 4.0.16 sürümünde kapatmıştı. CVE ataması ve NVD kaydıyla açık, zafiyet tarayıcılarında ve envanter araçlarında da görünür hale geldi. Puanı CVSS v3.1'e göre 9.8, CVSS v4'e göre 9.3.
Sorun ICO görsel yükleyicisinde. Dosyadaki 32 bitlik veri boyutu alanı bellek ayırma sırasında taşıyor; bunun sonucunda çok küçük bir alan ayrılıyor ve veri bu alanın dışına yazılıyor (CWE-122, heap buffer overflow). Kimlik doğrulama ya da kullanıcı etkileşimi gerekmiyor. Hazırlanmış tek bir görsel, imgproxy sürecini çökertebiliyor ve bellek bozulmasıyla kod çalıştırma ihtimali doğuruyor. Açığın saldırılarda kullanıldığına dair bir bildirim yok ve açık CISA KEV listesinde değil.
Etkilenen ve düzeltilmiş sürümler
| Ürün | Etkilenen | Düzeltilmiş sürüm |
|---|---|---|
imgproxy (github.com/imgproxy/imgproxy/v4) | 4.0.0 – 4.0.15 | 4.0.16 |
Sürümler imgproxy'nin GHSA-hff9-5pqw-6w9f bildiriminden alınmıştır. Proje 2 Kasım'da yayımladığı 4.0.21'de de BMP ve ICO yükleyicilerindeki birkaç açığı daha kapattığını duyurdu. Bu nedenle 4.0.16 en düşük sınırdır; güncel sürüme geçmek daha doğru olur.
Beni etkiliyor mu?
imgproxy çoğunlukla konteyner olarak çalıştırılır. Çalışan imajın etiketini salt okunur komutlarla görebilirsiniz:
docker ps --format "{{.Names}} {{.Image}}" | grep -i imgproxy
kubectl get pods -A -o wide | grep -i imgproxy
kubectl get deploy -A -o wide | grep -i imgproxyİmaj etiketi 4.0.0 ile 4.0.15 arasındaysa ya da latest gibi sabit olmayan bir etiketse imajın gerçek sürümünü kayıt defterinden doğrulayın. imgproxy'yi Go kütüphanesi olarak derlediyseniz go.mod dosyasındaki github.com/imgproxy/imgproxy/v4 satırına bakın. Kullanıcıların görsel yükleyebildiği ya da dış adreslerden görsel çektiğiniz kurulumlar en açık olanlardır.
Ne yapılmalı?
- imgproxy'yi en az 4.0.16'ya, tercihen BMP ve ICO düzeltmelerini de içeren güncel sürüme yükseltin; sabit sürüm etiketi kullanın.
- Yükseltme hemen mümkün değilse imgproxy'ye gelen istekleri imzalı URL zorunluluğu ve izinli kaynak listesiyle sınırlayın. Kullanıcıların kendi yüklediği dosyalar izinli kaynakta duruyorsa bu önlem tek başına yetmez; ICO yüklemelerini uygulama katmanında reddetmek de değerlendirilmeli.
- imgproxy süreçlerinde beklenmeyen çökmeleri ve yeniden başlamaları izleyin. Ani yeniden başlama artışları, hazırlanmış görsel denemelerinin işareti olabilir.
- Değişikliği normal change management sürecinizle planlayın; görsel önbelleği (CDN) varsa yükseltme sonrası hata oranını kontrol edin.
