Broadcom, VMware Workstation ve Fusion’daki 9,3 ve 8,1 puanlı iki guest kaçış açığını yamaladı

Broadcom neyi düzeltti

Broadcom, VMware Workstation ve Fusion’daki, bir sanal makine içindeki yönetici erişiminin host makinenin kendisinde kod çalıştırmaya dönüşebileceği iki güvenlik açığını yamaladı. Bildirimin dev.to’daki analizine göre Broadcom duyuruyu 7 Ekim 2026’da yayımladı; Workstation ve Fusion 25H2 ile 26H1 sürümlerini etkilenen sürümler olarak listeliyor ve her iki hatayı da 26H1u1 buildinde gideriyor.

İkisi arasında daha ağır olanı, 9,3 CVSS puanına sahip bir tamsayı taşması olan CVE-2026-59346. Bunun istismar edilmesi, VMXNET3 sanal ağ adaptörüyle yapılandırılmış bir sanal makinede halihazırda yerel yönetici ayrıcalıklarına sahip kötü niyetli bir aktör gerektiriyor. İkincisi, HGFS’teki ve 8,1 puanıyla derecelendirilmiş, yığın tabanlı bir tampon taşması olan CVE-2026-59347 ise guest içindeki yerel yönetici ayrıcalıkları ön koşuluna sahip ve host üzerinde çalışan VMX süreci olarak kod çalıştırmayla sonuçlanıyor.

Her iki saldırı vektörü de yerel olduğundan saldırgan guest içinden başlamak zorunda. dev.to yazısı, bu ön koşulun tam da bir masaüstü hypervisor’daki hatanın kişisel cihaz politikası değil, kurumsal yama yönetimi kapsamına girmesinin nedeni olduğunu savunuyor.

Ön koşul build ortamlarında rutindir

Yazı, bu ürünlerin bireysel dizüstü bilgisayarlarla sınırlı olmadığına dikkat çekiyor. Workstation’ın, birkaç sanal makinenin tek bir hesap altında çalıştığı build sunucularında ve test hostlarında da çalıştığını, Apple donanımındaki Fusion’ın ise platform ekipleri tarafından üretim bileşenlerini yerel olarak yansıtmak için, çoğu zaman gerçek sistemlere erişebilen kimlik bilgileriyle kullanıldığını belirtiyor.

Her iki senaryoda da bildirimdeki ön koşul — guest içindeki yönetici hakları — tasarım gereği zaten sağlanıyor. Build agent’ları normalde yönetici olarak çalışır ve bir geliştiricinin test sanal makinesi genellikle o geliştiricinin gerçekten kullandığı kimlik bilgilerini taşır. Dolayısıyla bu açıkların gündeme getirdiği soru, bir guest’in ele geçirilip geçirilmediği değil, guest ile host arasındaki izolasyon sınırının gerçekten tutup tutmadığıdır.

Kaçışlar nasıl çalışıyor

Analize göre her iki hata da hypervisor kaçışının tanıdık örüntüsünü izliyor: host üzerindeki bir aygıt emülasyon katmanı, ayrıcalıklı bir guest’in denetlediği girdiyi ayrıştırıyor ve o ayrıştırıcıdaki bir bellek güvenliği hatası sınırı aşıyor.

HGFS durumunda, paylaşılan klasörler mekanizması host ile guest arasında dosya alışverişini sağlayan kanaldır; ona erişen guest tarafı kodu host tarafındaki ayrıştırma koduna erişir ve o ayrıştırıcıdaki bir yığın taşması bir host ele geçirmesi anlamına gelir. VMXNET3 durumunda ise bu adaptör, Windows guest’lerin varsayılan olarak kullandığı paravirtualize ağ adaptörüdür ve bir guest yöneticisi guest’in kendi ağ sürücüsünü denetler — tamsayı taşmasının tetiklenebileceği konum budur. VMX süreci host tarafında bir bileşendir; dolayısıyla oradaki kod çalıştırma host üzerinde kod çalıştırma demektir.

Yapılandırmalar ve yama kontrolleri

dev.to yazısı, maruziyeti değerlendirmek için somut sorular öneriyor: HGFS paylaşılan klasörlerinin etkin ama kullanılmamış olması, her guest’in hangi ağ adaptörünü kullandığı, her guest içinde kimlerin yönetici erişimi olduğu ve host’un domain’e katılıp katılmadığı ya da üretim sistemleri için kimlik bilgileri taşıyıp taşımadığı. Farklı ekipler için beş sanal makine çalıştıran bir host, birkaç kişinin etkileyebileceği bir hosttur ve üretime giden bir SSH anahtarı tutan bir geliştirici makinesi, konteynırlanmış tek cihazlık bir varlık olarak görülemez.

Düzeltmeyi doğrulamak bir testten çok sürüm kontrolüdür: her iki üründeki About iletişim kutusu build numarasını gösterir ve bildirim, ürün başına düzeltilmiş buildi belirtir. Yönetilen filolar için kurulu sürüm üzerindeki bir envanter sorgusu ilgili listeyi verir — ancak yazı, masaüstü uygulamalarının çoğu zaman sunucu odaklı yama raporlamasının dışında kaldığına ve dizüstü hypervisor’ların bunun ders kitabı örneği olduğuna dikkat çekiyor. Workstation’ın satıcı indirmesinden kurulduğu ve yalnızca bir bildirim göründüğünde güncellendiği hostlarda ise yama durumu hiçbir şekilde doğrulanamaz.

Yazı ayrıca bir olay müdahalesi kaygısına da değiniyor. VMX sürecinin günlüğü olan vmware.log, her sanal makinenin aygıt etkinliğini kaydeder ve ele geçirilen host üzerinde VM’nin dosyalarının yanında durur. Paylaşılan bir iş istasyonunda bu günlükler genellikle guest’i işleten kişinin erişemeyeceği bir yerde toplanmaz; bu nedenle bir host ele geçirmesi, kullanılabilir bir kayıt olmadan açıklanamayan host davranışı olarak ortaya çıkabilir.

Neden önemli

Bunlar uzaktan istismar edilebilir açıklar değil ve asıl önemli nokta da tam olarak bu. Kurumsal build ve geliştirme ortamlarında saldırganın guest içinde ihtiyaç duyduğu yönetici erişimi, istisnadan çok normal durumdur; bu da iş istasyonu sınıfı bir hatayı paylaşımlı altyapıda guest’ten host’a bir kaçış yoluna dönüştürür. Workstation ya da Fusion’ı build sunucularında, test hostlarında veya üretim kimlik bilgileri olan geliştirici makinelerinde çalıştıran her kurum, bu ürünlerin nerede kurulu olduğunu envanterlemeli, etkilenen hostları 26H1u1’e geçirmeli ve bir kaçışı ortaya çıkaracak günlüklerin guest’in erişemeyeceği bir yerde saklanıp saklanmadığını kontrol etmelidir.