vCenter 9.1 Yükseltmesi Öncesi Kritik Uyarı ve Kontrol

Aşağıdaki değerlendirme, resmî KB’ler ve bağımsız güvenlik kaynaklarının çapraz okumasına dayanıyor. 9.1.x yükseltmesini henüz bir laboratuvarda baştan sona test edemedim; dolayısıyla adımları “benim ortamımda şöyle oldu” diye değil, “duyurunun gerektirdiği doğru sıra budur” diye aktarıyorum.

9 Ekim uyarısı tam olarak neyi anlatıyor?

Sorunun kökeni biraz dolambaçlı, bu yüzden adım adım gidelim. Bazı ortamlarda, geçmişte vLCM/VUM deposu KB 316581’deki sıfırlama scripti ile sıfırlanmış. Bu işlem, 8.0 U3 → 9.0.x yolundan gelen sistemlerde veritabanı şemasını eksik bırakabiliyor: yerleşim politikası (placement policy) sütunları ve ilişki tabloları oluşmuyor. Tek başına bu, çalışan bir ortamda hemen belli olmuyor.

Asıl problem yükseltmede ortaya çıkıyor. 9.1.x’teki yeni LCCM alt sistemi, sistem VM’lerini bulmak için tam da bu tablolara ihtiyaç duyuyor. Şema eksikken 9.1.0 veya 9.1.1’e geçildiğinde Broadcom’un net ifadesiyle “Supervisor Kontrol Düzlemi VM’leri ve Foundation Load Balancer’lar (FLB) envanterden kaldırılıp kaybedilebiliyor” — ilgili yük dengeleyici yapılandırmasıyla birlikte. vSphere Supervisor, VKS ve FLB kullanan ortamlar risk altında.

Yükseltmeden önce yapılması gerekenler

Uyarının pratik kısmı burası ve bir sistem mühendisi için takip edilmesi gereken sıra oldukça açık:

1. Yedek alın. Yükseltme öncesi vCenter Server ve Supervisor için yedek/anlık görüntü şart. Bu, “geri dönüş planı” değil, bu senaryoda birincil kurtarma yolu.
2. Şemayı doğrulayın. KB 455737 içindeki checker scripti ile vLCM/VUM veritabanı şemasını kontrol edin. Alternatif olarak VCF Diagnostic Tool (VDT) sorun varsa [FAIL] VUM SCHEMA CHECK uyarısı veriyor.
3. Gerekirse onarın. Kontrol bir tutarsızlık işaretlerse, aynı KB’deki remediation scriptini çalıştırın. Tutarlılık onaylanmadan yükseltmeyi başlatmayın.
4. Zaten yükselttiyseniz ve VM’ler eksikse: yükseltme öncesi yedeğinizden/anlık görüntünüzden Supervisor durumunu geri yükleyin, ardından veritabanı düzeltmesini uygulayın. İzlenecek belge KB 457944.

Bu dört adımın özü tek cümlede şu: bu yükseltme, “önce yedek, sonra doğrula, en son yükselt” disiplinini gerçekten zorunlu kılan türden bir yükseltme.

Arka plan: VMSA-2026-0006 ve neden yamayı geciktirmemeli?

Bu yükseltme konuşmasının gölgesinde, yaz boyunca gündemde olan güvenlik tablosu da duruyor ve ikisini birlikte düşünmek gerekiyor. 30 Temmuz 2026’da yayımlanan VMSA-2026-0006 ile vCenter’ta iki kritik açık duyuruldu. İkisi de CVSS 9.8, ikisi de kimlik doğrulaması gerektirmiyor ve yalnızca ağ erişimiyle tetiklenebiliyor:

• CVE-2026-59309 — VMware Directory Service’te kimlik doğrulama atlatma. Saldırgan vCenter yönetim düzlemine yetkisiz erişebiliyor.
• CVE-2026-59310 — vCenter Syslog sunucusunda dizin gezinme (path traversal); ağa komşu saldırganın uzaktan kod çalıştırmasına imkân tanıyor.

Benim buradaki asıl endişem, açıkların varlığından çok zaman çizelgesi. 17 Ağustos’ta CVE-2026-59310 için kamuya açık PoC çıktı, 18 Ağustos’ta CISA bunu aktif istismar nedeniyle KEV kataloğuna ekledi ve bağımsız kaynaklara göre Eylül ortasında fidye yazılımı gruplarının bu açığı aktif kullandığı doğrulandı. Broadcom’un net ifadesi şu: bu açıklar için workaround yok, tek çözüm yama. Düzeltilmiş sürümler 9.1 hattı için 9.1.0.0300, 9.0 hattı için 9.0.2.0100 ve 8.0 için 8.0 U3k.

İki konuyu birleştirince pratik sonuç şu: Birçok ortamda hem güvenlik yaması için 9.1.x/9.0.2/8.0 U3k hattına çıkmak, hem de yukarıdaki şema kontrolünü yapmak aynı bakım penceresine denk gelecek. Dolayısıyla yama planını yaparken VUMDB kontrolünü de aynı plana koymak, iki kez ortam durdurmaktan iyi.

Sunucu ve donanım tarafında kısa not

Donanım gündemi bu hafta sakin; AMD’nin “Advancing AI 2026” lansmanı Temmuz’da geçti, bu yüzden bugün için taze bir EPYC/Instinct duyurusu yok. Mühendis açısından anlamlı olan, yukarıdaki sanallaştırma kararlarının altındaki konsolidasyon eğilimi: Broadcom sonrası lisans maliyetleri birçok ekibi çekirdek başına yoğunluğu artırmaya ve küme sayısını azaltmaya itiyor. Bu da her yükseltmenin “kaç VM’i riske atıyorum” hesabını daha kritik hale getiriyor — tam da bugünkü vCenter uyarısının neden bu kadar önemli olduğunu açıklayan nokta.

Yapay zeka araçları ve nasıl yapılır: Bir haftada çıkan yeni dalga

Sanallaştırma tarafı bugünün ana konusu olsa da, AI araç tarafında son bir hafta oldukça hareketliydi. 7–12 Ekim arasında ardı ardına yeni modeller geldi ve bunların çoğu “ajan” ve “karar” odaklı; yani bir sistem mühendisinin otomasyon akışına doğrudan girebilecek türden.

Benim buradan çıkardığım pratik “nasıl yapılır” şu: Eğer bir log sınıflandırma, bilet yönlendirme veya önceliklendirme otomasyonu kuruyorsanız, bu hafta çıkan Microsoft Decision-1 gibi “kalibre karar skoru” döndüren modeller, serbest metin üreten büyük modellerden daha öngörülebilir sonuç verir; çünkü sabit seçenekler arasında puanlıyorlar. Kodlama ajanları için açık kaynak tarafında JetBrains Mellum 2.1 (Apache 2.0, 12B MoE) kendi altyapınızda barındırılabilir olması sebebiyle ilgi çekici. Yüksek hacimli ve maliyete duyarlı işler için Claude Haiku 5.5‘in ayarlanabilir “effort” ayarı, özet ve sınıflandırma iş yüklerinde maliyet/kalite dengesi kurmak için pratik bir kol.

Bu modellerin hiçbirini henüz üretim iş yükümde uzun süreli test edemedim; buradaki yorum, resmî duyurular ve yayımlanan özelliklere dayanan bir ilk değerlendirme. Somut karşılaştırma için kendi verinizle küçük bir pilot kurmak en sağlıklısı.

Türkiye açısından

Bugün için Türkiye kaynaklı, doğrulanmış yeni bir duyuru öne çıkmadı; dolayısıyla uydurma bir haber eklemiyorum. Ama yerel bağlam net: Broadcom sonrası lisanslama, Türkiye’deki birçok kurumsal BT ekibi için bütçe gündeminin başında. Bu da yerli bulut sağlayıcılarına ve alternatif hipervizörlere ilgiyi artırıyor. Yine de çoğu kurumun kısa vadede vSphere üzerinde kalacağı gerçeği göz önüne alındığında, bugünkü yükseltme uyarısı Türkiye’deki ekipler için de birebir geçerli.

vCenter 9.1’e yükseltmeyi hemen durdurmalı mıyım?

Hayır, yükseltmeyi iptal etmek gerekmiyor. Yapılması gereken, yükseltmeden önce KB 455737 checker scripti veya VDT ile VUMDB şemasını doğrulamak. Şema temizse güvenle devam edebilirsiniz.

Bu uyarı her ortamı etkiliyor mu?

Hayır. Risk, özellikle geçmişte vLCM/VUM deposu sıfırlanmış ve vSphere Supervisor/VKS/FLB kullanan ortamlarda. Yine de kontrol scriptini çalıştırmak düşük maliyetli bir sigorta.

VMSA-2026-0006 için geçici bir çözüm (workaround) var mı?

Broadcom’a göre yok. Tek çözüm, düzeltilmiş sürüme (9.1.0.0300, 9.0.2.0100 veya 8.0 U3k) yama uygulamak. Açıklar aktif olarak istismar edildiğinden yamayı geciktirmek önerilmiyor.

Değerlendirmem

Bugünün tek cümlelik özeti: vCenter 9.1.x’e çıkacaksanız, yükseltme düğmesine basmadan önce yedeğinizi alın ve VUMDB şemasını doğrulayın. Aynı bakım penceresinde VMSA-2026-0006 yamasını da uygulayın, çünkü o açıklar için beklemenin karşılığı giderek artıyor. Donanım ve Türkiye tarafında bugün taze bir kırılma yok; AI tarafındaki yeni model dalgası ise otomasyon kuran ekipler için izlenmeye değer ama acele karar gerektirmiyor. Benim önceliğim bu sabah net: önce sanal altyapıyı güvene al, sonra yeni araçlarla deney yap.