PHP GÜVENLİK GÜNCELLEMELERİ SONRASI RİSKLER: OTURUM YÖNETİMİ, BELLEK GÜVENLİĞİ VE YAMA DOĞRULAMASI ÜZERİNE TEKNİK BİR İNCELEME

PHP GÜVENLİK GÜNCELLEMELERİ SONRASI RİSKLER: OTURUM YÖNETİMİ, BELLEK GÜVENLİĞİ VE YAMA DOĞRULAMASI ÜZERİNE TEKNİK BİR İNCELEME

Alt başlık: Kritik güvenlik açıkları, yazılım regresyonları ve yapılandırma kaynaklı risklerin kanıta dayalı değerlendirilmesi

Tarih: 23 Ekim 2026

Çalışmanın niteliği: Teknik inceleme, literatür ve kaynak kodu kayıtlarının değerlendirilmesi, savunma amaçlı güvenlik rehberi.

Özet

Yazılım güvenliğinde güvenlik güncellemelerinin yayımlanması, bilinen zaafiyetlerin giderilmesi açısından temel bir savunma mekanizmasıdır. Bununla birlikte bir güncellemenin uygulanması, sistemin bütün güvenlik risklerinin ortadan kalktığını tek başına kanıtlamaz. Yazılımın yapılandırması, kullanılan uzantılar, bellek yönetimi, isteklerin işlenme biçimi ve uygulama mimarisi, güvenlik değerlendirmesinin ayrılmaz parçalarıdır.

Bu çalışma, 21 Ekim 2026 tarihinde yayımlanan PHP güvenlik güncellemelerini başlangıç noktası alarak dört temel teknik alanı incelemektedir: oturum yönetimi ve serileştirme uyumluluğu, bellek yönetimi ve SimpleXML regresyonu, güvenlik yamalarının doğrulanması ve unserialize() işlemi sırasında bellek yaşam döngüsü. Ayrıca 23 Ekim 2026 tarihinde duyurulan oturum yükleme ilerlemesiyle ilgili ek risk değerlendirmeye dâhil edilmiştir.

İncelemede resmî güvenlik duyuruları, kaynak kodu hata kayıtları ve bağımsız doğrulama gerektiren teknik iddialar birbirinden ayrılmaktadır. AddressSanitizer gibi bellek hata tespit araçlarının kullanımı, testlerin tekrarlanabilirliği, etki sınıflandırması ve sistem yöneticilerine yönelik savunma önlemleri değerlendirilmiştir.

Temel sonuç, güvenlik değerlendirmesinin yalnızca sürüm numarasına veya hata kayıtlarına dayandırılamayacağıdır. Her bulgunun etkilenen sürüm, teknik mekanizma, yeniden üretilebilirlik, kanıtlanan etki ve düzeltme durumu üzerinden ayrı ayrı incelenmesi gerekir.

Anahtar kelimeler: PHP, yazılım güvenliği, bellek güvenliği, oturum yönetimi, serileştirme, use-after-free, double-free, güvenlik yaması, regresyon testi, AddressSanitizer.

1. Giriş

PHP, web uygulamalarında yaygın olarak kullanılan bir programlama dilidir. Kullanıcı oturumlarının yönetilmesi, HTTP isteklerinin işlenmesi, nesnelerin oluşturulması ve yok edilmesi, bellek tahsisi ve yerel uzantıların çalıştırılması gibi işlemler güvenlik açısından farklı hata türleri doğurabilir.

Yazılım güvenliği değerlendirmelerinde iki temel kavramın birbirinden ayrılması gerekir. Birincisi, belirli bir koşulda ortaya çıktığı doğrulanmış güvenlik açığıdır. İkincisi ise mevcut bir güvenlik mekanizmasıyla ilişkili olabilecek, ancak etkisi henüz yeterli kanıtla ortaya konulmamış risk veya araştırma varsayımıdır. Bu iki kategorinin aynı kesinlik düzeyinde sunulması, teknik sonuçların yanlış yorumlanmasına neden olabilir.

PHP'nin 21 Ekim 2026 tarihli güvenlik güncellemeleri, kimlik doğrulaması gerektirmeyen uzaktan kod çalıştırma riski taşıyan iki kritik sorunu gidermeyi amaçlamıştır. Resmî duyurularda PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümleri belirtilmiştir. Aynı duyurular, güncellemenin geciktirilmemesi gerektiğini vurgulamaktadır.

23 Ekim tarihli ek bilgilendirme ise belirli bir oturum yapılandırması kombinasyonunda ortaya çıkabilecek başka bir riske dikkat çekmiştir. Bu gelişme, güvenlik değerlendirmelerinin tek seferlik değil, yeni kanıtlar ortaya çıktıkça güncellenen bir süreç olması gerektiğini göstermektedir.

Bu çalışmanın amacı, söz konusu gelişmeleri tek bir güvenlik açığı zinciri olarak varsaymak değil; aralarındaki teknik ilişkileri, kanıt düzeylerini ve savunma bakımından taşıdıkları anlamı sistematik biçimde değerlendirmektir.

2. Yöntem ve kanıt sınıflandırması

Bu inceleme, mevcut resmî duyuruların, kaynak kodu hata kayıtlarının ve teknik değerlendirme materyallerinin karşılaştırmalı analizine dayanmaktadır. Buradaki yaklaşım, her iddiayı aynı kanıt standardına tabi tutmak ve doğrulanmış bulgularla araştırılması gereken olasılıkları açıkça ayırmaktır.

Bir güvenlik bulgusunun değerlendirilmesinde aşağıdaki kanıt sınıfları kullanılmalıdır:

Kanıt sınıfı	Tanım	İzin verilen sonuç
Resmî güvenlik danışması	Üretici tarafından açıklanmış güvenlik sorunu	Açıklamada belirtilen kapsam ve etki aktarılabilir.
Kaynak kodu hata kaydı	Belirli bir bileşende hata veya regresyon bildirimi	Kaydın gösterdiği hata ve mevcut durum açıklanabilir.
Kontrollü test	Belirli koşullarda tekrarlanabilir biçimde gözlenen davranış	Sonuç yalnızca test edilen koşullar için genellenebilir.
Bağımsız doğrulama	Bulguyu farklı bir yöntem veya ortamda destekleyen kanıt	Doğrulanan kapsam genişletilebilir; sınırlar belirtilmelidir.
Araştırma varsayımı	Henüz yeterli kanıtla doğrulanmamış olası mekanizma	Kesin güvenlik açığı veya doğrulanmış istismar olarak sunulamaz.

Bu sınıflandırma, hata kaydı bulunması ile bir güvenlik açığının doğrulanması arasındaki farkı korumayı sağlar. Aynı şekilde bir testte uygulamanın çökmesi, tek başına uzaktan kod çalıştırma sonucuna ulaşıldığını göstermez.

Çalışmanın sınırları da belirtilmelidir: Bir kaydın veya kaynak kodu değişikliğinin incelenmesi, bütün işletim sistemlerinde, derleme seçeneklerinde ve üretim ortamlarında bağımsız deney yapılmış olduğu anlamına gelmez. Bu nedenle aşağıdaki değerlendirmeler, kaynakların desteklediği kapsamla sınırlıdır.

3. Resmî güvenlik güncellemeleri ve doğrulanmış bulgular

3.1. 21 Ekim 2026 tarihli kritik güvenlik duyurusu

PHP'nin resmî güvenlik duyurusu, aşağıdaki iki güvenlik sorununu açıklamaktadır:

• CVE-2026-109618: Bellek yetersizliği (Out-of-Memory, OOM) işlenirken oluşabilen bellek bozulmasıyla ilişkili uzaktan kod çalıştırma riski.
• CVE-2026-109619: Bir isteğe ait dahili durumun, ilgili bellek serbest bırakıldıktan sonra sonraki isteklerde yeniden kullanılabilmesiyle ilişkili uzaktan kod çalıştırma riski.

Resmî duyuruda belirtilen düzeltme sürümleri PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35'tir. Duyuru ayrıca web isteklerini işleyen PHP kurulumlarının risk altında olabileceğini belirtmektedir.

Bu iki sorunun teknik mekanizmaları birbirinden farklıdır. İlkinde bellek yetersizliği sırasında kısmen başlatılmış dahili verilerin hata temizleme sürecinde yanlış ele alınması söz konusudur. İkincisinde ise önceki isteğe ait durumun, aynı çalışan süreç tarafından sonraki bir istekte normal başlatma işlemi gerçekleşmeden kullanılabilmesi söz konusudur.

Dolayısıyla bu açıkları yalnızca genel bir “bellek sorunu” başlığı altında toplamak, hata koşulları ve savunma seçenekleri arasındaki farkları görünmez kılabilir.

Resmî kaynaklar:

• PHP 2026 Güvenlik Duyuruları Arşivi
• PHP Resmî İndirme Sayfası
• CVE-2026-109618 – GHSA-w8hw-w9fx-j79w
• CVE-2026-109619 – GHSA-6wmf-4rv5-p3rp

3.2. 23 Ekim 2026 tarihli ek oturum güvenliği bilgilendirmesi

PHP'nin 23 Ekim tarihli bilgilendirmesi, oturum yükleme ilerlemesi özelliğiyle ilişkili, belirli yapılandırma koşullarında ortaya çıkabilecek ek bir riski ele almaktadır.

Açıklamaya göre risk, uygulamanın session.serialize_handler ayarını başlangıçta php_binary veya php_serialize olarak belirlemesi, daha sonra çalışma sırasında ini_set() ile php değerine geçmesi ve bu değişiklikten önce ilgili oturum yükleme ilerlemesi özelliğinin etkin kalması gibi alışılmadık bir yapılandırma birleşiminde ortaya çıkabilir.

Duyuruda CVE-2026-115560 numarası belirtilmiş ve daha ayrıntılı danışmanın sonraki olağan hata düzeltme sürümüyle yayımlanacağı ifade edilmiştir.

Bu bulgu, 21 Ekim'de düzeltilen iki kritik açıkla otomatik olarak aynı kabul edilmemelidir. Tarih, yapılandırma koşulları ve düzeltme takvimi farklıdır. Bilimsel bir değerlendirmede bu ayrımın korunması gerekir.

Resmî kaynak: PHP 2026 Güvenlik Duyuruları Arşivi.

4. Oturum yönetimi ve serileştirme uyumluluğu

4.1. session.serialize_handler yapılandırması

PHP oturum verileri, kullanılan serileştirme işleyicisine bağlı olarak farklı biçimlerde saklanabilir ve okunabilir. session.serialize_handler, bu davranışı belirleyen yapılandırma seçeneklerinden biridir.

Aynı uygulamanın oturum yazma ve okuma aşamalarında farklı işleyiciler kullanması, verilerin beklenmedik biçimde yorumlanmasına veya oturum yönetiminde tutarsızlıklara yol açabilir. Bu tür farklılıklar sanal sunucu ayarları, dizin bazlı yapılandırmalar veya çalışma sırasında yapılan değişiklikler nedeniyle oluşabilir.

Ancak yapılandırma uyumsuzluğunun varlığı, tek başına nesne enjeksiyonu veya uzaktan kod çalıştırma kanıtı değildir. Bunun için verinin hangi biçimde işlendiğinin, hangi kod yoluna ulaştığının ve ortaya çıkan davranışın güvenlik üzerindeki etkisinin ayrıca gösterilmesi gerekir.

4.2. Nesne yaşam döngüsü ve sihirli metotlar

PHP'de __wakeup() ve __destruct() gibi sihirli metotlar, belirli nesne yaşam döngüsü olaylarında otomatik olarak çalışabilir. Güvenilmeyen verilerden nesne oluşturulması, uygulamada uygun koşullar mevcutsa güvenlik riski doğurabilir.

Bununla birlikte, bu metotların varlığı bir güvenlik açığı olarak değerlendirilemez. Risk; kullanılan sınıflara, nesnenin oluşturulma biçimine, uygulamanın girdiyi nasıl doğruladığına ve nesne yok edilirken yürütülen işlemlere bağlıdır.

Oturum verisinin reddedilmesi veya geçersiz sayılması da dosya bütünlüğünün korunduğunu tek başına göstermez. Hata durumunda dosyanın değiştirilip değiştirilmediği, oturumun geçersiz kılınıp kılınmadığı ve işlemin diğer kullanıcı oturumlarına etkisi ayrı ayrı incelenmelidir.

4.3. Oturum yükleme ilerlemesi ve savunma

23 Ekim tarihli resmî bilgilendirme, ilgili yapılandırma birleşimi için session.upload_progress.enabled=0 ayarını geçici önlem olarak önermektedir. Ayarın, istek işlenmeye başlamadan önce geçerli olacak şekilde uygulanması ve çalışan süreçlerin yeniden başlatılması gerektiği belirtilmektedir.

Bu önlem, duyuruda tarif edilen belirli saldırı yollarını engellemeye yöneliktir; bütün PHP güvenlik risklerini ortadan kaldırmaz. Üretim ortamında uygulanmadan önce kullanılan PHP sürümü, oturum yapılandırması ve uygulamanın dosya yükleme işlevleri değerlendirilmelidir.

5. SimpleXML ve bellek yönetimi regresyonu

5.1. Teknik sorun ve kaynak kodu kaydı

PHP kaynak kodu deposundaki #24488 numaralı hata kaydı, PHP 8.4.27 ve 8.5.12 ile ilişkilendirilen, çöp toplama sürecinde SimpleXMLElement özellik tablosunun birden fazla kez serbest bırakılması sorununu ele almaktadır. İlgili #24494 numaralı düzeltme çalışması bu sorunu gidermeyi amaçlamaktadır.

Kayıtta ele alınan mekanizma, nesne temizliği ile çöp toplama sürecinin aynı bellek yapısı üzerindeki işlemleri arasındaki uyumsuzlukla ilgilidir. sxe_object_free_storage(), zend_hash_release() ve çöp toplama mekanizması arasındaki etkileşim, hatanın anlaşılması açısından önemlidir.

Kayıtta tartışılan düzeltme, özellik tablosunun serbest bırakılma yönteminin değiştirilmesini ve buna ilişkin regresyon testini içermektedir. Bu teknik ayrıntı, bellek yönetimindeki küçük bir kod değişikliğinin bile nesne yaşam döngüsü ve çöp toplama davranışıyla birlikte değerlendirilmesi gerektiğini göstermektedir.

5.2. Olası etkiler ve kanıt sınırları

Çift serbest bırakma (double-free), aynı bellek alanının birden fazla kez serbest bırakılmasıdır. Böyle bir hata, çalışma zamanı ve bellek yöneticisine bağlı olarak aşağıdaki sonuçları doğurabilir:

• Uygulama sürecinin çökmesi.
• Bellek yöneticisinin bozulma tespit etmesi.
• AddressSanitizer gibi araçlarda bellek hatası raporlanması.
• Bazı koşullarda daha sonra yapılan bellek işlemlerinin etkilenmesi.

Bununla birlikte, bu sonuçların tamamı her ortamda ortaya çıkmak zorunda değildir. Bir çökme veya bellek bozulması bulgusu, kendi başına uzaktan kod çalıştırma sonucunu kanıtlamaz.

Bu nedenle SimpleXML regresyonu, iki kritik CVE'den ayrı bir kaynak kodu bulgusu olarak ele alınmalı; etkilenen sürümler, düzeltmenin hangi dallara alındığı ve ilgili testlerin sonuçları takip edilmelidir.

6. unserialize() ve use-after-free riski

6.1. Bellek yaşam döngüsü

unserialize() fonksiyonu, serileştirilmiş veriden PHP değerleri ve nesneleri oluşturur. Bu süreçte geçici veri yapılarının oluşturulması, nesne yıkıcılarının çalışması ve ayrılan belleğin temizlenmesi gibi işlemler gerçekleşebilir.

Use-after-free (UAF), bir bellek alanı serbest bırakıldıktan sonra o alana yeniden erişilmesi durumudur. Böyle bir hata uygulamanın çökmesine veya bellek güvenliğinin bozulmasına yol açabilir.

Nesne yıkıcılarının yürütülmesi sırasında başka işlemlerin yeniden başlatılması, iç içe çağrılar veya geçici veri yapılarının erken temizlenmesi gibi durumlar, bellek yaşam döngüsü açısından dikkatle incelenmelidir.

PHP kaynak kodu deposundaki #24481 numaralı hata kaydı, unserialize() sırasında yeniden giriş (re-entrancy) ve var_destroy() işlemiyle ilişkili olası bir use-after-free sorununu ele almaktadır. Kayıtta yer alan durumun, SimpleXML regresyonuyla aynı hata olduğu varsayılmamalıdır.

6.2. Doğrulama gereksinimleri

Bu tür bir iddianın doğrulanması için aşağıdaki unsurlar gerekir:

1. Hatanın ortaya çıktığı kod yolunun ve ilgili veri yapısının belirlenmesi.
2. Belleğin hangi aşamada serbest bırakıldığının gösterilmesi.
3. Daha sonraki erişimin gerçekten geçersiz bellek alanına yöneldiğinin doğrulanması.
4. Kontrollü testte gözlenen davranışın kaydedilmesi ve yeniden üretilebilirliğinin değerlendirilmesi.
5. Farklı derleme ve çalışma koşullarının sonuç üzerindeki etkisinin incelenmesi.

Kaynak kodunda karmaşık bir çağrı zincirinin bulunması veya bir hata kaydının açılmış olması, sorunun tüm PHP sürümlerinde doğrulandığı anlamına gelmez. Aynı şekilde bir hata kaydının ilk aşamada inceleme bekliyor olması, sorunun kesinlikle bulunmadığını da göstermez.

Bu nedenle teknik sonuç, ilgili kayıtların güncel durumu ve doğrulanmış test bulguları üzerinden ifade edilmelidir.

7. Dört teknik alanın karşılaştırmalı değerlendirmesi

Aşağıdaki tablo, incelenen mekanizmaların birbiriyle ilişkisini ve kanıt sınırlarını özetlemektedir.

Teknik alan	İncelenen mekanizma	Başlıca risk	Doğrulama yöntemi
Oturum yönetimi	Serileştirme işleyicisi ve oturum yaşam döngüsü	Veri tutarsızlığı, belirli koşullarda güvenlik riski	Yapılandırma karşılaştırması, kontrollü oturum testleri
Bellek yönetimi	SimpleXML ve çöp toplama etkileşimi	Double-free, süreç çökmesi, bellek bozulması	Kaynak kodu incelemesi, regresyon testi, ASan
Yama doğrulaması	Önceki ve sonraki kod davranışı	Düzeltme sonrası gerileme veya kapsanmayan kod yolu	Kod farkı analizi, test karşılaştırması
Serileştirme çözümleme	unserialize() ve nesne yaşam döngüsü	UAF veya güvenilmeyen veri kaynaklı riskler	Kontrollü test, bellek hata raporu, kod yolu analizi

Bu dört alan arasında kavramsal bağlantılar bulunması, bunların tek bir istismar zinciri oluşturduğunu kanıtlamaz. Örneğin oturum yönetimindeki bir tutarsızlığın bellek hatasını tetiklemesi, ancak iki mekanizma arasında tekrarlanabilir ve kanıtlanabilir bir ilişki gösterildiğinde ileri sürülebilir.

Dolayısıyla “bileşik zafiyet zinciri” ifadesi, kanıtlanmış bir teknik sonuç olarak değil, araştırılması gereken olası bir senaryo olarak kullanılmalıdır.

8. Teknik doğrulama ve test metodolojisi

8.1. Kaynak kodu karşılaştırması

Yama öncesi ve sonrası kaynak kodu karşılaştırması, düzeltmenin kapsamını değerlendirmek için temel yöntemlerden biridir. İnceleme sırasında yalnızca değiştirilen satırlara değil, ilişkili işlevlere, bellek sahipliği kurallarına, hata temizleme yollarına ve test dosyalarına da bakılmalıdır.

Özellikle aşağıdaki sorular cevaplanmalıdır:

• Düzeltme hangi hata koşulunu hedeflemektedir?
• Bellek tahsisi ve serbest bırakılması arasındaki ilişki nasıl değiştirilmiştir?
• İlgili regresyon testi eklenmiş veya güncellenmiş midir?
• Düzeltme hangi geliştirme ve kararlı sürüm dallarına aktarılmıştır?
• İlgili hata kaydının ve düzeltme çalışmasının güncel durumu nedir?

Kod farkı analizi, sorunun bulunup bulunmadığı konusunda tek başına nihai karar vermek yerine, test edilmesi gereken hipotezleri belirlemeye yardımcı olur.

8.2. AddressSanitizer ve diğer bellek hata tespit araçları

AddressSanitizer (ASan), use-after-free, heap taşması ve double-free gibi bazı bellek hatalarının tespit edilmesini sağlayan bir araçtır. Valgrind ve hata ayıklayıcılar da bellek davranışının incelenmesinde yardımcı olabilir.

Testler, üretim ortamından ayrılmış ve yetkilendirilmiş bir laboratuvarda yürütülmelidir. Kullanılan kaynak kodu sürümü, derleyici, derleme seçenekleri, işletim sistemi, etkin PHP uzantıları ve test girdileri kayıt altına alınmalıdır.

ASan altında gözlenen hata, test edilen kod yolunda bellek güvenliği sorunu bulunduğunu destekleyebilir. Bununla birlikte, aracın raporu tek başına sorunun uzaktan istismar edilebilirliğini veya belirli bir güvenlik etkisini kanıtlamaz.

Standart derlemede hata gözlenmemesi de sorunun bulunmadığı anlamına gelmez. Derleyici optimizasyonları, bellek yerleşimi ve hata tespit aracının çalışma biçimi sonuçları etkileyebilir.

Bu nedenle test sonuçları, kaynak kodu incelemesi ve tekrar deneyleriyle birlikte değerlendirilmelidir. Hata günlükleri gerçek testlerden alınmalı; örnek veya varsayımsal günlükler gerçek bulgu gibi sunulmamalıdır.

8.3. Test ortamlarının karşılaştırılması

PHP CLI, PHP-FPM ve Apache modülü gibi farklı çalışma biçimleri, süreçlerin yaşam döngüsü ve yapılandırmalar açısından farklılık gösterebilir. Bu nedenle bir ortamda elde edilen sonuçlar diğerlerine otomatik olarak genellenmemelidir.

Test matrisi en azından şu bilgileri içermelidir:

• PHP sürümü ve kaynak kodu revizyonu.
• İşletim sistemi ve derleyici.
• Etkin uzantılar ve ilgili yapılandırma ayarları.
• Çalışma modeli ve süreçlerin yeniden kullanılması.
• Testin amacı, sonucu ve tekrarlanabilirliği.
• Hatanın türü ve gözlenen güvenlik etkisi.

Test sonuçları, hem hatanın ortaya çıktığı hem de beklenen davranışın korunduğu kontrol koşullarını kapsamalıdır. Negatif kontrolün başarısız olması, test düzeninin veya hipotezin yeniden incelenmesini gerektirebilir.

9. Savunma önlemleri ve sistem sıkılaştırması

Savunma önlemleri, doğrulanmış güvenlik duyurularının önerileri ile genel sistem yönetimi uygulamaları birbirinden ayrılarak ele alınmalıdır.

9.1. Birincil önlem: Güncelleme yönetimi

PHP'nin 21 Ekim tarihli resmî duyurusu, belirtilen kritik açıklar için ilgili düzeltilmiş sürümlere geçilmesini önermektedir. Güncellemenin uygulanması, mümkün olan en kısa sürede planlanmalı; dağıtım paketlerinin ve uzun süreli destek sağlayan işletim sistemi sürümlerinin kendi güvenlik duyuruları da kontrol edilmelidir.

Güncelleme sonrasında uygulamanın çalışması, uzantıların uyumluluğu, hata günlükleri ve temel işlevler test edilmelidir. Bir dağıtım sağlayıcısının düzeltmeyi geriye taşıdığı (backport) durumlarda yalnızca sürüm numarasına bakmak yeterli olmayabilir; sağlayıcının güvenlik duyurusu incelenmelidir.

9.2. Oturum yönetimi

Oturum serileştirme ayarları, uygulamanın gereksinimleri ve PHP'nin resmî güvenlik önerileri doğrultusunda gözden geçirilmelidir. Çalışma sırasında değiştirilen ayarlar, sanal sunucu ve dizin bazlı yapılandırmalar ile uygulama kodundaki ini_set() kullanımları denetlenmelidir.

23 Ekim tarihli resmî bilgilendirmede belirtilen özel koşullar mevcutsa session.upload_progress.enabled=0 geçici önlemi değerlendirilmeli ve ayarın istek işlenmeden önce etkin olduğundan emin olunmalıdır.

Bu önlemin, güncellemenin yerini tutmadığı ve yalnızca tarif edilen risk yollarını sınırlandırdığı açıkça belirtilmelidir.

9.3. Bellek ve kaynak sınırları

İstek boyutlarının, yüklenen dosyaların ve işleme sürelerinin uygun sınırlarla yönetilmesi, hizmet kesintisi risklerini azaltmaya yardımcı olabilir. Ancak bu tür sınırlar, PHP çekirdeğindeki doğrulanmış bir bellek güvenliği açığının giderilmesiyle aynı şey değildir.

Özellikle memory_limit değerini gelişigüzel düşürmek, bellek yetersizliği durumunu daha sık tetikleyebilir. Bu nedenle her ayar, ilgili güvenlik duyurusundaki öneri ve uygulamanın kaynak gereksinimleriyle birlikte değerlendirilmelidir.

PHP'nin 21 Ekim tarihli resmî danışması, OOM ile ilişkili açık için belirli geçici önlemler açıklamaktadır. Bu önlemler, normal bir memory_limit değerini otomatik olarak daha güvenli kabul etmekle karıştırılmamalıdır.

9.4. PHP-FPM süreç yönetimi

PHP-FPM çalışan süreçlerinin belirli sayıda istekten sonra yenilenmesi, genel süreç yönetimi ve operasyonel kararlılık açısından yararlı olabilir. Ancak pm.max_requests ayarı, doğrulanmış bir bellek güvenliği açığının çözümü olarak kabul edilmemelidir.

Özellikle bir önceki istekte kalan dahili durumun sonraki isteği etkileyebildiği bir güvenlik açığında, süreç yenileme mekanizması tek başına yeterli koruma sağlamayabilir. Bu nedenle güvenlik düzeltmesi uygulanmalı ve üreticinin ilgili danışmasındaki talimatlar esas alınmalıdır.

9.5. WAF ve ağ katmanı savunması

Web uygulaması güvenlik duvarları (WAF), bazı şüpheli istekleri belirlemek ve uygulamaya ulaşan trafiği sınırlandırmak için kullanılabilir. Bununla birlikte PHP serileştirme desenlerini arayan genel düzenli ifadeler, bütün geçerli ve geçersiz veri biçimlerini güvenilir biçimde ayırt edemez.

Bir WAF kuralı, yalnızca O:, a: veya benzeri karakter dizilerini aradığı için güvenlik açığını tamamen kapatmış sayılmaz. Kodlanmış girdiler, farklı istek biçimleri, uygulamanın meşru veri yapıları ve kuralın kapsamı yanlış pozitiflere veya atlatılabilir durumlara yol açabilir.

Bu nedenle doğrulanmamış Cloudflare, Nginx/OpenResty veya ModSecurity kuralları üretim ortamına doğrudan uygulanmamalıdır. Her kural, kullanılan WAF sürümünün sözdizimiyle doğrulanmalı; önce kayıt veya izleme modunda test edilmeli ve uygulamanın geçerli trafiğiyle karşılaştırılmalıdır.

WAF, güncellemelerin yerine geçen bir çözüm olarak değil, uygun olduğu durumlarda ek savunma katmanı olarak değerlendirilmelidir.

9.6. Günlük izleme ve olay müdahalesi

PHP hata günlükleri, web sunucusu günlükleri ve süreç çökme kayıtları düzenli olarak izlenmelidir. Segmentation fault, bellek yöneticisi hataları ve tekrarlayan çalışan süreç çökmeleri, teknik inceleme gerektiren belirtilerdir.

Bununla birlikte her çökme bir saldırı göstergesi değildir. Günlükler; zaman, ilgili sürüm, istek bağlamı ve uygulama davranışıyla birlikte değerlendirilmelidir. Güvenlik olayı şüphesi varsa kayıtların korunması, ilgili süreçlerin incelenmesi ve güncelleme durumunun doğrulanması gerekir.

10. Sınırlılıklar ve gelecekteki araştırmalar

Bu inceleme, mevcut resmî duyurular ve belirtilen kaynak kodu kayıtları üzerinden yürütülen bir teknik değerlendirmedir. Burada yer alan bütün senaryoların bağımsız laboratuvar testlerinde yeniden üretildiği veya her üretim ortamında aynı sonuçları verdiği ileri sürülmemektedir.

Gelecekteki çalışmalar aşağıdaki konulara odaklanabilir:

1. SimpleXML regresyonunun farklı PHP sürümleri ve desteklenen derleme seçenekleri üzerindeki etkisinin doğrulanması.
2. unserialize() ve nesne yıkımıyla ilişkili hata kayıtlarının güncel durumunun ve düzeltmelerinin izlenmesi.
3. Oturum serileştirme ayarlarının farklı çalışma ortamlarında tutarlılığının ölçülmesi.
4. Bellek hata tespit araçlarının sonuçlarının standart derlemelerle karşılaştırılması.
5. WAF kurallarının yanlış pozitif ve yanlış negatif oranlarının kontrollü testlerle değerlendirilmesi.
6. Güvenlik güncellemelerinin farklı dağıtım paketlerine hangi tarihlerde ve hangi değişikliklerle ulaştığının incelenmesi.

Bu çalışmaların sonuçları paylaşılırken test ortamı, yöntem, ham kanıtlar ve sınırlılıklar açık biçimde belirtilmelidir. Böylece bulgular başka araştırmacılar tarafından yeniden değerlendirilebilir.

11. Sonuç

PHP güvenlik güncellemeleri sonrasında ortaya çıkan riskleri değerlendirmek, yalnızca sürüm numarasını kontrol etmekten daha kapsamlı bir yaklaşım gerektirir. Oturum yönetimi, bellek tahsisi, çöp toplama, serileştirme ve hata yönetimi birbirini etkileyebilen mekanizmalardır; ancak bu ilişkilerin her biri somut kanıtlarla değerlendirilmelidir.

21 Ekim 2026 tarihli iki kritik güvenlik duyurusu, düzeltilmiş sürümlere geçmenin önemini ortaya koymaktadır. SimpleXML ile ilişkili kaynak kodu regresyonu ve unserialize() sırasında yeniden girişle ilgili hata kaydı ise farklı teknik sorunların ayrıca incelenmesi gerektiğini göstermektedir. 23 Ekim tarihli ek oturum güvenliği bilgilendirmesi de yeni kanıtların ve özel yapılandırma koşullarının güvenlik değerlendirmesini zaman içinde değiştirebileceğini ortaya koymaktadır.

Bu bulguların tümünü tek bir zafiyet zinciri olarak kabul etmek veya her bellek hatasını uzaktan kod çalıştırma riskiyle eşitlemek bilimsel açıdan doğru değildir. Benzer biçimde, bir yamanın uygulanmış olması da ilişkili bütün bileşenlerin her koşulda hatasız çalıştığını garanti etmez.

Güvenilir bir güvenlik yaklaşımı; resmî duyuruların takip edilmesini, güncellemelerin uygulanmasını, kaynak kodu değişikliklerinin incelenmesini, kontrollü testlerin yürütülmesini ve sistem davranışının izlenmesini birlikte gerektirir. Teorik riskler, doğrulanmış hatalar ve kanıtlanmış güvenlik etkileri açıkça ayrıldığında, hem teknik kararların kalitesi hem de kamuya sunulan bilginin güvenilirliği artar.

Genel değerlendirme: Güvenlik güncellemeleri temel savunma önlemidir. Test, izleme ve yapılandırma denetimi bu süreci tamamlar; doğrulanmış bir açığın giderilmesinin yerine geçmez.

Kaynakça ve teknik başvuru noktaları

1. PHP. News Archive – 2026. Resmî güvenlik duyuruları ve 23 Ekim tarihli oturum yükleme ilerlemesi bilgilendirmesi. https://www.php.net/archive/2026.php
2. PHP. Downloads. PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürüm bilgileri. https://www.php.net/downloads.php
3. PHP Source Repository. GHSA-w8hw-w9fx-j79w. CVE-2026-109618 ile ilişkili güvenlik danışması. https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
4. PHP Source Repository. GHSA-6wmf-4rv5-p3rp. CVE-2026-109619 ile ilişkili güvenlik danışması. https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
5. PHP Source Repository. Issue #24488: GC double-frees the SimpleXMLElement properties table. https://github.com/php/php-src/issues/24488
6. PHP Source Repository. Pull Request #24494: Fix phpGH-24488. https://github.com/php/php-src/pull/24494
7. PHP Source Repository. Issue #24481: Use-after-free in var_destroy() during unserialize() re-entrancy. https://github.com/php/php-src/issues/24481
8. PHP Manual. Session Security. https://www.php.net/manual/en/session.security.php
9. PHP Manual. unserialize(). https://www.php.net/manual/en/function.unserialize.php
10. LLVM Project. AddressSanitizer. Bellek hata tespit aracının çalışma ilkeleri ve kullanım sınırları. https://clang.llvm.org/docs/AddressSanitizer.html

Yayın öncesi bilimsel doğrulama notu

Bu çalışma, teknik bilgilendirme ve araştırma çerçevesi niteliğindedir. Akademik bir yayında veya hakem değerlendirmesine sunulacak bir makalede kullanılmadan önce, kaynakların son sürümleri yeniden kontrol edilmeli; kaynak kodu kayıtlarının güncel durumları belirtilmeli ve araştırmacılar tarafından gerçekleştirilen testler varsa yöntem, ortam ve sonuçlarıyla belgelenmelidir.

Resmî kaynaklarda açıklanan bulgular ile bağımsız olarak test edilmemiş senaryolar birbirinden ayrılmalıdır. Örnek hata çıktıları gerçek deney sonuçları gibi sunulmamalı; test edilmemiş yapılandırmalar için kesin güvenlik hükümleri verilmemelidir.