VMware vCenter Açığı Aktif İstismarda

VMware vCenter: CVE-2026-59310 hâlâ aktif istismarda

Önce dürüst olayım: VMSA-2026-0006 advisory’si yeni değil — 29 Temmuz 2026’da
yayımlandı ve kritik iki vCenter açığından biri olan CVE-2026-59310, 18 Ağustos’ta
CISA’nın KEV (Known Exploited Vulnerabilities) listesine girdi. Peki neden hâlâ başa alıyorum?
Çünkü sahada yama uygulamamış vSphere ortamları duruyor ve açık aktif olarak istismar
ediliyor. Yani haber eskidi ama tehdit eskimedi. Benim bu sabahki açım tam da bu: “Sen yamanı
gerçekten geçtin mi, yoksa ‘sonra hallederim’ listesinde mi?”

Bülten beş CVE içeriyor ama kritik olan ikisi vCenter tarafında. İkisi de
kimlik doğrulaması gerektirmeden, ağdan erişebilen bir saldırganın uzaktan kod
çalıştırmasına (RCE) imkân veriyor ve CVSS skoru 9.8’e kadar çıkıyor. Yönetim düzlemine ön-kimliksiz
RCE, bir sanallaştırma yöneticisinin görebileceği en kötü senaryolardan biridir; vCenter’ı ele geçiren
bir saldırgan altındaki tüm ESX host’larına ve sanal makinelere uzanabilir.

Üçüncü sırada duran CVE-2026-47876 ise ESX’teki VMXNET3 sanal ağ kartında bir
sınır dışı yazma hatası ve sonucu bir VM escape: misafir sanal makine üzerindeki bir yönetici,
host üzerinde kod çalıştırabiliyor. Çok kiracılı (multi-tenant) ortamlar için bu kritik bir izolasyon
ihlali. Kalan iki açık (41703 bilgi sızıntısı/DoS, 41709 yetersiz loglama) görece düşük seviyede.

Resmî kaynağın net söylediği bir şey var: geçici çözüm (workaround) yok. e1000 gibi
para-sanal olmayan NIC’e geçmek dahi önerilmiyor, çünkü onların da kendi sürücü açıkları olmuş. Yani tek
gerçek çözüm güncelleme. Kendi değerlendirmem — ki bunu henüz üretim ortamında test etmedim,
değerlendirme resmî Broadcom bülteni ve Rapid7/SOCRadar/Greenbone gibi bağımsız kaynaklara dayanıyor —
şu üç adımda toplanabilir:

• vCenter’ı önce yama: Yönetim düzlemi saldırının ilk hedefi. vSphere 8 tarafında
  Broadcom en az Update 3’ü (ya da VVF/VCF 9.1’e geçişi) öneriyor.
• İnternete açık mı kontrol et: vCenter arayüzü asla doğrudan internete bakmamalı;
  Shodan benzeri bir dış görünürlük taraması iyi bir sağlık kontrolü.
• EoGS durumunu not et: vSphere 7, 2 Ekim 2025’te genel destek sonuna ulaştı. Hâlâ
  7 üzerindeyseniz bu bülten, göç planını hızlandırmak için iyi bir bahane.

Donanım: AMD Helion ve EPYC “Venice” OCP 2026’da sahneye çıktı

Günün gerçekten taze gelişmesi burada. AMD, 12 Ekim’de OCP Global Summit 2026‘da
Helion adını verdiği açık rack mimarisini tanıttı ve 6. nesil EPYC “Venice” (Zen 6)
işlemcilerini “ajan tabanlı yapay zeka” iş yükleri için konumlandırdı. Beni ilgilendiren asıl mesaj şu:
CPU rafı artık AI veri merkezinde birinci sınıf vatandaş olarak sunuluyor — yani ajanların kod
yürütmesi/orkestrasyonu için saf CPU, çıkarım (inference) için ayrı GPU katmanı.

Rakamlara bakalım, ama künyesiyle: aşağıdaki değerlerin neredeyse tamamı AMD’nin kendi
beyanı; bağımsız, nötr bir ajan-verimi testi henüz yok. CPU-öncelikli yapılandırmada rack başına
32.768 Venice çekirdeği; hepsi-bir-arada kurumsal yapılandırmada ise EPYC düğümleri +
16 adede kadar Instinct MI350P GPU (toplam 74 PFLOP FP4) ve rack başına
102 Tbps ağ bandı. Form faktörü ORv3 44OU, sıvı ve hava soğutmalı sürümleri var.
Planlanan erişilebilirlik Kasım 2026; Cisco, Dell, HPE, Lenovo, Supermicro gibi üreticiler destekliyor.

AMD, Venice’in “en iyi rakip x86’ya göre 1,8 kat token/sn” ve “Nvidia’nın 88 çekirdekli Vera’sına göre
çekirdek başına %20 daha yüksek performans” verdiğini söylüyor. Benim mühendis refleksim: bu tür
karşılaştırmalar teorik iş yükü ve güç/çekirdek aritmetiğine dayandığında, gerçek üretimdeki verimi
göstermez. Helion’u satın alma kararına bağlamak için bağımsız MLPerf benzeri sonuçları ve “token
router” denen katmanın gecikme/politika şeffaflığını beklerdim — ki AMD bunları henüz açıklamadı.
Yine de yön doğru: çok çekirdekli CPU raflarının AI orkestrasyonunda yeniden önem kazanması, kapasite
planlaması yapan herkesin radarında olmalı.

Yapay zeka araçları & nasıl yapılır: yerel LLM barındırma 2026’da olgunlaştı

Veri egemenliği ve maliyet nedeniyle en çok sorulan konu, modelleri kendi altyapında çalıştırmak.
2026 itibarıyla bu iş “deneysel” olmaktan çıktı; Ollama, vLLM,
LM Studio ve llama.cpp gibi araçlar üretim-yakını senaryolara oturdu.
Pratik ayrım basit: hızlı prototip ve tek makinede kullanım için Ollama/LM Studio, yüksek eşzamanlılık
ve sunucu tarafı çıkarım için vLLM.

Tek bir GPU’lu sunucuda hızlı başlangıç için tipik akış şöyle:

# Ollama ile tek komutla yerel model (prototip / iç araç)
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b

# Üretim-yakını, yüksek eşzamanlı çıkarım için vLLM (OpenAI-uyumlu API)
pip install vllm
vllm serve meta-llama/Llama-3.1-8B-Instruct --port 8000
# Artık http://localhost:8000/v1 üzerinden OpenAI SDK'sıyla konuşabilirsin

Not düşeyim: yukarıdaki komutlar genel kurulum akışıdır; yeni model sürümlerine dair değerlendirmelerim
resmî duyurulara ve bağımsız kaynaklara dayanıyor, her sürümü kendi lab’ımda birebir test ettiğimi iddia
etmiyorum. Mühendis gözüyle kritik olan nokta, modelin kendisinden çok etrafındaki operasyon:
GPU bellek planlaması (8B model ~16 GB VRAM ister), eşzamanlılık için vLLM’in sayfalı dikkat (paged
attention) avantajı, ve API’yi bir reverse proxy arkasında kimlik doğrulamayla yayınlamak. İç bir
“soru-cevap” aracını bir öğleden sonrada ayağa kaldırmak artık gerçekçi.

Türkiye: yapay zeka girişim sayısı 504’e çıktı

Yurt içi tarafta bu hafta öne çıkan veri, Türkiye’deki yapay zeka girişimi sayısının
504’e yükselmesi oldu (15 Ekim’de güncellenen girişim haritası). Rakamın kendisinden çok
eğilim önemli: ekosistem 500 eşiğini geçerek kritik kütleye yaklaşıyor ve bu, yerel model barındırma,
Türkçe’ye özgü veri setleri ve KVKK uyumlu altyapı taleplerini de besleyecek. Bir sistem mühendisi için
bu, “veriyi yurt içinde tut” baskısının önümüzdeki dönemde proje gereksinimlerine daha sık gireceği
anlamına geliyor — yukarıdaki yerel LLM başlığının Türkiye’de neden bu kadar konuşulduğunu da açıklıyor.

vCenter’ı hemen yamamazsam ne olur?

CVE-2026-59310 aktif istismarda ve geçici çözüm yok. Yama uygulanmamış, ağdan erişilebilir bir vCenter,
kimliksiz uzaktan kod çalıştırma riski taşır; yönetim düzleminin ele geçmesi tüm sanallaştırma ortamını
tehlikeye atar. Öncelik sırası: vCenter → ESX host’lar.

AMD Helion’un performans rakamlarına güvenebilir miyim?

Şu an için rakamların çoğu AMD’nin kendi beyanı ve teorik iş yüklerine dayanıyor. Satın alma kararı
için bağımsız MLPerf benzeri sonuçları ve token router’ın gecikme/politika şeffaflığını beklemek daha
sağlıklı.

Yerel LLM için hangi aracı seçmeliyim?

Tek makinede prototip ve iç araç için Ollama ya da LM Studio; yüksek eşzamanlılık ve sunucu tarafı
çıkarım için vLLM. Model boyutuna göre GPU belleğini (8B için ~16 GB) ve API güvenliğini planlamayı
unutmayın.

Değerlendirmem

Bugünün tek “şimdi yap” maddesi net: vCenter yamanızı gerçekten geçtiğinizden emin olun — eski bir
bülten olsa da tehdit canlı. Donanım tarafında AMD’nin Helion/Venice hamlesi, CPU raflarını AI
orkestrasyonunun merkezine koyan gerçekten taze bir gelişme; ama satın alma için bağımsız testleri
beklerim. Yazılım tarafında ise yerel LLM barındırma, Türkiye’deki veri egemenliği eğilimiyle birleşince
önümüzdeki dönemin en pratik mühendislik becerilerinden biri olacak. Kısacası: güvenlikte disiplin,
donanımda temkinli iyimserlik, yazılımda ise “kendi altyapında dene” zamanı.