· kaynak dev.to (home feed)
Wazuh Manager CVE-2026-74041: büyük harf LOG_FORMAT atlatma yolu root kod çalıştırmaya götürüyor
Wazuh Manager 4.14.3 ile 4.14.7 arasındaki sürümlerde kritik bir yapılandırma doğrulaması atlatma açığı, config iznine sahip kullanıcılara root olarak komut çalıştırma imkânı veriyor; mevcut config değişikliği ve reload kayıtları bu kötüye kullanımı ortaya çıkarabiliyor.

Root ile sonuçlanan bir harf durumu boşluğu
CVE-2026-74041, 25 Ekim'de dev.to üzerinde yayımlanan bir yazıya göre Wazuh Manager'ın 4.14.3 ile 4.14.7 arasındaki sürümlerini etkileyen bir yapılandırma doğrulaması atlatma açığı. INCIBE-CERT açığı 16 Ekim 2026'da INCIBE-2026-753 olarak yayımladı ve kritik olarak derecelendirdi; yazıya göre danışma belgesi yayımlandığında herhangi bir sömürü kaydı yoktu.
Mekanizma, aynı dosyayı okuyan iki bileşen arasındaki uyuşmazlıktan kaynaklanıyor. Bir doğrulayıcı ossec.conf içindeki uzak komutları denetlerken, wazuh-logcollector aynı yapılandırmayı ayrıca okuyor ve ikisi harf durumunu farklı ele alıyor. manager:update_config iznine sahip kimliği doğrulanmış bir kullanıcı LOG_FORMAT yönergesini büyük harfle yazabilir: doğrulayıcının komut filtresi hiç devreye girmez ama collector yönergeyi yine de uygular. Manager bir dahaki seferde yeniden yüklendiğinde komut root olarak çalışır.
Ekiplerin zaten tuttuğu kayıtlardan tespit
Yazının özetlediği gibi danışma belgesi etkilenen sürümleri, gereken izni,涉及的 bileşenleri ve yönergeyi, reload sırasında root çalıştırmayı ve önem derecesini belgeliyor — ancak hiçbir kayıt satırı, komut dizisi, saldırgan aracı veya güvenlik ihlali göstergesi içermiyor. Bu nedenle bugün yazılacak herhangi bir tespit kuralı, yayımlanmış imzalar yerine sömürü mekanizmasına dayanıyor; yazar bu uyarıyı açıkça dile getiriyor.
Zincir üç gözlemlenebilir olaya bölünebilir:
- normalde yapılandırma yazmayan bir hesap tarafından ossec.conf üzerinde yapılan veya bir değişiklik penceresi dışında gerçekleştirilen bir değişiklik
- belgelenmiş örneklerden farklı bir yazımla, özellikle LOG_FORMAT yönergesi içeren eklenmiş içerik
- yapılandırma değişikliğinden kısa süre sonra manager reload veya restart işlemi
Üçüncü olay, şüpheli bir yazmayı sömürü girişimine dönüştüren şey. Reload işlemleri rutin olduğundan değeri, tek başına reload'dan değil ilk iki olayla korelasyondan gelir.
Gerçek operasyonlar için tasarlanmış uyarılar
Yazıya göre her LOG_FORMAT geçişinde tetiklenen bir kural meşru ayarlamaların içinde boğulur; yazı daha kalıcı dört alternatif öneriyor:
- hangi hesapların yapılandırma yazdığına dair bir taban çizgisi oluşturmak, sonra yazmanın kendisine değil bu taban çizgisinden sapmaya göre uyarı vermek
- onaylanmış bir pencere dışında, kısa bir aralık içinde bir yapılandırma değişikliği ve reload gerçekleştiğinde uyarı vermek
- LOG_FORMAT içeren yapılandırma içeriğinin yazımının satıcının belgelenmiş biçiminden farklı olması durumunda uyarı vermek
- host başına reload sıklığını izlemek, çünkü açıklanamayan bir artış, yapılandırma içeriği incelenmeden önce bile araştırılmaya değer
Bunların hiçbiri yükseltmenin yerini almıyor. Bu kurallar zaman kazandırır ve hem yamalanmış hem yamalanmamış ortamlarda kanıt üretir.
İzinler ve çözüm
manager:update_config kapıyı açan izin. Yazı, birçok dağıtımda bu iznin küçük bir grupta olduğunu, çoğunlukla kasıtlı bir en az ayrıcalık tasarımından ziyade operasyonel nedenlerle bulunduğunu belirtiyor ve sahip listesinin gözden geçirilmesini hem bir güvenlik açığı yönetimi adımı hem de bir tespit iyileştirmesi olarak çerçeveliyor: daha az meşru sahip, bunlardan biri olağan dışı bir şey yaptığında daha az gürültü demek.
Çözüm, Wazuh Manager 4.14.8 veya sonraki bir sürüme yükseltmek. Etkilenen aralıktaki her şey planlanmalı ve yazı, planın bu tespitlerin dayandığı kanıtı daha sonra sağlayacak olan aynı değişiklik yönetimi sisteminde yaşaması gerektiğini öneriyor.
Etkilenme rakamlarını doğru okumak
Yazı, 22 Ekim tarihli ZoomEye gözlemlerine dayanarak app="Wazuh" sorgusunun 18.031 varlıkla eşleştiğini, vul.cve="CVE-2026-74041" sorgusunun ise sıfırla eşleştiğini bildiriyor. Bu rakamlar farklı şeyleri ölçüyor: ilki Wazuh parmak izi sunan servisleri sayıyor, ikincisi CVE ile etiketlenmiş dizin girdilerini. Hiçbiri kaç host'un savunmasız bir sürüm çalıştırdığını söylemiyor; yazar, bir bulgunun yönetime iletileceği sırada bu ayrımın önemli olduğunu söylüyor.
Neden önemli
Açık, kimliği doğrulanmış bir yapılandırma yazmayı, görevi güvenlik izleme olan bir ürünün içinde root komut çalıştırmaya dönüştürüyor; bu yüzden başarılı bir kötüye kullanım, aksi halde onu tespit edecek olan aracı tehlikeye atıyor. Pratik çıkarım, sömürü yolunun görünür bir iz bırakması: bir yapılandırma değişikliği ve ardından bir reload, ikisi de çoğu Wazuh dağıtımının zaten ürettiği kayıtlarda ortaya çıkıyor. Mekanizma temelli tespitler, henüz gerçek dünya göstergesi bulunmadığı uyarısını taşıyor; bu yüzden ekipler telemetri ortaya çıktıkça kuralları rafine etmeyi beklemeli, 4.14.8 veya sonrasına yamalamalı ve hem riski hem de uyarı gürültüsünü azaltmak için manager:update_config sahip listesini daraltmalı.
- #security
- #wazuh
- #vulnerability
- #siem
- #log-analysis
İlgili yazılar
- İki npm güvenlik bülteni: fast-jwt HMAC karışıklığı ve decompress symlink dizin aşımı için dependency güncellemesi gerekiyor
- Langflow CVE-2026-105740, kayıtlı kullanıcıların stdio MCP sunucuları üzerinden rastgele bash komutu çalıştırmasına izin veriyordu
- Brotli çözücüsündeki CVE-2026-111497 zafiyeti Node.js'den Python'a, Envoy'a ve ötesine yayılıyor