Brotli açığı (CVE-2026-111497): Sistem paketini güncellemek neden yetmiyor?

Geçen hafta PHP2Shell gündemi meşgul ederken, aynı günlerde daha sessiz ama belki daha geniş etkili bir açık duyuruldu: Google'ın geliştirdiği Brotli sıkıştırma kütüphanesinin çözücüsünde (decoder) bir bellek taşması. CVE-2026-111497 numaralı açık, toplulukta "Node2Shell" ya da "Broccoli2Shell" gibi takma adlarla anılıyor.

Bu yazıda ne olduğunu, hangi yazılımların etkilendiğini ve en önemlisi bir geliştirici olarak neyi kontrol etmeniz gerektiğini anlatmaya çalışacağım. Çünkü bu açığın asıl dersi, "kütüphaneyi güncelle, geç" yaklaşımının neden işe yaramadığı.

Ne oldu?

Brotli, web'de özellikle Content-Encoding: br ile tanıdığımız, gzip'e göre daha iyi sıkıştırma oranı sunan bir algoritma. Tarayıcılar, CDN'ler, ters vekil sunucular (reverse proxy), çalışma zamanları ve pek çok veri aracı Brotli'yi kendi içinde barındırıyor.

Açık, çözücünün hatalı biçimlendirilmiş bir "block switch" durumunu format hatası olarak değil, "daha fazla girdi gerekiyor" diye yorumlamasından kaynaklanıyor. Node.js'in açıklamasına göre bu durumda akış tabanlı çözücü, sekiz baytlık bir iç tampona bayt eklemeye devam ediyor ve sınırların dışına yazıyor. Sonuç: özel hazırlanmış bir Brotli akışıyla sürecin belleğini okumak ya da bozmak, servisi çökertmek ve teorik olarak uzaktan kod çalıştırmak.

Öne çıkan birkaç bilgi:

• Etkilenen Brotli sürümleri: 1.0.3 ile 1.2.0 arası. Düzeltilmiş sürümler 1.0.10, 1.1.1 ve 1.2.1.
• Keşif: Açığı OpenAI'ın Codex Security ekibi buldu; Node.js 21 Ekim'deki güvenlik sürümünde duyurdu.
• Puanlama: CVE kaydında CVSS 4.0 ile 9.2 (kritik). Microsoft ise kendi ürünleri için CVSS 3.1 ile 8.1 veriyor ve istismarı "daha olası" olarak sınıflandırıyor.
• İstismar durumu: Yazının hazırlandığı tarih itibarıyla gerçek saldırılarda kullanıldığına dair bir kanıt yok.

İlginç bir ayrıntı: Kök nedeni düzelten değişiklik Brotli kaynak koduna Şubat 2026'da girmiş, ama o zaman bunun bir güvenlik açığı olduğu fark edilmemiş ve yeni bir sürüm çıkmamış. Yani düzeltme aylarca depoda bekledi, kimse yayımlamadı.

Kimler etkileniyor?

Liste uzun ve bu açığı ilginç kılan da tam olarak bu:

• Node.js: 22.23.4, 24.22.1 ve 26.12.1 sürümleriyle düzeltildi. 20.x ve daha eski sürümler destek dışı olduğu için düzeltme almıyor; 23.x ve 25.x gibi tek sayılı dallar da öyle.
• .NET: Microsoft 25 Ekim Pazar günü bant dışı (out-of-band) güncelleme yayımladı: .NET 8, 9, 10 ve .NET 11'in ön sürümü. Visual Studio ve PowerShell de güncellendi. .NET'te Brotli çözme varsayılan olarak açık değil, .NET Framework ise etkilenmiyor.
• Diğerleri: Bun, Envoy, Istio ve Python'un brotli ile brotlicffi paketleri için yamalar çıktı. JFrog, FFmpeg, ClickHouse ve Apache Arrow'da da açığı tespit etti; hatta FFmpeg'de özel hazırlanmış bir JPEG XL görseliyle istismar gösterdi. Yani saldırı yüzeyi yalnızca HTTP ile sınırlı değil.
• Hâlâ bekleyenler: Haberlere göre kamuya açık bir takipçide DuckDB, Apache Arrow, 7-Zip-zstd, p7zip ve EDK II yamasız görünüyordu.

Wiz'in verilerine göre bulut ortamlarının yüzde 91'inde bu açıktan etkilenen bileşen var, yüzde 82'sinde ise internete açık Node.js örnekleri bulunuyor.

Panik mi, abartı mı?

Bu rakamlar ürkütücü görünse de güvenlik camiasında tartışma var. watchTowr'dan uzmanlar etkinin tamamen yazılımın Brotli'yi nasıl kullandığına bağlı olduğunu vurguluyor. Sysdig, GitHub'daki bir kavram kanıtının yalnızca kasıtlı olarak zayıflatılmış bir derlemede çalıştığını söylüyor. Imperva resmi Node.js 24.22.0 ARM64 imajında saldırıyı denemiş, ancak her seferinde başarılı olmamış ve kodunu yayımlamamış.

Bence doğru okuma şu: "Yüzde 91 etkileniyor" demek, "yüzde 91 hacklenebilir" demek değil. Bir Node.js servisinin gerçekten risk altında olması için, o servisin ya da kullandığı bir kütüphanenin saldırganın kontrol ettiği Brotli verisini çözmesi gerekiyor. Örneğin Content-Encoding: br ile gelen istek gövdelerini açan bir API, dışarıdaki sunuculardan sıkıştırılmış yanıt çeken bir HTTP istemcisi veya kullanıcıdan sıkıştırılmış dosya kabul eden bir servis.

Bunun yanında VulnCheck'ten gelen bir yorum da dikkate değer: Yapay zeka araçları karmaşık açıkları giderek daha hızlı buluyor ve bu, ekiplerin gerçekten acil olanla yaygın ama sınırlı etkili olanı ayırt etmesini zorlaştırıyor. Brotli açığı bu yeni dönemin iyi bir örneği.

Asıl ders: Brotli nerede, biliyor musunuz?

Bu açığın geliştiriciler için en önemli tarafı şu: Sunucudaki Brotli paketini güncellemek çoğu durumda yetmiyor. Node.js gibi pek çok yazılım Brotli'yi kendi içine gömülü (bundled) olarak taşıyor. apt upgrade ile sistem kütüphanesini güncellediğinizde Node.js'in içindeki kopya değişmiyor.

Üstelik çalışan süreçler eski kodu bellekte tutmaya devam ediyor. Yani yama sonrası servisleri yeniden başlatmak, container imajlarını yeniden derlemek gerekiyor.

Pratikte yapılacaklar:

1. Çalışma zamanlarınızı kontrol edin

Node.js'in hangi sürümü ve hangi Brotli kopyasını kullandığını tek satırda görebilirsiniz:

node -p "process.versions.node + ' / brotli ' + process.versions.brotli"
pip show brotli brotlicffi
dotnet --list-runtimes

Bunu yalnızca kendi makinenizde değil, üretimdeki container imajlarında da çalıştırın. Base imajı node:24 gibi sabit bir etiketle çeken projeler, imaj yeniden derlenmedikçe eski sürümde kalır.

2. Brotli verisini kimin çözdüğünü bulun

• İstek gövdelerini otomatik açan middleware'ler var mı?
• Uygulamanız harici API'lerden br ile sıkıştırılmış yanıt alıyor mu?
• Kullanıcıdan arşiv, görsel veya sıkıştırılmış veri kabul ediyor musunuz?
• Envoy, Istio gibi bir proxy katmanı sıkıştırma çözüyor mu?

3. Yamayı hemen uygulayamıyorsanız

OpenAI'ın Patch the Planet girişimi, yama uygulanana kadar güvenilmeyen Brotli verisinin mümkün olduğunca engellenmesini öneriyor. Proxy veya WAF katmanında Content-Encoding: br taşıyan istekleri reddetmek ya da boyut ve sıkıştırma oranı sınırı koymak geçici bir önlem olabilir. Ama bunlar yamasız bir çalışma zamanını güvenli hale getirmez; yalnızca zaman kazandırır.

4. Destek dışı sürümlerden çıkın

Node.js 20 hâlâ üretimde çalışan pek çok projede var. Bu açık, destek dışı bir çalışma zamanının ne demek olduğunu somut olarak gösteriyor: Düzeltme gelmiyor. Node.js 26'nın 28 Ekim'de LTS olacağını da hatırlatalım; geçiş planı yapmak için iyi bir zaman.

Sonuç

Brotli açığı tek başına bir felaket olmayabilir; şu ana kadar bilinen bir saldırı yok ve güvenilir bir istismar kodu da ortada değil. Ama yazılım tedarik zincirimizin ne kadar görünmez katmanlardan oluştuğunu bir kez daha gösteriyor. Çoğumuz projelerimizde Brotli kullandığımızı bile düşünmüyoruz; oysa çalışma zamanının, proxy'nin, veri aracının içinde bir yerde duruyor.

Bu yüzden bu haftaki ödev basit ama önemli: Envanterinizi çıkarın, çalışma zamanlarınızı güncelleyin, imajlarınızı yeniden derleyin ve servislerinizi yeniden başlatın. Bir sonraki "her yerde olan kütüphane" açığında aynı soruları daha hızlı yanıtlayabilmek de bu işin kazancı olacak.