Viral 'yamalanmamış PHP RCE' iddiası çürütüldü: CVE-2026-115560 nadir görülen bir runtime serializer değişikliği gerektiriyor

Dolaşıma giren ile php.net'in yayınladığı

Bu hafta geniş ölçüde yeniden paylaşılan bir uyarı, PHP'nin acil yamaları yayınladıktan sadece iki gün sonra yamalanmamış bir uzaktan kod yürütme (RCE) açığı konusunda uyarıda bulunduğunu, bunun alışılmadık session yapılandırmalarını etkilediğini ve acil önlem rehberi içerdiğini iddia etti. 23 Ekim'de dev.to'da yayımlanan bir analizlere göre, bu özetin her unsuru php.net'in aynı gün yayınladığı duyuruyu yanlış aktarıyor.

dev.to'nun aktardığına göre gerçek duyuru, acil bir uyarı değil bilgilendirme niteliğinde. PHP'nin gerçek dağıtımlarda olası görmediği bir RCE vektörünü kapatmak için bir sonraki düzenli hata düzeltme sürümüne kadar session upload progress özelliğinin kapatılmasını — session.upload_progress.enabled değerinin 0 yapılmasını — öneriyor. Kritik nokta şu: Aynı ayar, 21 Ekim'de yayımlanan CVE-2026-109619 için hazırlanan GHSA-6wmf-4rv5-p3rp duyurusunda zaten önlem olarak listelenmişti. O zaman uygulamış olanların yapması gereken başka bir şey yok.

İki sürüm arasındaki fark çarpıcı: bilgilendirici bir not yamalanmamış bir RCE'ye, planlanmış bir hata düzeltmesi aciliyete ve kesin biçimde tanımlanmış nadir bir yapılandırma geniş bir etkileşim çağrıştıran belirsiz bir ifadeye dönüştü.

Açıklığın gerçekte gerektirdiği koşullar

dev.to'nun alıntıladığı php.net duyurusuna göre açık, yalnızca belirli bir yapılandırma ve uygulama kodu birleşimi altında ortaya çıkabiliyor. Bir uygulama, yapılandırmasında session.serialize_handler değerini php_binary veya php_serialize olarak ayarlamalı, ardından session_start() çağırmadan önce bu değeri ini_set() ile runtime'da php olarak değiştirmeli ve session upload progress de açık kalmalı. Serialize handler'ı hiçbir zaman runtime'da değiştirmeyen uygulamalar etkilenmiyor ve özelliği açık tutabilir.

Bu kurulum nadir olduğundan PHP, sorunu normal sürüm döngüsü içinde ele alıyor ve CVE-2026-115560 için tam duyuruyu bir sonraki sürümle birlikte yayımlayacak.

Hatanın muhtemelen nasıl çalıştığı

dev.to yazarı, resmi duyuru gelene kadar yorum olarak işaretlediği bir mekanizma öneriyor. Bir serializer'ın kodlama kurallarıyla yazılan session verisi daha sonra başka bir serializer'la çözümleniyor; php_binary ve php_serialize, anahtarları varsayılan php handler'ından farklı kodluyor, dolayısıyla bir gramerle yazılan baytlar başka bir gramerle okunuyor. Upload-progress girdisi, kullanışlı biçimde, saldırganın seçtiği bir anahtar adı içeriyor. Saldırganın etkilediği session içeriği üzerindeki serializer karışıklığı, kod yürütmenin klasik yollarından biri; ancak tam olarak hangi imkân sunulduğu, tam duyuru yayımlandığında kesinleşecek.

Etkilenip etkilenmediğinizi belirlemek

dev.to yazısı duyuruyu üç duruma indirgiyor:

• 21 Ekim'de önceki önlemin parçası olarak upload progress'i kapattıysanız, bu vektöre karşı da zaten korunuyorsunuz.
• Upload progress açık ama kodunuz serialize handler üzerinde hiç ini_set() çağrısı yapmıyorsa, savunmasız kombinasyon dağıtımınızda mevcut değil ve özelliği açık bırakabilirsiniz — yine de henüz uygulamadıysanız 21 Ekim yamalarını (yazıya göre 8.5.12, 8.4.27, 8.3.36 ve 8.2.35) uygulamalısınız.
• Uygulamanız serialize handler'ı runtime'da değiştiriyorsa — bazı frameworkler ve session shimleri geçmişte bunu yapmıştır — upload progress'i şimdi kapatın ve tam duyuruyu bekleyin.

Yazı ayrıca kısa bir kontrol listesi sunuyor: yapılandırmada ve kodda session.serialize_handler ifadesini arayın, handler'a dokunan ini_set çağrılarını arayın ve etkin ayarları inceleyin. Runtime geçişine rastlarsanız, önlemin muhatabı sizsiniz.

Bir operasyonel tuzak vurgüyü hak ediyor: CLI ve php-fpm genellikle farklı ini dosyalarını okur, dolayısıyla bir kabukta php -i ile ayarı doğrulamak web sunucusunun görünüşü hakkında hiçbir şey kanıtlamaz. Bunun yerine bir phpinfo() sayfası ya da php-fpm -i üzerinden kontrol edin; çünkü en olası hata modu, önlemin yanlış yapılandırma dosyasına uygulanmış olması ve FPM havuzlarının progress açıkken çalışmaya devam etmesi.

Neden önemli

dev.to yazısı bunu, tarihleri karışık biçimde yeniden paylaşılan bir LiteLLM tedarik zinciri raporu, genel bir e-posta listesine sızan bir ZDI özel kuyruğu ve sorununun abartıldığından yakınan bir sertifika otoritesiyle birlikte haftanın dördüncü abartı haberi olarak çerçeveliyor. Ortak örüntü şu: yeniden paylaşmak okumaktan daha ucuz ve birincil kaynaktan her adım uzaklaştıkça doğruluk kaybediliyor, aciliyet ekleniyor.

php.net duyurusu bunun karşı örneği — kesin bir tetikleme koşulu, dürüst bir olasılık tahmini ve açıklayıcılığın en nadir cümlesi: yapmanız gerekeni zaten yaptıysanız, hiçbir şey yapmayın. Operatörler için çoğu uyarıya doğru yanıt eylemsizlik ve bunu size sadece birincil kaynak söyler.