Linux barındırma sunucularında yaygın kullanılan güvenlik paketi cPGuard’ın güncelleme kanalı, 2 Kasım 2026’da yaklaşık 70 dakikalığına ele geçirildi. Geliştirici OPSSHIELD’in 3 Kasım tarihli olay açıklamasına ve güncelleme kanalı uyarısına göre saldırgan, çalınan erişim anahtarıyla sahte bir güncelleme yükledi. Bu pencere içinde ajanı otomatik kontrol eden yaklaşık 2950 müşteri sunucusu paketi root yetkisiyle kurdu. Aynı saldırıda fatura portalından yaklaşık 7900 müşteri hesabı da kopyalandı.

cPGuard; cPanel, DirectAdmin ve Plesk yanında çalışan bir kötü amaçlı yazılım tarayıcısı ve güvenlik duvarı paketidir. Güvenlik ajanı sunucuda her şeyi görmek için root çalıştığı için sahte güncelleme de root olarak indi. Yani koruma aracı, kısa bir süre için dağıtım vektörüne dönüştü.

Kısaca

  • 1–2 Kasım 2026’da saldırgan OPSSHIELD fatura/lisans altyapısına girdi; 2 Kasım 02:04–03:20 UTC aralığında (~70 dk) sahte cPGuard güncellemesi dağıttı.
  • ~2950 müşteri sunucusu sahte güncellemeyi root olarak çalıştırdı; /etc/shadow, /etc/passwd, root SSH anahtarları, MySQL root yapılandırması, kabuk geçmişi ve bazı .s3cfg dosyaları hedeflendi.
  • ~7900 fatura portalı hesabı (ad, adres, e-posta, bcrypt parola hash’i) kopyalandı; saldırgan üç OPSSHIELD bulut sunucusunu da kopyaladı.
  • Sahte sürümler 5.88.12–5.88.19; temiz sürümler 5.88.25/5.88.26. Arka kapı izleri: /var/tmp/.cpg91511_sh ve cron /etc/cron.d/i93677.
  • IOC IP: 94.183.188.91. Adım: 5.88.25+ güncelleyin, root/SSH/veritabanı parolalarını ve anahtarlarını değiştirin.

Saldırı nasıl ilerledi?

OPSSHIELD’in kendi zaman çizelgesine göre olay 1 Kasım 15:38 UTC’de manage.opsshield.com fatura portalına yönelik keşifle başladı. 16:34’te saldırgan sahte kimlikle müşteri hesabı açıp ücretsiz deneme sipariş etti. Akşam 21:17’de deneme sürümünü kendi denetimindeki bir sunucuya kurarak lisans sunucusuyla ajan arasındaki iletişimi öğrendi. İlginç bir ayrıntı: Aynı saatlerde cPGuard, 94.183.188.91 adresini şüpheli davranış nedeniyle iki kez geçici olarak engelledi; yani ürün saldırganı kısa süreliğine durdurdu, ama engel kalıcı değildi.

22:50’de fatura portalının ödeme sağlayıcılarından gelen otomatik bildirimleri alan callback sayfalarına özel hazırlanmış istekler gönderildi. 22:58’de fatura ve lisans sunucusunda komut çalıştırma elde edildi. Şirket, tam hangi isteğin kapıyı açtığını loglarda netleştiremediğini; SSH, yönetim paneli, FTP veya API jetonu olmadığını, girişin saldırganın açtığı hesap üzerinden fatura uygulamasından geçtiğini yazıyor.

2 Kasım 02:04–02:09 arasında sahte güncelleme CDN’e yüklendi. Ajanlar 02:08’den itibaren kurmaya başladı; dağıtım yaklaşık 03:20’ye kadar sürdü. Aynı sırada, 02:13 civarında saldırgan şirketin üç bulut sunucusunun kopyasını aldı. Toplanan veriler yine OPSSHIELD lisans sunucusuna, ele geçirilmiş bir hesap üzerinden yüklendi; şirket incelemede her biri farklı bir müşteri sunucusundan gelen 32 dosyanın fiilen çekildiğini doğruladı. Bu sayı etkilenen sunucu sayısı değil; yine de OPSSHIELD, o pencerede çevrimiçi olan her sunucunun root düzeyindeki sırlarının ele geçirilmiş sayılabileceğini söylüyor.

Sunucularda ne toplandı?

Sahte betik root olarak çalıştığı için klasik “sunucu anahtarları” listesine yöneldi:

  • /etc/shadow ve /etc/passwd: yerel kullanıcı parola hash’leri.
  • /root/.ssh: authorized_keys ve known_hosts dahil root SSH malzemesi.
  • /root/.my.cnf: MariaDB/MySQL root yapılandırması; çoğu kurulumda veritabanı parolasını düz metin tutar.
  • Root kabuk geçmişi: komut satırına yapıştırılmış API jetonları, bulut anahtarları ve parolalar burada kalır.
  • Bazı sunucularda .s3cfg gibi nesne depolama kimlik bilgileri.

Diskte bırakılan izler arasında /var/tmp/.cpg91511_sh adlı gizli root kabuğu, /var/tmp/.cpg91511 toplama dizini ve /etc/cron.d/i93677 zamanlanmış görevi var. Temiz güncelleme bu izleri sildiği için dosyaların yokluğu “saldırı olmadı” kanıtı değildir; kurulum günlüklerinden 5.88.12–5.88.19 sürümüne bakmak gerekir.

Fatura tarafında kopyalanan ~7900 kayıtta ad, şirket, posta adresi, e-posta ve bcrypt ile saklanmış parola hash’leri vardı. Hash’ler düz metin değildir; yine de zayıf veya başka yerde yeniden kullanılan parolalar kırılabilir. Lisans anahtar çiftleri de risk altında sayıldığı için şirket bunları yeniden düzenlemeye başladı.

Neden önemli?

Bu olay “güvenlik yazılımındaki bir sıfır gün” değil. Saldırgan, güncellemenin meşru kaynağını ele geçirdi. İstemci tarafında imza doğru, adres doğru, paket beklenen kanaldan geliyor gibi görünür. Otomatik güncelleme ve root yetkisi birleşince tek bir dağıtım noktası binlerce sunucuya dönüşür.

Barındırma sunucusunda root SSH anahtarı çalınırsa etki o makineyle sınırlı kalmaz. Aynı anahtara güvenen diğer sunucuların authorized_keys kayıtları da hedef olur; cPGuard hiç kurulmamış olsa bile. Kabuk geçmişindeki jetonlar ve MySQL root parolası ise sitelerin, veritabanlarının ve yedeklerin kapısını açar. Bir hosting sunucusunda yüzlerce müşteri sitesi barınabilir; tedarik zinciri burada “müşterinin müşterisine” kadar iner.

BleepingComputer ve SecurityWeek olayın 12 saat içinde tespit edilip sahte dağıtımın durdurulduğunu aktarıyor. Hızlı müdahale olumlu; ama 70 dakikalık pencere, otomatik ajanların ne kadar hızlı yayılabileceğini gösteriyor.

Türkiye açısından

Türkiye’de paylaşımlı barındırma, VPS ve cPanel/DirectAdmin/Plesk panelli Linux sunucular yaygın. cPGuard gibi ajanlar çoğu zaman hosting firmasının seçimiyle kurulur; site sahibi hangi güvenlik paketinin root çalıştığını bilmeyebilir. Bu yüzden hem barındırıcı hem müşteri aynı olayda farklı sorumluluk taşır.

Kişisel veri barındıran bir sunucuda root sırları sızdıysa, 6698 sayılı Kanun kapsamında veri sorumlusu ihlali öğrendiği andan itibaren Kişisel Verileri Koruma Kurulu’na 72 saat içinde bildirim yükümlülüğü doğabilir. Ekim 2026’daki ihlal bildirimlerini KVKK Ekim 2026 dosyamızda derlemiştik; Kasım başındaki bu tedarik zinciri olayı, “güvenlik aracının kendisi vektör” başlığını o dosyaya eklenmesi gereken yeni bir kalıp olarak gösteriyor.

Küçük ve orta ölçekli hosting firmaları için ders net: Güncelleme yayın anahtarlarının fatura/müşteri paneliyle aynı güven alanında tutulmaması, deneme hesaplarından gelen trafiğin kalıcı engellenmesi ve root ajan envanterinin müşteriye açıklanması gerekir.

Ne yapmalısınız?

  • Sürümü yükseltin: cPGuard’ı 5.88.25 veya sonrasına (önerilen temiz sürüm 5.88.26) güncelleyin. Kurulum günlüklerinde 5.88.12–5.88.19 izi varsa sunucuyu ele geçirilmiş kabul edin.
  • İzleri kontrol edin: /etc/cron.d/i93677, /var/tmp/.i93677/ ve /var/tmp/.cpg91511_sh yoksa sorun değil; varsa silin ve temiz güncellemeyi doğrulayın. Yokluk tek başına temizlik kanıtı değildir.
  • Parolaları değiştirin: Root ve tüm yerel kullanıcı parolalarını temiz bir kurtarma ortamından yenileyin. MySQL/MariaDB root ve ilgili veritabanı parolalarını değiştirin.
  • SSH anahtarlarını döndürün: Yeni root SSH anahtarları üretin; eski anahtarları bu sunucuya güvenen her makineden kaldırın. Anahtarlar değişene kadar sunucuları ele geçirilmiş sayın.
  • Kabuk geçmişi ve bulut sırları: Root history’de geçen API jetonlarını, S3 anahtarlarını ve benzer sırları iptal edin. .s3cfg kullanıyorsanız kimlik bilgilerini yenileyin.
  • Fatura portalı: OPSSHIELD portal parolanızı değiştirin, iki adımlı doğrulamayı açın. Sahte güncelleme almamış olsanız bile portal hesabı kopyalanmış olabilir.
  • Yeniden kurulum: OPSSHIELD size saldırganın sunucuya elle girdiğini bildirdiyse, 1 Kasım öncesi temiz yedekten yeniden kurun.
  • Site sahipleri: Hosting sağlayıcınıza cPGuard kullanıp kullanmadığını sorun; panel ve FTP/SFTP parolalarınızı yeniden kullanıyorsanız değiştirin. Kişisel veri işliyorsanız hukuki danışmanınızla 72 saatlik bildirim eşiğini değerlendirin.
  • Ağ izleme: 94.183.188.91 adresini ve beklenmeyen outbound trafiği loglarda arayın.