1 Sunucudaki her PHP’yi bulun

Birçok sunucu birden fazla PHP çalıştırır: sistem paketi, bir kontrol paneli tarafından kurulan sürümler (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), container’lar ve cron’un kullandığı komut satırı derlemeleri. Web isteklerine hizmet eden her biri güncellenmelidir.

php -v çalıştırın, ps aux | grep php-fpm ile php-fpm süreçlerini listeleyin ve panelinizin PHP seçicisini kontrol edin.

2 Düzeltilmiş bir sürüme güncelleyin

Düzeltilmiş upstream sürümler 8.5.12, 8.4.27, 8.3.36 ve 8.2.35’tir. Dağıtım paketleri düzeltmeyi daha eski bir sürüm numarasıyla taşıyabilir — changelog’da CVE-2026-109618 ve CVE-2026-109619’u arayın.

PHP 8.1 ve öncesi PHP projesinden sürüm almıyor. Kaynaktan derleyenler için 7.4, 8.0 ve 8.1’e asgari kaynak backport’ları yayımlandı, ancak kalıcı çözüm desteklenen bir dala geçmektir.

Debian / Ubuntu (dağıtım paketleri)

Dağıtımınızın güvenlik güncellemesini kurun ve PHP’yi yeniden başlatın. Sürüm numarası aynı kalabilir; paketin changelog’u CVE’yi listeler.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

PHP modül akışınız için sağlayıcının errata güncellemesini uygulayın, ardından yeniden başlatın.

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / resmî php imajları

Düzeltilmiş etiketle çekin veya yeniden derleyin ve container’ları yeniden oluşturun.

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel, Plesk, CWP, DirectAdmin

Kurulu her PHP sürümü (EA-PHP, Plesk PHP handler’ları, alt-php, CustomBuild) için panelin güncelleme aracını kullanın, ardından PHP-FPM’i yeniden başlatın. Paneller tek tek siteler için eski sürümleri çoğu zaman kurulu tutar — onları da güncelleyin ya da kaldırın.

Paylaşımlı veya yönetilen hosting

PHP’yi genellikle kendiniz güncelleyemezsiniz. Sonuç kartındaki mesajı kullanarak sağlayıcınızdan tam sürümü, yama tarihini ve işçi süreçlerin yeniden başlatıldığına dair teyidi isteyin.

Windows / IIS

Düzeltilmiş derlemeyi windows.php.net’ten indirin, PHP dizinini değiştirin ve IIS uygulama havuzlarını geri dönüştürün (recycle).

3 Tüm PHP süreçlerini yeniden başlatın

Paket kurmak, hâlihazırda çalışan kodu değiştirmez. PHP-FPM, Apache (mod_php için), LiteSpeed, FrankenPHP, kuyruk işçileri ve supervisor’ları yeniden başlatın. Container’larda yeni imajı yeniden derleyin veya çekin — aynı imajı yeniden başlatmak yama kurmaz.

4 Doğrulayın

Her ikili dosya için php -v çalıştırın ve çalışan süreçlerin yeni derlemeyi kullandığını teyit edin (örneğin ls -l /proc/$(pgrep -o php-fpm)/exe çıktısında “deleted” görünmemeli). Ardından bu aracı tekrar çalıştırın.

5 Bugün güncelleyemiyorsanız

Güncelleyene kadar aşağıdaki kısmi önlemleri uygulayın ve siteye kimlerin erişebileceğini kısıtlayın. Bunlar riski azaltır; ortadan kaldırmaz.

6 Ele geçirilme belirtilerini kontrol edin — ve gizli bilgileri değiştirin

Açıklı bir site internetten erişilebilir durumdaysa 20 Ekim 2026 ve sonrasındaki etkinliği inceleyin: PHP-FPM veya Apache hata logunda PHP işçi çökmeleri (SIGSEGV), web kök dizininde yeni veya değiştirilmiş PHP dosyaları, yeni cron görevleri, yeni yönetici hesapları ve beklenmeyen giden bağlantılar.

CVE-2026-109619 PHP süreç belleğini hiç kod çalıştırmadan açığa çıkarabildiği için temiz bir dosya sistemi hiçbir şeyin sızmadığının kanıtı değildir. Açıkta kalan siteler için veritabanı parolalarını, API anahtarlarını, ödeme ve e-posta kimlik bilgilerini değiştirin ve kullanıcı oturumlarını geçersiz kılın.

7 Güncellemeden sonra

Düzeltme yeni bir katı bellek sınırı getiriyor: bu sınıra ulaşan süreç hemen sonlandırılır ve kapanış (shutdown) işleyicileri çalışmaz. Uygulamanızın bellek baskısı altında nasıl davrandığını kontrol edin, memory_limit değerini post_max_size ve max_input_nesting_level ile birlikte gözden geçirin ve yamadan önce geçici olarak ayarladığınız memory_limit = -1 varsa geri alın. Sürümü expose_php = Off ile gizlemek isteğe bağlı bir sıkılaştırmadır, düzeltme değildir.

Kısmi önlemler (php.net ve güvenlik duyurularından)

Bunlar yalnızca bilinen saldırı yollarını daraltır. php.net, tek güvenli seçeneğin güncellemek olduğunu belirtiyor.

; php.ini / FPM pool (php_admin_value) — ardından tüm işçi süreçleri yeniden başlatın
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M dosya yükleme gerekiyorsa
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

Bunları php.ini’de, PHP-FPM havuzunda (php_admin_value) ya da sunucu yapılandırmasında ayarlayın — ini_set() veya .user.ini ile değil — ve işçi süreçleri yeniden başlatın. Duyurulardan ve araştırma ekibinden diğer önlemler:

memory_limit = -1, PHP’nin kendi bellek sınırına dayanan bazı yolları engeller, ancak bellek tükenmesini işletim sistemine bırakır — yalnızca cgroup v2 memory.max sınırıyla birlikte kullanın. RLIMIT_AS veya RLIMIT_DATA kullanmayın; aynı açıklı yolları tetikleyebilirler.
max_input_nesting_level değerini formlarınızın izin verdiği ölçüde düşürün.
İşçi süreçlerin daha sık yenilenmesi için PHP-FPM pm.max_requests değerini düşürün (performans maliyeti vardır).
Web sunucusu veya proxy düzeyinde istek boyutu, alan sayısı ve iç içe geçme sınırları koyun; geçersiz ya da kullanımdan kaldırılmış istek başına INI ayarlarını kaldırın.
SELinux veya AppArmor politikaları, ele geçirilmiş bir işçi sürecin neleri çalıştırabileceğini sınırlayabilir — etkiyi azaltır, bellek sızıntısını önlemez.

Kaynaklar

Kaynak: php.net güvenlik duyurusu, 21 Ekim 2026. Son doğrulama: 2026-10-23.