VMware vCenter Kritik Açığı: Acil Yama Uyarısı 2026
inceledim ve ikisinin de CVSS puanı 9.8; yani kritik eşiğin tam tepesinde.
Daha da önemlisi, bu açıklar artık teorik değil: bağımsız güvenlik firmalarının raporlarına
göre Ağustos 2026’dan itibaren vahşi doğada (in-the-wild) aktif olarak sömürülüyor ve kamuya
açık bir PoC (kanıt kodu) dolaşımda.

sürümler. Kaynak: Broadcom VMSA-2026-0006 + CISA KEV + bağımsız güvenlik raporları;
İki açığı şöyle ayırıyorum:
- CVE-2026-59310 — vCenter Syslog bileşenindeki dizin geçişi (CWE-22)
açığı. Bir saldırgan, kimlik doğrulaması olmadan, yalnızca ağ erişimiyle uzaktan
kod çalıştırabiliyor (RCE). Benim için listenin bir numarası bu; çünkü ön koşul neredeyse
yok. - CVE-2026-59309 — VMware Directory Service tarafındaki kimlik doğrulama
atlatma (CWE-303) açığı. Yetkisiz bir saldırgana doğrudan vCenter yönetim düzlemine erişim
kapısı açıyor.
Gözlemlenen saldırı deseninde ilk aşamanın, kalıcılık için reverse_ssh gibi
açık kaynaklı bir ters kabuk aracının yerleştirilmesi olduğu raporlandı. Yani açık yalnızca
“patlayıp geçmiyor”; saldırgan ortamda tutunmaya çalışıyor. Bir şeyi netleştireyim: Ben bu
açıkları kendi laboratuvarımda istismar edip test etmedim; bu değerlendirme resmî Broadcom
bülteni ile bağımsız güvenlik firmalarının (QUIRSO, Greenbone, Shadowserver gibi) kamuya
açık raporlarına dayanıyor. “47 ülke / yüzlerce IP” gibi ölçek rakamları ise tek bir güvenlik
firmasının telemetrisinden geliyor; bunları doğrulanmış mutlak gerçek değil, ciddiye alınması
gereken güçlü bir sinyal olarak okuyorum.
Hangi sürümdeysem ne yapmalıyım?
Broadcom açıkça “workaround yok” diyor; tek gerçek çözüm yama. Kontrol ettiğim güvenli
sürüm eşikleri şunlar:
| Ürün / Dal | Güvenli sürüm |
|---|---|
| vCenter 9.1.x | 9.1.0.0300 |
| vCenter 9.0.x | 9.0.2.0100 |
| vCenter 8.0 | 8.0 U3k |
| Cloud Foundation 5.x | 8.0 U3k’ya async yama |
| Telco Cloud Platform / Infrastructure | Broadcom KB449886 |
Benim iş yüküme göre pratik sıralamam şöyle: önce internete ya da geniş yönetim VLAN’ına
açık vCenter’ları yamalıyorum, sonra iç segmenttekileri. Mevcut sürümü hızlıca teyit etmek
için şunu kullanıyorum:
# vCenter sürümünü SSH üzerinden teyit
vpxd -v
# Veya API ile (yetkili erişim gerektirir)
curl -sk https://VCENTER_FQDN/api/appliance/system/version \
-u 'administrator@vsphere.local'
Yamadan önce mutlaka yedek/snapshot aldığımı ve varsa U3k gibi bir güncellemenin
bağımlılıklarını (ESXi uyumluluğu, eklenti sürümleri) Broadcom uyumluluk matrisinden
kontrol ettiğimi de ekleyeyim. CVE-2026-59310’un CISA KEV listesine girdiği bildirildi;
bu, kamu kurumlarıyla çalışan ekipler için sıkı bir yama takvimi anlamına geliyor.
Donanım tarafı: AMD EPYC “Venice” (Zen 6) sahneye çıkıyor
Güvenlik telaşının ortasında, veri merkezi tarafında da dönüm noktası niteliğinde bir
gelişme var: AMD’nin Zen 6 mimarili yeni nesil sunucu işlemcisi EPYC “Venice”.
SP7 ailesinin 2026’nın 4. çeyreğinde, SP8’in ise 2027’nin ilk yarısında geleceği duyuruldu.
Rakamları incelediğimde en çok dikkatimi çeken, soket başına 256 Zen 6 çekirdeğe
(512 iş parçacığı) kadar çıkan yoğunluk ve TSMC’nin 2 nm (N2) üretim sürecine geçiş oldu.

“Turin”e göre). Kaynak: AMD duyuruları + bağımsız teknoloji basını
AMD’nin paylaştığı performans rakamları iştah açıcı: önceki nesil “Turin”e kıyasla saniyede
işlenen token’da 1.8x’e, watt başına ajan (agent/watt) metriğinde 1.7x’e kadar iyileşme.
Burada mühendislik refleksimi devreye sokuyorum: bu değerler AMD’nin kendi testlerinden
geliyor, yani üretici iddiasıdır. Gerçek konumlandırmayı görmek için bağımsız testleri
ve kendi iş yüklerinizdeki ölçümleri beklemek gerekir. Yine de yön belli: üretici artık işlemciyi
ham çekirdek sayısıyla değil, “watt başına kaç AI ajanı koşturabilirsin” diliyle pazarlıyor.
Bu beni doğrudan bir önceki başlığa bağlıyor. Çekirdek yoğunluğunun artması, sanallaştırma
mimarları için bir konsolidasyon fırsatı: daha az fiziksel soket, daha az rack, ve Broadcom’un
çekirdek bazlı yeni lisans modelinde potansiyel olarak daha iyi yönetilen bir maliyet. Ama aynı
madalyonun diğer yüzü de var: tek bir hipervizöre daha fazla iş yükü yığmak, yukarıda anlattığım
gibi bir vCenter/ESXi açığında “patlama yarıçapını” (blast radius) büyütür. Yani yoğunlaştırırken
yama disiplinini ve segmentasyonu gevşetme lüksümüz yok.
Yapay zekâ araçları ve nasıl yapılır: Ajan destekli CVE triyajı
Yapay zekâ tarafında bu sonbaharın ana teması, sohbet asistanlarından “ajan” (agent) odaklı
araçlara geçiş. Büyük sağlayıcıların son nesil modelleri (ör. Claude 5.5 ailesi, GPT ve Gemini’nin
güncel sürümleri) artık tek seferlik yanıt vermek yerine, bir görevi adım adım planlayıp araçları
kendileri çağırabiliyor. EPYC Venice’in “agent/watt” vurgusuyla aynı dalgayı sörfliyorlar; donanım
ve yazılım aynı yöne bakıyor.
Peki bu bir sistem mühendisinin bugünkü işine ne katıyor? Somut bir örnek vereyim: yukarıdaki
VMware açığı gibi bir durumda, filodaki onlarca vCenter’ın sürümünü toplayıp güvenli eşikle
karşılaştıran ve riskli olanları önceliklendiren bir triyaj adımını ajan destekli bir araca
bırakabiliyorum. Henüz üretim ortamında bu araçlara kör güvenmiyorum; çıktısını her zaman kendim
doğruluyorum. Ama tekrarlı, “veri topla–karşılaştır–raporla” tipi işlerde ciddi zaman kazandırdığını
kendi akışımda gözlemledim. Mantığı yalın tutmak için şöyle bir iskelet kullanıyorum:
# Basit sürüm-triyaj iskeleti (kavramsal örnek)
# Cikti her zaman manuel dogrulanir; bu adim otomatik yama TETIKLEMEZ.
for vc in $(cat vcenter_list.txt); do
ver=$(ssh "$vc" "vpxd -v" 2>/dev/null)
echo "$vc -> $ver"
done | tee vcenter_envanter.txt
# Ardından envanteri güvenli sürüm eşiğiyle karşılaştır (9.1.0.0300 / 9.0.2.0100 / 8.0 U3k)
Türkiye açısından: Neden bizi daha çok ilgilendiriyor?
Bu haberi Türkiye’den okuyan bir mühendis için ek bir uyarı notu düşmek istiyorum. VMware
vCenter istismarına dair paylaşılan ülke dağılımında, Türkiye en çok hedeflenen ilk beş ülke
arasında gösterildi. Kamu, finans ve hosting tarafında vSphere tabanının geniş olduğu
düşünülürse, bu sürpriz değil. Eğer bir kurumda vSphere işletiyorsanız, “bize bir şey olmaz”
demeden önce yama envanterinizi bugün çıkarmanızı öneririm. Yerli bulut ve veri merkezi
yatırımları büyürken, temel hijyen olan yama disiplini hâlâ en ucuz savunma kalemi.
VMSA-2026-0006 neden bu kadar kritik?
İki açığın da CVSS puanı 9.8 ve en tehlikelisi (CVE-2026-59310) kimlik doğrulaması olmadan
uzaktan kod çalıştırmaya izin veriyor. Üstelik aktif istismar ve kamuya açık PoC söz konusu.
Geçici bir çözüm (workaround) var mı?
Hayır. Broadcom resmî olarak workaround olmadığını belirtiyor; tek çözüm güvenli sürüme
yükseltmek.
Hangi sürüme yükseltmeliyim?
vCenter 9.1.x için 9.1.0.0300, 9.0.x için 9.0.2.0100, 8.0 için 8.0 U3k. Diğer ürünler için
Broadcom KB449886’ya bakın.
EPYC Venice’i hemen almalı mıyım?
SP7 4. çeyrekte geliyor; acele bir karar değil. Performans iddiaları üretici testlerine
dayanıyor, bu yüzden bağımsız testleri ve kendi iş yükü ölçümlerinizi beklemek mantıklı.
Değerlendirmem
Bugünün tek cümlelik özeti: önce yama, sonra plan. VMware vCenter açığı,
“önemli ama acil değil” kategorisinden “bugün kapatılmalı” kategorisine çoktan geçmiş durumda;
bunu günün bir numaralı aksiyon maddesi olarak işaretliyorum. AMD EPYC Venice ise orta vadeli
bir heyecan: çekirdek yoğunluğu ve enerji verimliliği, hem konsolidasyon hem de AI iş yükleri
için umut verici, ama rakamları bağımsız testlerle teyit edene kadar temkinliyim. Yapay zekâ
ajanları da artık bir oyuncak değil; tekrarlı operasyon işlerinde gerçek verim sağlıyor, yeter ki
çıktıyı doğrulamayı elden bırakmayalım. Kısacası: yoğunlaştırırken disiplini kaybetmeyen mühendis
kazanacak.
Share this content:

Bir yanıt yazın