← Tüm gündem

Güvenlik uyarısı · 31 Eki 2026

PHP2Shell: bu hafta neyi patch'lemeli?

İki kritik PHP açığı remote code execution'a izin veriyor ve sömürülüyor. Düzeltilen sürümler, PHP'nizi nasıl bulacağınız ve geçici önlemler.

Son doğrulama
31 Eki 2026
CVE
CVE-2026-109618, CVE-2026-109619, CVE-2026-115560
Durum
PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 ile düzeltildi. Saldırı denemeleri raporlandı.

Ne oldu?

PHP ekibi 21 Ekim 2026’da PHP core interpreter’daki iki açık için acil güvenlik güncellemesi yayınladı. İkisi de kritik (CVSS v4.0 skoru 9.2). Kimlik doğrulaması olmayan bir saldırgan sunucuda kod çalıştırabilir.

  • CVE-2026-109618: Out-of-memory durumunu yanlış yöneten bir açık. İstek verisi yarım başlatılmış halde kalabilir.
  • CVE-2026-109619: Stale state açığı. Aynı worker’daki sonraki bir istek, daha önce serbest bırakılmış istek durumunu kullanabilir.

Saldırganlar beklemedi. Amazon’un honeypot’ları açıklamadan dört gün önce, 17 Ekim’de bir saldırı denemesi kaydetti. Cloudflare 22 Ekim’e kadar denemelerin milyonlara çıktığını bildirdi. Bazı kampanyalar Mirai botnet varyantı kurmaya çalışıyor.

Kimler etkileniyor?

Web isteği karşılayan her PHP: PHP-FPM, mod_php ile Apache, php-cgi, FrankenPHP ve LiteSpeed. Google, PHP 5.4’ten 8.5.11’e kadar tüm sürümleri etkilenmiş olarak listeliyor. Google Cloud’un kendisi açık değil ama üzerinde çalıştırdığınız PHP uygulamaları açık olabilir.

Branch Düzeltilen sürüm
8.5 8.5.12
8.4 8.4.27
8.3 8.3.36
8.2 8.2.35
8.1 ve eski Fix yok. 8.2 veya üstüne geçin.

Bu hafta yapılacaklar

1. Çalıştırdığınız tüm PHP’leri bulun. Sadece sunucular değil. Container image’larına, base image’lara, CI runner’larına, WordPress ve Drupal host’larına ve managed platformlara da bakın.

# Sunucuda
php -v

# Bir image içinde
docker run --rm your-image:tag php -v

# Kubernetes: hangi pod PHP image'ı çalıştırıyor
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' | grep -i php

2. Güncelleyin ve restart edin. Yeni paketi kurmak yetmez. Yamalı binary’nin yüklenmesi için PHP-FPM, Apache veya FrankenPHP’yi yeniden başlatın.

3. Google Cloud’da kullandığınız servise göre ilerleyin.

Servis Yapmanız gereken
App Engine standard PHP 8.2+ runtime’ları otomatik yamalanır. PHP 8.1 ve eskisinde upgrade edip yeniden deploy edin.
App Engine flexible Otomatik yamalanmaz. Desteklenen bir runtime ile yeniden deploy edin.
Cloud Run ve Cloud Run functions Yalnızca otomatik base image güncellemesi açıksa kendiliğinden yamalanır. Değilse rebuild edip yeniden deploy edin.
GKE Container image’ı düzeltilmiş PHP sürümüne güncelleyip pod’ları yeniden deploy edin.
VM’ler ve kendi build’iniz olan container’lar PHP’yi güncelleyin, sonra web process’ini restart edin.

4. Bugün patch atamıyorsanız önce riski azaltın. Bu ayarlar PHP’nin duyurusundan ve Google’ın önerilerinden geliyor. Patch’in yerini tutmaz.

session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 4M
max_input_vars = 250
max_file_uploads = 10
expose_php = Off
display_errors = Off

Edge tarafında, upload almayan route’larda multipart/form-data isteklerini engelleyin, request body boyutunu sınırlayın ve Cloud Armor’da File Upload ve RFI managed kurallarını enforce modunda açın. Cloud Armor’a bir body size limit kuralı da ekleyin ki büyük payload’lar incelenmeden geçmesin.

5. Sınırlayın ve izleyin. PHP worker’larını yetkisiz bir kullanıcıyla, read-only document root ve cgroup memory limit ile çalıştırın. PHP sunucularından dışarı internet erişimini kapatın. 17 Ekim’den beri log’larda alışılmadık multipart POST isteklerini arayın. Bir host’tan şüphelenirseniz restart etmeden önce memory dump alın.

Üçüncü ve ayrı bir konu

23 Ekim’de PHP, CVE-2026-115560 için bir duyuru yayınladı. 21 Ekim sürümleri bunu düzeltmiyor. PHP riski düşük görüyor ve şimdilik sömürü raporlanmadı.

Yalnızca şu üç koşulu birden sağlayan uygulamaları etkiliyor: session.serialize_handler ayarı php_binary veya php_serialize olmalı, uygulama session_start() öncesinde ini_set() ile bunu php yapmalı ve session upload progress açık olmalı. PHP bunu normal bir bugfix sürümünde düzeltecek. session.upload_progress.enabled=0 ayarı bunu da kapatıyor. 4. adımı uyguladıysanız ek bir şey gerekmez.

Nasıl yardımcı olabiliriz?

Kaç PHP sürümü çalıştırdığınızdan ya da nerede çalıştığından emin değilseniz, önce bunu çözmek gerekir. AWS, Azure ve Google Cloud’daki PHP envanterinizi çıkarabilir, patch’leri uygulayabilir ve geçici önlemleri devreye alabiliriz. Aşağıdaki butondan bir görüşme ayarlayın.

Kaynaklar

  1. Google Cloud: Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619
  2. CISA uyarısı: Critical vulnerabilities in PHP require immediate patching (21 Ekim 2026)
  3. The Hacker News: PHP warns of another unpatched RCE risk
  4. The Hacker News: PHP issues emergency patches for two critical PHP2Shell flaws
  5. PHP 8.4.27 release duyurusu

Sizi yavaşlatan ne?

Senior bir mühendisle 30 dakikalık görüşme. Sonraki adım biz olsak da olmasak da, net bir yol haritasıyla ayrılırsınız.

Görüşme planla