CVE-2026-76266: Splunk Linux paket yükseltmeleri servis hesabı dosyalarını root olarak çalıştırabiliyor

Ne oldu

Splunk, Linux üzerindeki Splunk Enterprise'ı etkileyen yüksek önemdere sahip bir yetki yükseltme açığı olan CVE-2026-76266 için yamalar yayımladı. dev.to üzerindeki bir incelemeye göre açık, AV:L/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:H vektörüyle 7.7 CVSS:3.1 puanı taşıyor ve CWE-269, yani uygunsuz ayrıcalık yönetimi altında sınıflandırılıyor. Splunk sorunu SVD-2026-1001 danışma belgesinde belgeliyor ve NCSC'nin NCSC-2026-0412 danışma belgesi de aynı puanı listeliyor.

Özündeki güven varsayımı

Hata, Linux paket maintainer betiğinde, yani paket yöneticisinin ürünü kurarken veya yükseltirken root olarak çalıştırdığı kodda bulunuyor. dev.to analizine göre bu betik, yükseltme işlemlerini gerçekleştirirken diskte mevcut olan Splunk Enterprise kurulum içeriğine güveniyor. Sorun şu ki Splunk Enterprise'ı çalıştıran servis hesabı bu içeriğe yazabiliyor. Böylece servis hesabının kontrol ettiği bir dosya, root olarak çalışan bir süreç tarafından işleniyor ve ikisi tam olarak yükseltme anında kesişiyor.

Sömürü nasıl işliyor

Saldırı, CVSS vektöründe de görülen iki koşul gerektiriyor.

Birincisi, saldırganın zaten Splunk servis hesabı olarak komut çalıştırabilmesi gerekiyor; bu, PR:H ön koşulu. Bu düzeydeki erişim, kurulum içeriğindeki dosyaları değiştirmesine olanak tanıyor.

İkincisi, bir yöneticinin etkilenen bir Linux paketi kullanarak yükseltme başlatması gerekiyor; bu da UI:R gereksinimi. Maintainer betiği çalıştığında, kurcalanmış içeriği root ayrıcalıklarıyla işliyor ve saldırganın değişiklikleri root olarak yürütülüyor.

dev.to yazısına göre danışma belgesi tasarım niyeti konusunda açık: bu tür bir yerel kullanıcı istediği zaman yetki yükseltememeli. Beklenti bu dizinin kapalı kalmasıydı ve yamalanmış sürümler onu kapatıyor.

Etki

Başarılı bir sömürü ana makinede root erişimi sağlıyor; gizlilik, bütünlük ve erişilebilirlik açısından yüksek puanlar taşıyor. Etki alanı işletim sisteminin ötesine uzanıp Splunk'ın dizinlenmiş verilerine ve saklanan koleksiyon kimlik bilgilerine ulaşıyor; bunlar bir log toplama platformunda genellikle makinedeki en hassas veriler arasındadır.

Etkilenen sürümler ve giderim

Kaynağa göre savunmasız sürüm aralıkları şunlar:

• 10.4.0'dan 10.4.2'ye
• 10.2.0'dan 10.2.6'ya
• 10.0.0'dan 10.0.9'a
• 9.4.0'dan 9.4.14'e

Düzeltilmiş sürümler 10.4.3, 10.2.7, 10.0.10 ve 9.4.15; yöneticiler ilgili sürüme veya sonrasına yükseltmeli. Yamalayamadan önce yükseltme yapması gereken siteler için Splunk'un belgelenmiş geçici çözümü, Linux paketi yerine tar arşivinden yükseltme yapmaktır; yalnızca tar ile yönetilen kurulumlar savunmasız maintainer betiğini hiç çalıştırmaz. Yabani ortamda sömürüldüğüne dair bir rapor yok.

Neden önemli

Bu bir Splunk tuhaflığı değil, şablon bir hata. deb veya rpm paketi, container giriş noktaları, CI hook'ları ya da yükseltilmiş ayrıcalıklarla çalışan herhangi bir kurulum aracı yayımlayan herkes, dev.to yazarının önerdiği denetimi uygulamalı: root olarak çalışan her kurulum ve yükseltme adımını sıralayın, sonra bu adımlardan herhangi birinin paketin yönettiği hesap tarafından yazılabilir dosyaları okuyup okumadığını kontrol edin. Cevap evetse, yükseltme yolu aynı zamanda bir yetki yükseltme köprüsü haline geliyor ve düzeltme dokümantasyonda değil paketlemede olmalı.

Splunk dağıtımları özelinde ön koşullar egzotik değil, sıradan olaylar: servis hesabı olarak komut çalıştırma ile rutin bir yönetici tarafından başlatılan yükseltmenin birleşimi. Yama şimdi mevcut ve tar tabanlı geçici çözüm, sürümler arasında sıkışanlar için ucuz bir duraklatıcıdır.