PHP kullanan sunucular için kritik bir güvenlik gündemi var. CVE-2026-109618 ve CVE-2026-109619 numaralarıyla anılan iki açık, PHP güvenlik ekibinin 20 Ekim 2026 tarihli duyurusuyla kamuoyunun dikkatine geldi. PHP tarafından paylaşılan ilk bilgiye göre iki açığın da CVSS v4.0 skoru 9.2. Resmi açıklamada, düzeltmelerin 21 Ekim 2026 saat 14.00 UTC’de yayınlanmasının planlandığı belirtilmişti. PHP’nin resmi duyurusu Ayrıntılar kamuya açılmadan önce The Hacker News de açıkların kritik RCE riski taşıdığına dair watchTowr değerlendirmesini aktardı; ancak etkilenen sürüm aralığının resmi PHP duyurusuyla doğrulanmadığını özellikle belirtti. The Hacker News haberi
Bu yazı, PHP’nin düzeltilmiş paketleri ve cPanel ya da CloudLinux gibi platformların ilgili güncellemeleri yayınlanana kadar alınabilecek geçici önlemleri anlatıyor. Buradaki ayarlar kalıcı bir yama yerine geçmiyor.
CVE-2026-109618 ve CVE-2026-109619 nedir?
Bu iki güvenlik açığı internette “php2shell” adı ile de anılıyor. Açıklarla ilgili teknik ayrıntıların bir bölümü PHP’nin resmi duyurusundan önce paylaşıldı. Ancak PHP ekibi ilk duyuruda açıkların etkilenen sürümlerini, kök nedenini ve düzeltilen sürümleri henüz açıklamadı.
Bu nedenle şu aşamada kesin olmayan bilgileri kesin bir gerçek gibi yazmamak gerekiyor. Güvenlik araştırmalarında, açıkların PHP’nin session.upload_progress ve multipart/form-data isteklerini işleme akışı ile ilişkili olabileceği belirtiliyor. GMO Flatt Security de kendi incelemesinde bu bağlantıya dikkat çekiyor; aynı değerlendirmede session.upload_progress.enabled = Off ayarının tek başına yeterli olmayabileceği ve saldırının devam edebileceği uyarısı yapılıyor. Flatt Security değerlendirmesi
PHP’nin kendi dokümantasyonuna göre session.upload_progress.enabled açıkken PHP, dosya yüklemelerinin ilerleme bilgisini takip ediyor. Bu işlem, uygulama kodu çalışmadan önce gerçekleşebiliyor. PHP Session Upload Progress dokümantasyonu
Yama yayınlanana kadar ne yapılabilir?
Şu an PHP tarafında düzeltilmiş sürümler, cPanel veya CloudLinux tarafında da bu açığı hedefleyen güncellemeler yayınlanmış değil. Bu nedenle yapılabilecekler, kalıcı çözümden çok riski azaltmaya yönelik geçici adımlar.
Yönetimini yaptığınız sunucularda şu hazırlıkları yapabilirsiniz:
- Çalışan PHP sürümlerini ve PHP handler yapısını tespit edin.
- PHP, cPanel ve CloudLinux duyurularını takip edin.
- Güncelleme çıktığında önce test ortamında uygulamak için plan hazırlayın.
- Uygulamanın dosya yükleme, oturum ve giriş akışlarını test edecek kontrolleri belirleyin.
Asıl hedef, geçici ayarı uygulasanız bile yama yayınlandığında güncellemeyi geciktirmemek olmalı.
cPanel sunucularda geçici ayar
cPanel ve EasyApache kullanan sunucularda PHP sürümlerinin konfigürasyon dosyaları farklı dizinlerde tutulur. Her sürüm için ayarı tek tek eklemek yerine, aşağıdaki betik /opt/cpanel/ea-php*/root/etc/php.d/ altında bulunan PHP sürümlerinin konfigürasyon dizinlerine session.upload_progress.enabled = Off ayarını ekler.
Betik varsayılan olarak dry-run modunda çalışır. Yani herhangi bir dosyaya yazmadan hangi dosyalara işlem yapacağını gösterir. Uygulamak için --apply, geçici ayarı kaldırmak için --revert parametresi kullanılır. Uygulama sonrasında LiteSpeed yeniden başlatılır veya aktif PHP-FPM servisleri yeniden yüklenir.
Betiği çalıştırmadan önce mutlaka inceleyin. Bu işlem root yetkisi gerektirir ve cPanel sunucunun PHP dizin yapısının standart olduğu varsayımına dayanır. Canlı sunucuda uygulamadan önce yedek almak ve önce bir sunucuda test etmek gerekir.
Betiğin kendisine GitHub Gist üzerinden ulaşabilirsiniz. Örnek kullanım:
# Önce yapılacak işlemleri görüntüle
./upload-progress-off.sh
# Geçici ayarı uygula
./upload-progress-off.sh --apply
# Geçici ayarı kaldır
./upload-progress-off.sh --revert
cPanel kullanmayanlar ne yapabilir?
cPanel kullanmayan bir sunucuda PHP ayarı php.ini, .user.ini veya uygun durumlarda .htaccess üzerinden yapılabilir. Geçici önlem olarak kullanılan ayar şudur:
session.upload_progress.enabled = Off
Bu satırı ekledikten sonra ayarın gerçekten web sunucusunun kullandığı PHP yapılandırmasında etkin olduğunu kontrol edin. Komut satırında çalışan php -i çıktısı ile web isteğini karşılayan PHP-FPM veya Apache PHP yapılandırması aynı olmayabilir.
session.upload_progress özelliğini kullanan bir uygulamanız varsa, bu ayarı kapatmak dosya yüklemelerinin kendisini değil, yükleme ilerleme bilgisinin takip edilmesini etkileyebilir. Yine de uygulamanın dosya yükleme ekranlarını test etmeden değişiklik yapmamak gerekir.
Ubuntu sunucular için betik
Ubuntu veya Debian üzerinde nginx, Apache ya da PHP-FPM kullanan panelsiz sunucular için de ayrı bir betik hazırladım. Betik, /etc/php altında bulunan Debian paketli PHP sürümlerini tespit ederek her sürüm için geçici bir yapılandırma dosyası oluşturuyor ve phpenmod ile etkinleştiriyor.
Betiği önce deneme modunda çalıştırmak, ardından ihtiyaca göre --apply ile uygulamak mümkün. Geçici ayarı kaldırmak için --revert parametresi kullanılabiliyor. İşlem sonrasında aktif PHP-FPM birimleri ve Apache yeniden yükleniyor.
Betiğe GitHub Gist üzerinden ulaşabilirsiniz. Bu betik de PHP güncellemesinin yerine geçmez; resmi yama yayınlandıktan sonra geçici yapılandırma kaldırılmalı ve desteklenen PHP sürümüne geçilmelidir.
Bu ayar açığı tamamen kapatır mı?
Hayır, bunu böyle sunmamak gerekiyor. session.upload_progress.enabled = Off, şu an paylaşılan teknik analizlere göre ilgili saldırı yolunu daraltabilecek bir geçici azaltımdır. PHP’nin resmi açıklaması, bu ayarın iki CVE için doğrulanmış kalıcı çözüm olduğunu söylemiyor.
Bir başka deyişle, ayarı kapatmak yama uygulamak değildir. Açıkların gerçek nedeni PHP’nin düzeltilmesi gereken bir kod yolundaysa, kalıcı çözüm PHP sürümünü güncellemektir. Geçici ayar, yama penceresine kadar riski azaltmak için düşünülmelidir.
Geçici ayar sonrasında ne kontrol edilmeli?
Değişikliği yaptıktan sonra önce etkin PHP ayarını kontrol edin. Ardından uygulamanın giriş, oturum ve dosya yükleme akışlarını deneyin. Özellikle WordPress medya kütüphanesi, form dosya yüklemeleri, yedekleme eklentileri ve yönetim panelleri gözden geçirilmeli.
Bir ayarın etkin görünmesi tek başına güvenlik kontrolünün tamamlandığı anlamına gelmez. PHP’nin hangi sürümünün hangi domain veya handler tarafından kullanıldığı, isteğin hangi web sunucusundan geçtiği ve güncellemenin gerçekten uygulanıp uygulanmadığı ayrıca kontrol edilmeli.
Bu yazıdaki bilgiler yayın sonrasında değişebilir. PHP’nin güvenlik duyurularını, cPanel ve CloudLinux güncellemelerini takip edin. Paketler yayınlandığında desteklenen sürüme geçişi ertelemeyin.
Son söz
Kritik bir açık duyulduğunda en sağlıklı yol, resmi duyuruyu takip edip yama için hazırlanmak; geçici ayarları ise kalıcı çözüm gibi görmemek. cPanel sunucularda betiği uygulayacaksanız dry-run ve uygulama sonrası kontrol adımlarını atlamayın.