PHP CVE-2026-109618 ve CVE-2026-109619

PHP çekirdek motorunun anormal sonlandırılması ve istek durumu yönetimi sırasında, kimlik doğrulama olmadan uzaktan kod yürütmeye (RCE) olanak tanıyan CVE-2026-109618 ve CVE-2026-109619 güvenlik açıkları yayımlandı. Bu sorun WordPress veya GNUBoard gibi web uygulamalarından değil, PHP yürütme motorunun bellek bozulması ve serbest bırakılmış belleğin yeniden kullanılması (Use-After-Free) kusurlarından kaynaklanır. Sorunu gidermek için PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 gibi güvenlik yamalarının uygulandığı sürümlere hemen yükseltme yapmalı ve worker süreçlerini yeniden başlatmalısınız.

Yalnızca web uygulamasını güncelleyerek engellenemeyen PHP motoru güvenlik açığı

21 Ekim 2026'da (UTC), PHP geliştirme ekibi CVSS v4.0'a göre 9,2 risk puanıyla duyurulan iki güvenlik açığını yayımladı. Saldırganlar, ayrı bir oturum açma işlemi olmadan yalnızca hazırlanmış bir HTTP isteği göndererek sunucuda istedikleri kodu çalıştırabilir.

Bu kusurlar, web isteklerini ayrıştıran ve belleği temizleyen PHP çekirdek katmanında çalışır. Bu nedenle sitenin CMS'sini veya eklentilerini güncel tutsanız bile PHP çalışma zamanı eski sürümse saldırıya maruz kalırsınız. Özellikle Apache'nin mod_php varsayılan yapılandırmasının kullanıldığı ortamlarda, web uygulaması kodu çalıştırılmadan önce tek bir istekle kod yürütmenin mümkün olduğu doğrulanmıştır.

Saldırı başarılı olursa saldırgan, PHP sürecinin çalıştığı sistem hesabının yetkilerini elde eder. Bu durum doğrudan root yetkisinin ele geçirilmesi anlamına gelmez; ancak web kök dizininde bir webshell oluşturabilir veya yapılandırma dosyalarında kayıtlı veritabanı bağlantı bilgilerini okuyarak dahili verileri sızdırabilir ve değiştirebilir. Tek bir sunucuda birden fazla web sitesi aynı PHP-FPM yürütme hesabını paylaşıyorsa, bir sitenin ihlalinin sunucudaki diğer sitelere yayılma riski de vardır.

Anormal sonlandırmada bellek bozulması ve serbest bırakılmış belleğin yeniden kullanılması

Her iki güvenlik açığı da istek işlenirken olağan dışı bir durum oluştuğunda belleğin güvenli biçimde temizlenememesinden kaynaklanır. Oluşma koşulları ve dahili çalışma ilkeleri birbirinden farklıdır.

CVE-2026-109618 (bellek sınırı aşımı işlenirken oluşan bellek bozulması): PHP, bir isteği işlerken izin verilen bellek sınırını (Out-Of-Memory) aşarsa yürütmeyi hemen durdurmak için longjmp() çağrısı yapar. Bu sırada dahili istek veri yapıları henüz tamamen başlatılmamışken işlem durursa, eksik durum geri alınmadan kalır. Daha sonra çalışan istek temizleme (cleanup) rutini, başlatılmamış bu belleğe normal veri olarak güvenip eriştiğinde bellek bozulması ve uzaktan kod yürütme ortaya çıkar.

CVE-2026-109619 (önceki isteğin serbest bırakılmış belleğine başvuran Use-After-Free): PHP içindeki bazı genel durumlar veya hata işleme durumları, tek bir isteğin sahip olduğu bellek alanını geçici olarak gösterir. Kritik hata (fatal error) veya bellek yetersizliği nedeniyle istek anormal biçimde sonlandırıldığında gerçek bellek serbest bırakılmış olsa da, onu gösteren dahili işaretçi başvurusu başlatılmadan kalabilir. PHP-FPM veya mod_php gibi worker süreçlerinin yeniden kullanıldığı ortamlarda aynı worker bir sonraki HTTP isteğini aldığında, daha önce serbest bırakılmış bellek alanını yeniden okuyarak (Use-After-Free) kod yürütme yolu oluşturur.

Resmî güvenlik duyurusu, CVE-2026-109619 için doğrulanan yollar olarak oturum yükleme ilerleme özelliğini (session.upload_progress), istek başlatılmadan önce görüntülenen yapılandırma uyarılarını ve PHP 8.5'in kritik hata geri izlemelerini (fatal_error_backtraces) belirtir. Ancak bu yollar engellense bile başka varyant yolların kalacağını da açıklar.

PHP sürümlerine göre yama durumu ve yürütme ortamına göre etki alanı

Yamalı sürümlerden daha eski PHP 8.2–8.5 sürümleri etkilenir; desteği sona eren 8.1 ve daha eski sürümler ise PHP projesinin resmî güncelleme kapsamına girmez. Yürütme yöntemleri açısından PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed ve web isteklerini işleyen diğer tüm kurulumlar kapsam dahilindedir. Resmî duyuru bunlar arasında mod_php için riski en yüksek olarak değerlendirir. Red Hat, PHP-FPM'nin uygulama aşamasındaki yollar üzerinden koşullu olarak etkilendiğini sınıflandırır.

Doğrulanan ortam: 22 Ekim 2026 itibarıyla Remi deposunu kullanan bir Linux sunucusu ortamında PHP 8.4.26 sürümü 8.4.27'ye yükseltildi; PHP-FPM worker yeniden başlatması ve web isteklerine yansıması doğrulandı.

Paket güncellemesi ve PHP-FPM azaltma ayarlarının uygulanması

PHP geliştirme ekibi, yalnızca yapılandırma değişiklikleriyle tüm saldırı yollarının engellenemeyeceğini ve yama sürümüne güncellemenin tek ve eksiksiz çözüm olduğunu bildirir. Güncellemeden sonra da saldırı yüzeyini azaltmak için gereksiz özellikleri kapatan azaltma önlemlerini birlikte uygulayabilirsiniz.

1. PHP paket güncellemesini yükleme
   İşletim sistemi paket yöneticisi aracılığıyla kullandığınız PHP serisinin yama sürümüne (8.4 serisi için 8.4.27) yükseltme yapın. Kurulumdan sonra önce terminalde CLI sürümünü kontrol edin.

   php -v

   Komut çalıştırıldığında ekranda PHP 8.4.27 (cli) gibi güncellenmiş sürüm numarası ve derleme tarihi görüntülenir. Ancak CLI sürümü ile web sunucusunun bağlandığı PHP sürecinin sürüm durumu farklı olabilir; bu nedenle sonraki adımı mutlaka uygulamalısınız.

2. Saldırı yüzeyini azaltmak için PHP-FPM ayarlarını düzenleme (isteğe bağlı ve geçici azaltma)
   Güncellemeyi hemen uygulamak zorsa veya ek bir savunma katmanı eklemek istiyorsanız php.ini ya da PHP-FPM havuz yapılandırma dosyasını (örneğin /etc/php-fpm.d/www.conf) yedekledikten sonra aşağıdaki öğeleri düzenleyin.

   php_admin_value[session.upload_progress.enabled] = Off
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 30M

   session.upload_progress.enabled devre dışı bırakıldığında doğrulanmış oturum tabanlı saldırı yolu engellenebilir. post_max_size değerini düşürmek (dosya yüklemenin gerekmediği ortamlarda 8M, gerektiği ortamlarda 32M gibi), büyük isteklerle bellek tükenmesine yol açma girişimlerini zorlaştırır. Bu sırada multipart ek üstbilgilerinin boyutunu dikkate alarak upload_max_filesize değerini post_max_size değerinden biraz düşük belirleyin. PHP 8.5 ortamında fatal_error_backtraces = 0 ayarını da uygulayın.

3. PHP-FPM yapılandırma söz dizimi denetimi ve süreçlerin yeniden başlatılması
   Yapılandırmayı kaydettikten sonra söz dizimi hatası olmadığını test edin ve PHP-FPM hizmetini yeniden başlatın.

   php-fpm -t
   systemctl restart php-fpm

   php-fpm -t çalıştırıldığında yapılandırmada sorun yoksa ekranda NOTICE: configuration file ... test is successful mesajı görüntülenir. Worker süreçleri yeniden başlatılmalıdır; böylece bellekte bulunan eski sürüm worker'lar sonlandırılır ve yeni yama ile ayarlar uygulanır.

4. Gerçek uygulanan sürümü web isteği üzerinden doğrulama
   WordPress'in 'Site Health' bilgi sekmesini veya web sunucusu entegrasyon tanılama sayfasını çağırarak web isteklerini işleyen PHP-FPM worker'ın 8.4.27 gibi yamalı sürümle yanıt verdiğini kontrol edin. Doğrulama amacıyla geçici olarak oluşturulmuş bir tanılama PHP dosyası varsa, sistem bilgilerinin dışarıya sızmaması için kontrolün hemen ardından silin.

Güncelleme gecikmesi veya ayar değişikliklerinin yan etkileri oluştuğunda yapılacaklar

Üçüncü taraf deposunun (Remi vb.) yansıtma işlemi geciktiği ve paket indirilemediği durumlar

Acil güvenlik yamasından hemen sonra trafik yoğunluğu veya eşitleme gecikmesi nedeniyle üçüncü taraf depolarında (örneğin rpms.remirepo.net) güncelleme paketleri hemen görüntülenemeyebilir ya da indirme hızı düşük olabilir. Resmî duyuru, gönüllüler tarafından işletilen bu depoya duyuru günü güncelleme yüklenmeyebileceğini belirtir ve dağıtım paketlerine veya kaynak derlemeye geçilmesini önerir.

Bu durumda depo ayarlarından eşitlemesi tamamlanmış ve normal hızda çalışan bir yansıtma sunucusunun adresini doğrudan belirterek güncellemeyi sürdürebilirsiniz. Yansıtmayı manuel olarak değiştirseniz bile paket kurcalamasını önlemek için GPG imza denetimini (gpgcheck=1) etkin tutmalısınız. Yansıtma kullanılamıyorsa işletim sistemi dağıtımının resmî backport paketlerini kullanın veya kaynak kodunu doğrudan derleyerek uygulayın.

Azaltma ayarları uygulanırken bellek yetersizliği (OOM) veya yükleme reddi konusunda endişeler

Resmî duyuru, hemen güncelleme yapılamadığında CVE-2026-109618 için azaltma önlemi olarak memory_limit = -1 (sınırsız) değerini önerir ve bu durumda kapsayıcı veya cgroup bellek sınırlarının birlikte kullanılmasını bildirir. Ancak fiziksel belleği yeterli olmayan bir sunucuda bellek sınırını kaldırmak, tek bir isteğin sunucu belleğinin tamamını tüketmesine ve işletim sisteminin OOM Killer'ının temel daemon'ları zorla sonlandırmasına neden olabilir. Bu ayar, güncelleme yapılana kadar geçici bir önlemdir; yama sürümüne güncelledikten sonra özgün bellek sınırına dönmek güvenlidir.

Ayrıca post_max_size değerini mevcut değerinden (örneğin 64MB) düşürürken sitenin dosya aktarım yöntemini önceden kontrol etmelisiniz. Yönetici web sayfası üzerinden büyük yedek dosyaları veya eklentileri doğrudan yükleyen sitelerde istekler engellenebilir. Buna karşılık büyük dosyaların SFTP veya rsync ile aktarıldığı ortamlarda ya da uygulamanın kendi sınırı zaten 30MB veya daha düşük olarak ayarlanmışsa PHP yükleme sınırını 32MB'ye düşürmenin hizmete etkisi olmaz.

Öte yandan PHP sürümünü yükselttikten sonra PHP-FPM worker'ları zaman zaman anormal biçimde sonlanıyorsa OPcache'in JIT (Just-In-Time) derleme ayarını inceleyebilirsiniz. JIT özelliği (örneğin opcache.jit=1255) bu güvenlik açığıyla doğrudan ilişkili değildir; ancak sürüm değişiklikleri sırasında kararlılık sorunlarına yol açtığı biliniyorsa çakışmaları önlemek için yapılandırma dosyasında opcache.jit=off ile devre dışı bırakılabilir.

Sık sorulan sorular

WordPress'i veya eklentileri en son sürüme güncellemek sorunu çözer mi?

Çözmez. Bu güvenlik açığı, WordPress veya güvenlik eklentileri çalıştırılmadan önceki aşama olan PHP çekirdek motorunda oluşur. Web uygulaması güvenlik duvarı (Cloudflare, AWS WAF vb.) aracılığıyla bilinen saldırı kalıplarını geçici olarak engelleyebilirsiniz; ancak temel çözüm için barındırma sağlayıcısı veya sunucu yöneticisi aracılığıyla sunucunun PHP sürümünü güncellemeniz gerekir.

session.upload_progress.enabled ayarını kapatırsam güncelleme yapmadan güvende olur muyum?

Güvende olmazsınız. Resmî duyuru, bu ayarın yalnızca doğrulanmış oturum yolunu engellediğini, diğer varyant yolları engelleyemediğini belirtir. Ayrıca ayar ini_set() veya FPM'nin .user.ini dosyasında değil, php.ini, FPM havuzu ya da sunucu ayarları gibi istek ayrıştırılmadan önce uygulanan bir yerde bulunmalı ve tüm worker'lar yeniden başlatılmalıdır. Eksiksiz çözüm yalnızca yamayı yüklemektir.

Yama uygulaması tamamlandıysa ek denetim yapmadan hemen işletime geçebilir miyim?

Güncelleme gelecekteki saldırıları engeller; ancak daha önce ihlal edilip edilmediğini göstermez. Güncellemeyi tamamladıktan sonra geçmişte ihlal olup olmadığını ayrıca kontrol etmeniz önerilir. Web dizininde yakın zamanda olağan dışı biçimde oluşturulmuş veya değiştirilmiş PHP dosyaları (webshell gibi) olup olmadığını kontrol edin; web sunucusu erişim günlüklerinde ve PHP hata günlüklerinde olağan dışı büyük POST isteklerini veya yinelenen bellek hatalarını araştırın.

Kapsayıcı veya bulut imajı ortamlarında nasıl karşılık verilmelidir?

Sunucu ana makinesindeki paketleri güncelleseniz bile kapsayıcının içinde bulunan PHP çalışma zamanı otomatik olarak değişmez. Bu nedenle yamalı sürümlerin (8.5.12, 8.4.27, 8.3.36, 8.2.35) bulunduğu bir temel imajı kullanarak kapsayıcı imajını yeniden oluşturmalı ve yeniden dağıtmalısınız.

Kaynaklar

• PHP: Security Advisory (CVE-2026-109618, CVE-2026-109619)
• PHP: PHP 8.4.27 Release Announcement
• PHP: PHP 8 ChangeLog (8.4.27)
• Red Hat Customer Portal - CVE-2026-109618
• Red Hat Customer Portal - CVE-2026-109619
• PHP 원격 코드 실행 취약점 CVE-2026-109618, CVE-2026-109619 대응 및 PHP 8.4.27 업데이트 (Korece)