Yamalanmayı bekleyen PHP session serializer uyumsuzluğu CVE-2026-115560 uzaktan kod yürütmeyle sonuçlanabilir

6 Kasım'da dev.to'da yayımlanan bir yazı, yamalanmamış bir PHP zafiyeti olan CVE-2026-115560'nın, session serileştirme işleyicileri arasındaki uyumsuzluğun nasıl uzaktan kod yürütmeye (RCE) dönüşebileceğini anlatıyor. Yazıya göre PHP henüz bir düzeltme yayımlamadı — bir düzeltme bir sonraki düzenli sürüm için planlanıyor — ve belgelenen risk azaltma yolu, session upload progress özelliğini devre dışı bırakmak. Duyuru tarihi itibarıyla sahada istismar edildiğine dair bir rapor yoktu ve PHP resmî bir CVSS puanı ya da etkilenen sürümler listesi yayımlamamıştı; yine de bazı kaynaklar 9.2 olan ve Kritik olarak derecelendirilmiş bir satıcı CVSS v4 puanına atıfta bulunuyor.

Uyumsuzluk nasıl ortaya çıkıyor

PHP, $_SESSION içeriğini depolamak için bir dizeye dönüştürürken session.serialize_handler ile seçilen bir serialize handler kullanır. Üç işleyici vardır — php (varsayılan), php_binary ve php_serialize — ve session verisini yazmak için kullanılan işleyicinin, geri okumak için kullanılanla aynı olması gerekir.

İki format tehlikeli bir şekilde birbirinden ayrılır. php işleyicisi her girdiyi bir ad, bir pipe karakteri ve ardından serileştirilmiş değer olarak saklar; okurken ilk pipe'ta bölünür ve sonrasındaki her şeyi unserialize()'e aktarır. php_serialize işleyicisi ise tüm session'ı tek bir serileştirilmiş dizi olarak kodlar ve bu formatta pipe'lar dize değerlerinin içinde meşru biçimde bulunabilir.

İkinci bileşen, varsayılan olarak etkin olan session upload progress özelliğidir. Multipart bir formda PHP_SESSION_UPLOAD_PROGRESS adında bir alan bulunduğunda PHP, istek gövdesi henüz ayrıştırılırken — yani uygulama kodu çalışmadan önce — istemcinin sağladığı alan değerini ve yüklenen dosya adını da içeren upload progress ayrıntılarını $_SESSION içine yazar. Bu yazma işlemi, uygulamanın daha sonra ayarladığı işleyiciyi değil, php.ini'de yapılandırılmış serializer'ı kullanır.

php.ini php_serialize ya da php_binary seçerken, uygulama da session_start() hemen öncesinde ini_set('session.serialize_handler', 'php') çağırıyorsa — yazının eski sürüm uyumluluğuyla ilişkilendirdiği bir desen — bir formatta yazılan veri öbür formatta çözümlenir. php okuyucusu, saldırgan denetimindeki progress verisinin içindeki ilk pipe'ı ayırıcı olarak değerlendirir ve kalan kısmı unserialize eder.

Üç koşulun aynı anda gerçekleşmesi gerekiyor

dev.to yazısunda özetlendiği gibi PHP, istismar için şunların tümünün gerektiğini belirtiyor:

• yapılandırmada session.serialize_handler'ın php_serialize veya php_binary olarak ayarlanmış olması; bu yüzden php varsayılanını kullanan standart kurulumlar bu koşulu sağlamaz
• uygulama kodunun, session_start() çağırmadan önce çalışma zamanında işleyiciyi php'ye geri çevirmesi
• session.upload_progress.enabled'in açık olması, ki bu varsayılan durumdur

Yazı, bu bileşimin nadir olduğunu, bu yüzden PHP'nin düzeltmeyi acil bir yama yerine normal sürüm döngüsünde ele aldığını savunuyor.

Yazının atıfta bulunduğu SIOS Security Blog gibi satıcı açıklamaları, temel sorunu eski kalmış global durum olarak tanımlıyor: bulaşmış veri bir HTTP isteğinde yerleştirilir ve aynı PHP-FPM worker'ın işlediği başka bir istekte yanlış ayrıştırılır. İstekler arasında serializer işaretçisini sıfırlayan bir topluluk backport yaması bu tabloyla örtüşüyor; ancak yazı, kesin mekanizmayı yalnızca resmî duyurunun doğrulayabileceği konusunda uyarıyor.

unserialize neden otomatik olarak RCE değil

unserialize(), dizede adı geçen nesneleri örnekler ve __wakeup ve __destruct gibi magic method'ları tetikleyebilir. Gerçek kod yürütme, uygulamada ya da bağımlılıklarında kullanılabilir bir gadget sınıfı gerektirir; bu yüzden etki büyük ölçüde bağımlılık ağacına bağlıdır. Yazı, Composer tabanlı büyük projelerin genellikle daha fazla gadget adayı sunduğuna dikkat çekiyor. Saldırı ayrıca iki isteğe yayılır — veriyi yerleştirmek için hazırlanmış bir yükleme, onu yanlış okutmak için sıradan bir sayfa yüklemesi — ki yazıya göre bu, salt log'lardan tespit etmeyi zorlaştırıyor.

Risk azaltma ve topluluk yamaları

PHP'nin önerisi, php.ini, PHP-FPM pool yapılandırması veya web sunucusu yapılandırmasında session.upload_progress.enabled = 0 ayarlamak ve ardından tüm PHP worker'larını yeniden başlatmak. Yazı, bu konuda ini_set() veya .user.ini'ye güvenilmemesi gerektiği uyarısını yapıyor ve bir yan etkiye dikkat çekiyor: özelliği yükleme ilerleme çubukları için kullanan uygulamalar bu çubukları kaybedecek. Ayrıca, örneğin kod tabanında session.serialize_handler araması yaparak, işleyici ayarındaki çalışma zamanı değişiklikleri için kodun denetlenmesini öneriyor.

Ömrünü tamamlamış PHP 5.4'ten 8.1'e kadar olan sürümler için php2shell-patches adlı bir topluluk projesi, üç katmanlı gayri resmî bir backport sunuyor: upload progress tarafından kaydedilen adlardan kontrol karakterlerinin ayıklanması, istekler arasında serializer durumunun sıfırlanması ve progress kod çözümünün autoloading ve __wakeup olmadan __PHP_Incomplete_Class ile sınırlandırılması. Projenin minimal varyantı ise yalnızca upload progress'i devre dışı bırakıyor; bu da PHP'nin kendi tavsiyesiyle örtüşüyor. Yazı, bu kodun ne resmî bir PHP yaması ne de PHP Group tarafından doğrulanmış bir düzeltme olmadığını vurguluyor.

Neden önemli

Zafiyet yamalanmamış ama koşullu ve koşulların denetlenmesi ucuz: tek bir yapılandırma yönergesi ve kod tabanında tek bir arama, bir dağıtımın açık olup olmadığını netleştirir. Tek satırlık risk azaltma, düzenli sürümü beklemeden anında koruma sağlıyor. Öykü ayrıca yinelenen bir deseni gözler önüne seriyor — serileştirme formatı karmaşası ile saldırganın erişebildiği session deposu yazmalarının birleşimi, unserialize() istismarına giden iyi bilinen bir yol. Son olarak, önem tablosu tutarsız: 9.2 Kritik puanı olan bir üçüncü taraf değerlendirmesi, resmî bir puan ya da etkilenen sürümler listesi yayımlamamış bir satıcının yanında duruyor; bu yüzden yama önceliklendirmesi, manşet sayısına değil gerçek maruz kalma koşullarına göre yapılmalı.