Tek HTTP Başlığı ile Rails Sunucunuzu Çökertmek Mümkün

Saldırganın tek yapması gereken şey: sunucunuza Range: bytes=0- başlığı taşıyan bir HTTP isteği göndermek. Rails’in Active Storage bileşeninde keşfedilen CVE-2026-33174, CVSS 7.5 (Yüksek) puanıyla proxy modunda dosya sunan her Rails uygulamasını hedef alıyor. Kimlik doğrulama gerektirmeden, sıfır ayrıcalıkla, tek bir istek bile sunucuyu devre dışı bırakmaya yetebilir.

CVE-2026-33174 Nedir? Teknik Özet

Active Storage, Rails uygulamalarında bulut ve yerel dosyaları yönetmek için kullanılan yerleşik bir bileşendir. Dosyaları kullanıcıya iletmek için iki mod sunar: yönlendirme (redirect) ve proxy. Proxy modunda tüm dosya trafiği Rails sunucusu üzerinden geçer; bu da içerik kontrolü, erişim denetimi ve oturum yönetimi gibi avantajlar sağlar. Ancak bu konforu bir açık kapıya dönüştüren kritik bir tasarım hatası var.

HTTP standardı, istemcilerin büyük dosyaların yalnızca belirli bir bölümünü istemesine olanak tanıyan Range başlığını destekler. Örneğin bir video oynatıcı Range: bytes=0-1023 göndererek yalnızca ilk 1 KB’ı ister. Ancak CVE-2026-33174’e konu olan açıkta Rails’in proxy denetleyicisi, gelen Range başlığını doğrulamadan tüm istenen bayt aralığını önce belleğe yüklemekte, ardından istemciye göndermektedir.

⚠️ Burası kritik nokta: Range: bytes=0- gibi üst sınırsız bir istek, sunucunun dosyanın tüm içeriğini — kaç gigabayt olursa olsun — belleğe almasına neden olur. Bu işlem tekrarlandığında ya da eş zamanlı çok sayıda istek gönderildiğinde bellek tükenmesi (memory exhaustion) kaçınılmaz hâle gelir ve hizmet dışı bırakma (DoS — Denial of Service) gerçekleşir.

Saldırı Nasıl Çalışır? Senaryo Analizi

Bu zafiyeti gerçek bir saldırı senaryosuna oturtmak için kurumsal düzeyde yaygın bir kullanım örneğini ele alalım: şirket içi belge yönetim sistemi, müşteri portalındaki dosya indirme servisi ya da medya arşivi. Bu sistemlerin ortak özelliği: Active Storage proxy modunu etkinleştirmiş olmaları ve kullanıcıların (ya da anonim ziyaretçilerin) dosyalara HTTP üzerinden erişebilmesi.

Saldırı zinciri son derece basit:

Saldırgan, Active Storage üzerinden sunulan herhangi bir dosyanın URL’ini tespit eder (bu URL çoğunlukla tahmin edilebilir ya da açık kaynaklarda mevcuttur).
Range: bytes=0- başlığıyla bir GET isteği gönderir.
Sunucu, dosyanın tamamını belleğe yüklemeye çalışır. 500 MB’lık bir dosya için bu 500 MB RAM demektir.
İstek eş zamanlı tekrarlanırsa (örneğin 10 paralel istek) sunucu 5 GB RAM tüketir ve çöker.

Kimlik doğrulama gerektirmez, özel bir araç gerekmez. Curl ya da herhangi bir HTTP istemcisiyle gerçekleştirilebilir:

# Zafiyetin kavramsal gösterimi (PoC - yalnızca eğitim amaçlı)
# Kendi test ortamınızda, izinli sistemlerde deneyin

curl -H "Range: bytes=0-" \
     buyuk-dosya.pdf erişimi için tıklayın

# Paralel istek etkisini simüle etmek için (yük testi aracıyla):
# ab -n 50 -c 10 -H "Range: bytes=0-" \
#    https://hedef-uygulama.example.com/rails/active_storage/blobs/proxy/TOKEN/dosya.pdf

🛡️ Önemli not: Yukarıdaki komutları yalnızca kendi test ortamlarınızda, yetkili olduğunuz sistemlerde kullanın. İzinsiz sistemlerde denemek yasal sonuçlar doğurur.

Kimin İçin Ne Kadar Kritik?

Rails, özellikle startup ekosistemi, e-ticaret platformları ve SaaS ürünleri geliştiren Türk yazılım ekipleri arasında yaygın biçimde kullanılıyor. Active Storage ise Rails 5.2’den bu yana çerçevenin (framework) ayrılmaz parçası hâline geldi. Bu demek oluyor ki yıllar içinde Active Storage’ı aktif olarak kullanan devasa bir uygulama tabanı oluştu.

Etkilenen sürümler şunlar:

Rails 8.x → 8.1.2.1 öncesi tüm sürümler
Rails 8.0.x → 8.0.4.1 öncesi tüm sürümler
Rails 7.2.x → 7.2.3.1 öncesi tüm sürümler

Peki bu zafiyet kimler için gerçekten risk oluşturuyor? Öncelik sıralaması şöyle:

🔴 Yüksek risk: Active Storage proxy modu etkin, büyük dosyalar (video, PDF, arşiv) sunulan, herkese açık dosya erişimi olan uygulamalar
🟠 Orta risk: Kimlik doğrulama gerektiren ama çok sayıda kullanıcısı olan SaaS platformları (iç kullanıcı da kasıtlı ya da kasıtsız DoS yapabilir)
🟡 Düşük risk: Active Storage kullanan ama yalnızca yönlendirme (redirect) modunu tercih eden uygulamalar — bu mod doğrudan etkilenmiyor

MITRE ATT&CK çerçevesine göre bu zafiyet T1499 – Endpoint Denial of Service ve alt teknik T1499.002 – Service Exhaustion Flood kategorisiyle örtüşüyor. Saldırgan altyapı kaynağını (bellek) tüketmek suretiyle hizmeti devre dışı bırakıyor; bu klasik bir kaynak tükenmesi saldırısı.

🔧 Nasıl Korunulur? Acil Aksiyon Listesi

Yamayı derhal uygulayın: Rails 8.1.2.1, 8.0.4.1 veya 7.2.3.1 sürümlerine geçin. Bu, birincil ve en etkili çözümdür. bundle update rails yeterli olmayabilir; Gemfile‘ı açıkça güncelleyin ve bundle install ardından uygulamayı yeniden başlatın.
Proxy modunu denetleyin: Active Storage’ı hangi modda kullandığınızı hemen kontrol edin. Yalnızca proxy modu etkileniyor. config/environments/production.rb içinde config.active_storage.resolve_model_to_route ayarını inceleyin. Proxy kullanmak zorunda değilseniz redirect moduna geçin.
WAF kuralı veya reverse proxy koruması ekleyin: Nginx ya da önünüzde bir WAF varsa anormal Range başlıklarını filtreleyin (aşağıda örnek mevcut).
Bellek kullanımını izleyin: Wazuh ile sistem bellek tüketimini anlık olarak takip edin ve eşik aşımında uyarı alın.
Hız sınırlama (rate limiting) uygulayın: Active Storage proxy uç noktalarına (/rails/active_storage/blobs/proxy/) özelinde istek hız sınırlaması koyun.
Bağımlılık tarama araçlarını devreye alın: Bundler Audit ya da GitHub Dependabot’u aktif edin; bundan sonraki benzer zafiyetleri otomatik olarak yakalasın.

Nginx ile Range Başlığı Filtreleme ve Wazuh Perspektifi

Yamayı hemen uygulayamıyorsanız ya da ek bir savunma katmanı istiyorsanız, Nginx düzeyinde Range başlıklarını sınırlandırabilirsiniz:

# /etc/nginx/conf.d/rails-activestorage-protection.conf
# Active Storage proxy uç noktalarına gelen anormal Range başlıklarını engelle

server {
    # ... diğer ayarlar ...

    location ~* ^/rails/active_storage/blobs/proxy/ {

        # Üst sınırsız Range başlıklarını engelle (bytes=0- gibi)
        # Geçerli Range: belirli bir üst sınır içermeli
        if ($http_range ~* "bytes=\d+-$") {
            return 416; # Range Not Satisfiable
        }

        # İzin verilen maksimum Range boyutunu dolaylı olarak sınırla:
        # Tek istekte maksimum 50 MB bayt aralığına izin ver
        # (Bu kural uygulama katmanında daha güvenli şekilde yapılmalı,
        #  Nginx regex ile tam byte hesabı yapmaz; yamaya alternatif değil)

        # Aynı IP'den saniyede maksimum 5 istek
        limit_req zone=activestorage_limit burst=10 nodelay;

        proxy_pass http://rails_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

# http bloğuna ekleyin:
limit_req_zone $binary_remote_addr zone=activestorage_limit:10m rate=5r/s;

Wazuh tarafında ise iki farklı yaklaşım işe yarar. Birincisi, Nginx veya Rails uygulama günlüklerinde Range: bytes=0- içeren istekleri tespit eden özel bir kural:

<!-- /var/ossec/etc/rules/rails_activestorage_dos.xml -->
<group name="rails,activestorage,dos,">

  <!-- Kural 1: Nginx erişim günlüğünde sınırsız Range başlığı tespiti -->
  <rule id="100650" level="10">
    <decoded_as>nginx-access</decoded_as>
    <match>/rails/active_storage/blobs/proxy/</match>
    <field name="http_range">bytes=\d+-$</field>
    <description>CVE-2026-33174: Active Storage proxy - sinirsiz Range basligi tespit edildi (olasi DoS denemesi)</description>
    <group>attack,dos,cve-2026-33174,</group>
  </rule>

  <!-- Kural 2: Kısa sürede aynı IP'den tekrarlanan proxy istekleri -->
  <rule id="100651" level="12" frequency="10" timeframe="30">
    <if_matched_sid>100650</if_matched_sid>
    <same_source_ip/>
    <description>CVE-2026-33174: Ayni IP'den 30 saniyede 10+ sinirsiz Range istegi - DoS saldirisina isaret ediyor</description>
    <group>attack,dos,cve-2026-33174,high_frequency,</group>
  </rule>

</group>

İkincisi, sistem genelinde bellek tüketimini izlemek için Wazuh’un yerleşik sistem izleme yeteneklerini kullanmak. ossec.conf içinde wodle name="syscollector" etkin olduğundan emin olun ve Wazuh gösterge panelinde (dashboard) bellek kullanım metriklerini takip edin. Ani ve sürekli bellek artışı, bu tür DoS denemelerinin erken uyarısı olabilir. Benzer sistem izleme yaklaşımlarını CISA KEV Wazuh tespit rehberimizde de incelemiştik.

📊 Benim Gözümden: Bu Açık Neden Hafife Alınmamalı?

CVSS 7.5 puanı “Yüksek” kategorisinde ama bazı ekipler bunu orta seviye bir sorun gibi değerlendirebilir; zira uzaktan kod çalıştırma (RCE) değil, yalnızca hizmet dışı bırakma (DoS) söz konusu. Bu bakış açısı tehlikeli.

Kurumsal bağlamda düşünün: bir SaaS uygulaması ya da müşteri portalı birkaç saat boyunca erişilemez kalırsa bu yalnızca teknik bir sorun değil, itibar ve gelir kaybına dönüşür. Rekabetçi bir ortamda, özellikle rakip ya da organize tehdit aktörleri tarafından kasıtlı olarak kullanılırsa etki çok daha ağır olabilir. Üstelik bu saldırıyı gerçekleştirmek için özel bir uzmanlık gerekmediğinden düşük yetenekli saldırganlar (script kiddie) da rahatlıkla kullanabilir.

Bir diğer önemli nokta: bu açığın kamuoyuna duyurulmasıyla birlikte istismar araçları çok hızlı yayılır. Benzer tedarik zinciri risklerini Mirai botnet analizimizde gördük — basit ama etkili açıklar hızla silahlandırılır. Active Storage proxy uç noktaları da internetten erişilebilen pek çok Rails uygulamasında varsayılan olarak aktif, bu da hedef yüzeyini genişletiyor.

Son olarak şunu da söylemem gerekiyor: Rails ekosistemi genellikle güvenlik yamalarını hızlı yayınlama konusunda başarılıdır ve bu sefer de yamalar hazır durumda. Engel yok, aksiyon almak için bir neden de var. Gecikmek için mazeret üretmeyin.

Orijinal kaynak: https://nvd.nist.gov/vuln/detail/CVE-2026-33174

Securtr