PHP acil sürümü: 8.2.35 ile 8.5.12 arasında iki kritik çekirdek RCE açığı kapatıldı
PHP, dil çekirdeğindeki iki kritik use-after-free açığını kapatan program dışı bir güvenlik sürümü yayımladı; her ikisi de kimlik doğrulamasız uzaktan kod yürütmeye elverişli ve ikisi de CVSS v4.0 ölçeğinde 9,2 puanlı. Düzeltilen sürümler, bugün yayımlanan ve projenin sürüm arşivinde listelenen PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35. Uzun süredir bakımsız kalan 7.4, 8.0 ve 8.1 dalları için minimal kaynak geri portları yalnızca GitHub'da var - onlar için resmî ikili paket yok.
Sürümün önünde alışılmadık derecede dağınık bir erken ifşa penceresi vardı. Proje 20 Ekim'de bugün 14:00 UTC için acil bir sürüm duyurdu ama etkilenen sürümleri ve işlevleri adını koymadı; OX Security'nin belgelediği üzere, exploit aracı ekran görüntüleri yamalar yayımlanmadan dolaşıma girdi ve projenin kendisi bu pencerede dolaşan proof-of-concept kodunun çoğu zaman değiştirilmiş zararlı yazılım olduğu konusunda uyarmıştı. Yamalar ve danışmalar artık açıkken teknik tablo, fragman döngüsünün ima ettiğinden daha net.Bellek tükenmesinden kod yürütmeye giden yol
GHSA-w8hw-w9fx-j79w olarak kayıtlı CVE-2026-109618, PHP'nin bellek tükenmesini ele alma biçimini kötüye kullanıyor. Bir tahsis başarısız olduğunda motor isteği longjmp() ile geri sarıyor - ve bu, istek belleği kısmen başlatılmışken gerçekleşirse, kapanış aşaması daha sonra geçersiz durumdaki bellek üzerinde okuma ya da dallanma yapıyor. Danışma, bunu sıradan bir HTTP isteğinden erişilebilir kılan bir tahsis baskısı hileleri ailesini anlatıyor: post_max_size'ı geçen kullanılamaz content-length'li multipart gövdeler; bellekteki temsili kablo üzerindeki boyutunu ezip geçen binlerce başlıklı parçalar; ve hiç max_file_uploads'a sayılmadan üst veri dizileri ayıran boş dosya kontrolleri. Apache'nin mod_php SAPI'sinin istismar edilebilir olduğu doğrulandı: araştırmacılar, varsayılan prefork yapılandırmaları üzerinden düz HTTP ile web worker hesabı olarak kimlik doğrulamasız uzaktan kod yürütmeyi doğruladı - yüksek saldırı karmaşıklığıyla ve muhtemelen birkaç denemeyle. PHP-FPM'nin uygulamaya özgü tahsis yolları üzerinden duyarlı olduğu kabul ediliyor; FrankenPHP ve LiteSpeed de muhtemelen aynı teknede. Yama, ham longjmp'yi VM'nin bir sonraki güvenli noktasındaki yumuşak bir bellek tükenmesi tuzağıyla ve işçiyi anında sonlandıran sert bir hatayla değiştiriyor.İşçi süreçlerde bayat küresel durum
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) daha sessiz kardeş: işçi süreçler, tek bir isteğe ait belleğe işaret edebilen küresel durum taşır - hata işleyicileri, oturum verileri, nesne ve eklenti kayıtları. Ölümcül bir hata, bellek tükenmesi iptali ya da geç bir tanılama böyle bir durum yazarsa ve istek belleği serbest bırakılmadan önce hiçbir şey onu sıfırlamazsa, işçinin küreselleri boşlukta sallanır. Yeni bir istek başlatılmadan onlara dokunan her şey serbest bırakılmış bellek okur. İki üretim yolu doğrulandı: PHP 8.5'te yeni olan ölümcül hata geri izleri mod_php altında ve session upload progress mekanizması mod_php ve FPM altında. Üretici ve tüketici aynı işçi sürecine düşmeli; bu da çok işçili FPM havuzlarını vurulmasını zorlaştırır - ama imkânsız kılmaz.Stratejik olarak kurgulanmış bir heap düzeni tam uzaktan kod yürütme (RCE) üretebilir. - PHP güvenlik danışması, GHSA-6wmf-4rv5-p3rp
Yöneticilerin şimdi yapması gerekenler
Güncelleme tek eksiksiz hafifletme ve bu bir 'yamala ve unut' vakası değil: iki danışma da güncellemeden sonra tüm PHP işçilerinin yeniden başlatılmasını vurguluyor, çünkü bayat durum uzun ömürlü süreçlerde hayatta kalabilir. Desteklenen dallar sürüm ikili paketleri alıyor; EOL dallarına çakılı siteler kaynak geri portlarını kendileri uygulamak zorunda.- 8.2.35, 8.3.36, 8.4.27 veya 8.5.12'ye güncelleyin (ya da 7.4/8.0/8.1 için GitHub geri portlarını uygulayın), sonra her işçi süreci yeniden başlatın.
- Bugün güncelleme mümkün değilse: session.upload_progress.enabled=0 ve PHP 8.5'te ek olarak fatal_error_backtraces=0 ayarlayın, işçileri yeniden başlatın.
- OOM açığı için memory_limit=-1'i merkezi olarak dayatın ve hiçbir havuz ya da .htaccess geçersiz kılmasının sonlu bir sınırı geri getirmediğini doğrulayın.
- post_max_size'ı tutucu tutun, uygulama kullanmıyorsa ön yüzde multipart isteklerini engelleyin ve giriş değişkenlerini, başlıkları ve yüklemeleri sınırlayın.
- RLIMIT_AS veya RLIMIT_DATA yerine konteyner/cgroup bellek sınırları kullanın - danışma, RLIMIT mekanizmalarının tahsis hatalarını savunmasız yola ittiğini açıkça uyarıyor.
- İsteğe bağlı olarak pm.max_requests ile işçi geri dönüşümünü sınırlayın, durum taşıma penceresini kısaltın.