Kaynaklar 22 Ekim 2026 itibarıyla kontrol edildi. A Dinleyiciler: PHP uygulama operatörleri, güvenlik müdahale görevlileri ve özel PHP yapılarının bakımını yapan mühendisler.
Bu makalede PHP2Shell güvenlik açığının nedeni, etki kapsamı, resmi onarım süreci, geçici etki azaltma önlemleri ve resmi yama uygulaması özetlenmektedir. Ana metin S1; tüm kaynak bağlantıları metnin sonundaki ekte listelenmiştir. Yapılandırma parçası, gerçek sürüme, iş kapasitesine ve yapılandırma devralma ilişkisine göre ayarlanması gereken bir dağıtım şablonudur.
TL;DR: Onarım adımları ve öneriler
- PHP çalışma zamanını yükseltin: ilgili dalı en az 8.2.35, 8.3.36, 8.4.27 veya 8.5.12’ye yükseltin. Dağıtım paketleri için satıcının her iki CVE’yi de düzelttiğini onayladığı tam paket sürümünü kullanın. S1S10
- Tüm eski süreçleri değiştirin: Yükseltme sonrasında her PHP worker, barındırma hizmetini ve kapsayıcıyı yeniden başlatın veya devredin ve eski örneklerden çıkıldığını doğrulayın.
- Gerçek Web istek yolu aracılığıyla doğrulayın: Web SAPI’yi, tam paket sürümünü ve çalışan örneği kontrol edin.
php -v’nin tek başına kontrol edilmesi, canlı hizmetin sabit olduğunu göstermez. - İş regresyon kontrollerini çalıştırın ve kaynak bütçelerini normale döndürün: oturum açmayı, oturum yönetimini, yüklemeleri, içe aktarmaları ve hata işlemeyi test edin. PHP bellek sınırı geçici olarak kaldırıldıysa, yama uygulamasından sonra uygun bir sınırlı bütçeyi geri yükleyin.
- Anında yükseltme imkansızsa: güvenilmeyen trafiği PHP’ye ulaşmadan önce kısıtlayın. Yükleme ilerlemesini ve PHP 8.5 ölümcül geri izlemeleri Bölüm 5’te açıklandığı şekilde devre dışı bırakmayı değerlendirin. Yapılandırma azaltımları ve WAF kurallarının kapsamı sınırlıdır ve yükseltmenin yerini tutamaz. S1S2S3
1. Güvenlik Açığı Genel Bakışı ve Risk Değerlendirmesi
Bu makaledeki PHP2Shell, 21 Ekim 2026’da PHP tarafından resmi olarak açıklanan iki Critical düzeyindeki güvenlik açığına atıfta bulunmaktadır. Her ikisi de PHP motorunun bellek ve istek yaşam döngüsü yönetimiyle ilgilidir ve kimliği doğrulanmamış uzaktan kod yürütme riski oluşturur. S1S2S3
| Proje | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| resmi ad | RCE via OOM corruption | RCE via stale global state |
| temel sorunlar | Yetersiz bellek anormal bir atlamaya neden olur ve henüz başlatmayı tamamlamamış bir durum bırakır. | Worker’da kalan genel durum, serbest bırakılan istek belleğine işaret eder. |
| Tipik oluşma zamanı | Mevcut isteğin başlatılması, yürütülmesi veya temizlenmesi süreci | Önceki istek durumu terk eder ve sonraki istekler durumu önceden tüketir. |
| OOM gerekli bir koşul mudur? | Güvenlik açığının temel tetikleme mekanizmasına aittir | Hayır; diğer ölümcül hatalar ve teşhis sonrası temizleme de söz konusu olabilir |
| Temel onarım yönü | Tahsis Hatalarını ve Talep Sonlandırmalarını Güvenle Ele Alın | Durum sahipliğini, temizleme zamanlamasını ve erken başlatmayı düzeltin |
| Bertaraf gereklilikleri | tamir edilmeli | aynı anda onarılması gerekir |
Temel: İki resmi güvenlik bülteni ve düzeltme gönderimi. S2S3S4
1.1 Etkilenen dağıtımları anlama
PHP resmen düşünüyor Tümü PHP dağıtımların işlenmesi Web istekler risk altında olanlar da dahil PHP-FPM , Apache mod_php , php-cgi , FrankenPHP , Ve LiteSpeed . Gösterilen mod_php Saldırı, uygulama kodu çalıştırılmadan önce gerçekleşebilir; dolayısıyla oturum açma kontrolleri, çerçeve ara yazılımı ve uygulama yükleme doğrulaması bu yolu kapsayamaz. S1
“Konuşlandırmanın düzeltilmesi gerekiyor” ile “belirli bir saldırı zincirinin tamamen kanıtlandığı” arasında ayrım yapmak gerekiyor. CVE-2026-109618 duyurusu: FPM, istek başlatma başarısız olduktan sonra alt süreçten çıkacak ve başlatma hatasından sonra mod_php’nin karşılık gelen temizleme yolunu engelleyecektir; ancak başarılı başlatmanın ardından OOM yolu hala risk altındadır. Duyuruda ayrıca bu CVE için tam FPM istismarının henüz gösterilmediği belirtiliyor. Bu kısıtlama FPM’nin güvenli olduğu sonucuna varmak için kullanılamaz, özellikle CVE-2026-109619 göz ardı edilemez. S2S3
Başarılı bir kullanım için anında izin sınırları, PHP’yi barındıran işlemin kimliğine ve erişimi olan kaynaklara bağlıdır. Genel olarak web sitesi koduna, yükleme dizinine, veritabanı kimlik bilgilerine, hizmet belirteçlerine ve dahili ağ erişim özelliklerine dikkat edilmelidir; “uzaktan kod yürütme”, doğal olarak kök izinleri elde etmek anlamına gelmez. Buradaki sonuç kararı süreç izin modeline dayanmaktadır ve gerçek etkinin dağıtım izinleriyle birlikte değerlendirilmesi gerekmektedir.
Sıradan tek seferlik CLI komut dosyaları aynı HTTP girişine sahip değildir; ancak CLI’de veya yerleşik modda harici görevleri uzun süre yürüten işlemlerin yine de çalışma zamanı ve yaşam döngüsü envanterine dahil edilmesi gerekir. Yalnızca CMS, çerçeve veya Composer bağımlılıkları güncellenir ve temeldeki PHP motoru otomatik olarak değiştirilmez.
2. Sebep analizi
2.1 Öncelikle iki yaşam döngüsünü anlayın
PHP worker genellikle birden fazla isteği arka arkaya işler. İstek sırasında tahsis edilen bellek, isteğin sonunda eşit şekilde serbest bırakılabilirken, işçinin kendisi ve bazı küresel alanları varlığını sürdürür.
Bu nedenle motor iki kısıtlamayı korumalıdır:
- Başlatma kısıtlaması: Diğer kodlar tarafından görülebilen veriler güvenli bir şekilde okunabilecek, üzerinden geçilebilecek ve yok edilebilecek bir durumda olmalıdır.
- Yaşam döngüsü kısıtlaması: istek belleği serbest bırakıldığında, daha uzun ömürlü alanlar bu bellekteki adresleri geçerli durum olarak değerlendirmeye devam etmemelidir.
Bu iki kısıtlama, iki güvenlik açığı grubunun ana hata modlarına karşılık gelir. Aşağıdaki süreç, duyuruları ve yama derlemesini birleştiren bir mekanizma açıklamasıdır. Bu, her dağıtımın tam olarak aynı erişilebilir yola sahip olduğu anlamına gelmez. S2S3S5
2.2 CVE-2026-109618: OOM, tamamlanmamış bir durum güncellemesini kesintiye uğrattı
Eski uygulama, OOM’yi işlemek için longjmp() türünde yerel olmayan bir atlama kullanır ve ilgili yol, mevcut yürütme bağlamından zend_bailout() aracılığıyla çıkar. Buradaki tehlike, C kodunun bir parçasının başka bir koda yeni bir nesne, dizi veya istek durumu yayınlamış olması ancak alan başlatma işleminin tamamını henüz tamamlamamış olmasıdır; bu sırada ilgili zamandaki herhangi bir tahsis hatası normal kapanış adımlarının atlanmasına neden olabilir. S2
Başarısızlık süreci dört adıma ayrılabilir:
- İsteğin iç yapısını oluşturun veya güncelleyin ve erişilebilir hale getirin.
- Sonraki bellek tahsisi başarısız olur ve OOM tetiklenir.
- Yürütme akışı geçerli işlevden atlar ve başlatmayı tamamlamak veya durumu geri yüklemek için orijinal olarak kullanılan kod yürütülmez.
- İstek temizleme işlemi bu yapıları işlemeye devam eder ve geçersiz içerikleri geçerli alanlar veya adresler olarak ele alır.
Sorun, belleğin tükenmesinin her zaman RCE’ye neden olması değildir. Aksine, bellek tükenmesi kontrol akışını değiştirir ve motorun geçerli yapılara ilişkin varsayımlarını ihlal eder. Başarısız tahsisin, sonuçta yanlış okunan yapıyı doğrudan içermesi gerekmez. S2
Neden daha küçük isteklerin de belleği tükenebilir?
İstek gövdesindeki bayt sayısı ile ayrıştırma sonrasındaki yığın kullanımı aynı şey değildir. A alanı, PHP içindeki birden çok dizeye, dizi öğesine ve meta veri nesnesine karşılık gelebilir; girdi yapısal karmaşıklığı hafıza amplifikasyonunun derecesini etkileyecektir.
Resmi duyuruda çok parçalı olarak listelenen sorunlar arasında şunlar yer alıyor: mevcut bildirim uzunluğu eksik olduğunda ilk boyut kontrol boşluğu, tek bir parça için başlık sayısı yeterince sınırlı değil ve boş dosya kontrolleri hala meta veriler üretiyor ve iç içe adlar dizi iş yükünü daha da artırıyor. Uygulamanın kendi girdi çözme, kod çözme veya yeniden atama işlemleri de OOM kaynağı olabilir. S2
Bundan iki koruyucu sonuç çıkarılabilir:
- PHP’ye girmeden önce istek gövdesi kısıtlamaları mümkün olduğunca uygulanmalı ve gerçek okuma uzunluğu ve yapısal karmaşıklık dikkate alınmalıdır.
- Dosya boyutunun ve dosya sayısının ayrı ayrı sınırlandırılması veya yalnızca bir yükleme portalının kapatılması, tüm OOM kaynaklarını kapsayamaz.
Uygulama kimlik doğrulaması neden çok geç olabilir?
mod_php’de istek gövdesi, istek başlatma aşaması sırasında otomatik olarak ayrıştırılabilir; başlatma başarısız olsa bile ilgili istek temizliği yine de gerçekleştirilecektir. Bu nedenle, onaylanmış saldırı yolları uygulama kodundan önce gerçekleşebilir. Bu aşamada riske maruz kalmayı azaltmak için ters proxy’ye, Web sunucusuna veya PHP istek işlemeden önce gelen diğer sınırlara kısıtlamalar getirilmesi gerekir. S1S2
2.3 CVE-2026-109619: İstek belleği serbest bırakıldı, genel referans hala hayatta
Bu sorun hata, oturum, nesne veya uzantı durumunu içerir: alan, çalışanın uzun vadeli erişim konumunda depolanır, ancak alanın referans verdiği veriler tek bir isteğe aittir. Referans, istek yığını serbest bırakılmadan önce düzgün bir şekilde temizlenmediği sürece, sonraki istekler, serbest kullanım sonrası kullanım oluşturacak şekilde sarkan bir durumla karşılaşabilir. S3
Resmi analiz, sömürü koşullarını “üreticiler” ve “tüketiciler” olarak ikiye ayırıyor:
| rol veya koşul | anlam | Korumaya yönelik çıkarımlar |
|---|---|---|
| devlet yapımcısı | Bu isteğin sahip olduğu durumu daha sonra erişilebilecek bir konuma yerleştirin | Anormal çıkıştan sonra ilgili temizliğin tamamlanıp tamamlanmadığını kontrol etmek için |
| Durum kalır | Temizlenmedi ya da geç bir operasyonla temizlenip yeniden dolduruldu. | Daha önceki kapatma aşamasında yalnızca bir kez temizlemek yeterli olmayabilir |
| işçinin yeniden kullanımı | Aynı çalışan sonraki talepleri işlemeye devam ediyor | Birden fazla çalışan yalnızca bir planlama farkıdır, bellek güvenliği garantisi değildir |
| peşin tüketici | İlgili durum normal şekilde başlatılmadan önce artık değeri okuyun, serbest bırakın veya belirleyin. | Başlatmadan önce INI, oturum ve diğer yollar kontrol edilmelidir |
Bu koşulların bir arada karşılanması gerekir; herhangi bir hata günlüğü tek başına güvenlik açığından başarıyla yararlanıldığını kanıtlamaz. S3
Gerekli bir ön koşul olarak OOM gerektirmez
Önemli hatalar, eşleştirilmiş durumun yayınlanmasını ve geri yüklenmesini kesintiye uğratabilir. Derleme veya ayrıştırma hataları, yakalanmamış hatalar, require hataları ve yürütme zaman aşımları belirli durumları geride bırakabilir. Temizleme işleminin sonlarında yapılan ölümcül olmayan tanılamalar, önceden temizlenmiş olan hata bilgilerini de yeniden doldurabilir. S3
Bu nedenle memory_limit’yi sınırsız olarak değiştirmek bu güvenlik açıklarını kapsamaz.
”Başlatmadan önce” ayrı olarak ele alınmalıdır
İki tür onaylanmış tüketicinin zamanlaması farklıdır:
- Erken INI tanılama: İstek üzerine uygulanan bazı yapılandırmalar, normal yürütücü başlatmadan önce uyarı, bildirim veya kullanımdan kaldırma sorunu çıkarır ve tanılama işlemi eski hata durumuna erişebilir.
- Oturum yükleme ilerlemesi: oturum, istek gövdesi ayrıştırma işlemi sırasında önceden işlenebilir, ancak normal modül
RINIThenüz tamamlanmamıştır; uygulama açıkçasession_start()’yi çağırmadığından yolun var olmadığı sonucu çıkarılamaz. S3
Tüm INI yapılandırmaları aynı risk zamanlamasına sahip değildir. FPM ön uç tarafından iletilen mod_php ve PHP_VALUE / PHP_ADMIN_VALUE’nin dizin düzeyinde yapılandırmasının, sıradan php.ini, FPM pool başlangıç yapılandırmasından ve FPM .user.ini’den ayırt edilmesi gerekir. İkincisi, farklı konfigürasyon zamanlamasına sahiptir ve toplu olarak aynı erken tüketiciler olarak adlandırılamaz. S3
display_errors, log_errors’nin kapatılması, error_reporting’nin azaltılması veya @’nin kullanılması yalnızca teşhisin görünürlüğünü etkiler; Günlüğün çıktısının alınıp alınmayacağına karar verilmeden önce ilgili dahili duruma erişilmiş olabilir. S3
3. Onarım sürümü ve yama seçimi
3.1 Resmi yukarı akış düzeltme temeli
| Mevcut PHP şubesi | Bu resmi düzeltmeyi içeren ilk sürüm | Öneriler |
|---|---|---|
| 8.2 | 8.2.35 | Bu sürüme veya aynı düzeltmeleri içeren sonraki bir sürüme yükseltin |
| 8.3 | 8.3.36 | Yukarıdakiyle aynı |
| 8.4 | 8.4.27 | Yukarıdakiyle aynı |
| 8.5 | 8.5.12 | Yukarıdakiyle aynı |
| 8.1 ve önceki sürümler | Yukarı akış genel desteği sona erdi | Desteklenen şubelere geçişe öncelik verin; kısa vadeli kontrol yayını veya LTS üretici desteği |
Sürüm ve destek durumu, PHP’nin resmi duyurusuna dayanmaktadır ve zaman aralığı 22 Ekim 2026’dır. S1
Bunlar Şubeye özgü düzeltme eşikleri’dir. Bunlar, 8.5.12’nin altındaki her sürümün güvenlik açığına sahip olduğunu belirten bir ifadeyle değiştirilemez: diğer dallardaki 8.2.35 ve 8.4.27 gibi sürümler zaten düzeltmeleri içermektedir.
3.2 Tam dağıtım paketi sürümünü kontrol edin
Dağıtımlar genellikle eski yukarı akış sürümlerini temel alan güvenlik düzeltmeleri ekler. Kabulde ayrıca yayın sürümü, depo kaynağı, tam paket sürümü ve güvenlik bülteni de kontrol edilmelidir.
Örneğin, Ubuntu USN-8948-1 için listelenen Ubuntu 24.04 LTS düzeltme paketi sürümü şöyledir:
8.3.6-0ubuntu0.24.04.13Yukarı akış kısmı hala 8.3.6’dir, ancak bu dağıtımın tam paket sürümü bu düzeltme duyurusuna dahil edilmiştir. Bu sonuç yalnızca ilgili dağıtım ve paket kaynağı için geçerlidir ve 8.3.6 görüntüleyen herhangi bir yapıya genelleştirilemez. S10
3.3 Doğru yamayı seçme
| sahne | Öncelik planı | Kabul için önemli noktalar |
|---|---|---|
| PHP dağıtım paketini kullanma | Üretici tarafından yayımlanan güvenlik güncellemelerini yükleyin | Duyuru hem CVE’yi; tam paket sürümü doğru |
| Resmi PHP kapsayıcısını veya kendi oluşturduğunuz görüntüyü kullanın | Temel çalışma zamanını güncelleyin, yeniden oluşturun ve dağıtın | Çalışan örnek yeni görüntüyü kullanır; tüm eski kopyalardan çıkıldı |
| Kendi kendine derlenen desteklenen dallar | Bu dalın resmi güvenlik sürümünü veya tam resmi yama setini kullanın | Dal eşleştirme, bağımlılık tamamlama, uzantı uyumluluğu ve regresyon geçişi |
| 7.4, 8.0, 8.1’ye tabidir | Satıcı desteğine öncelik verin; gerekirse resmi acil durum kaynak kodu dalını değerlendirin | Davranış değişikliklerini belirleyin ve desteklenen sürümlere geçişi planlayın |
Resmi yamalar yayınlandı ve gerçek düzeltmeler bu yamalardan başlamalı. Bölüm 6’daki kod parçacıkları, tasarımı ve gözden geçirilen önemli noktaları göstermeyi amaçlamaktadır ve bağımsız olarak uygulanabilecek eksiksiz bir yama oluşturmamaktadır. S1S4S6
4. Resmi onarım süreci
4.1 İstekleri fiilen işleyen çalışma zamanının envanteri
En azından aşağıdakileri kaydetmek için kısa bir defter oluşturulması tavsiye edilir:
- Giriş alan adı veya hizmeti, ters proxy arka ucu, PHP SAPI.
- PHP şubesi, tam paket sürümü veya görüntü özeti, derleme kaynağı.
- FPM pool, gerçek hizmet birimi, konteyner veya Pod, kopya sayısı.
- Uzantılar, ana konfigürasyon ve ek konfigürasyon dosyaları yüklendi.
- Doğrudan erişilebilen başka PHP sürümleri, eski dağıtım kopyaları veya kaynak portalları var mı?
Bunlar, “yükseltilmiş” ifadesinin her gerçek trafik girişine karşılık gelebilmesi için uygulama önerileridir. Özellikle PHP ve Web PHP komut satırlarının farklı sürümler kullanıp kullanmadığını, görüntünün oluşturulduğunu ancak eski kapsayıcının hala çalıştığını, havuzun bir kısmının veya kopyanın değiştirilmediğini vb. kontrol edin.
4.2 Doğru güncellemeyi seçin ve dağıtın
Tercihen mevcut bir güvenilir paket kaynağı veya kontrollü yapı zinciri kullanarak düzeltme sürümünü Bölüm 3’e göre onaylayın. Güncelleme kapsamı, FPM paketi, Apache PHP modülü, CGI ikili dosyası veya PHP’nin gömülü olduğu hizmet yapısı gibi, isteği gerçekten barındıran bileşeni içermelidir.
Yükseltmeden önce yapılandırmayı ve paket listesini saklayın ve üretim ortamına benzer bir ortamda başlangıç ve anahtar hizmetlerini doğrulayın. Kendi kendine bakımı yapılan uzantılar için, PHP sürümüne karşılık gelen derleme ve çalıştırma uyumluluğunu kontrol edin. Sadece başka bir şubeden görünüşte alakalı bir taahhüt seçmek, tüm düzeltmelerin uygulandığını garanti etmez.
4.3 Çalışan örnekleri yeniden başlatın veya devredin
Bir dosya yüklemek ve bir işleme yeni kod yüklemek iki farklı şeydir. İlgili hizmet yeniden başlatılmalı veya yuvarlanma değişimi tamamlanmalı ve eski çalışanın ve eski konteynerin çıktığı doğrulanmalıdır.
mod_php için modülü barındıran Apache işlemini yeniden başlatın. PHP’yi içeren hizmetlerin barındırma işlemlerinin değiştirilmesi gerekiyor. FPM için OPcache’nin temizlenmesi, çalışma zamanının güncellenmesinin ve eski çalışanların emekliye ayrılmasının yerini almaz.
Zarif anahtarlamayı kullanırken, eski nesil sürecin hala uzun bağlantıları veya bekleyen istekleri işleyip işlemediğini kontrol etmeniz gerekir. Kabul kaydı, eski örneğin gerçek hizmetini, dağıtım sürümünü, değişikliğin tamamlanma süresini ve çıkış sonuçlarını içermelidir.
4.4 Gerçek Web istekleri aracılığıyla doğrulama
Yalnızca tek bir komut sürümüne güvenmek yerine aşağıdaki kanıt parçalarının birleştirilmesi önerilir:
| kanıt | Ne kanıtlanabilir? | Tek başına hiçbir şeyi kanıtlayamam |
|---|---|---|
| Paket yöneticisi veya görüntü meta verileri | Kurulum kaynakları ve tam sürümler | Trafik bu örneğe değiştirildi |
| İşlem ve dağıtım durumu | işçi veya konteyner değiştirmeyi tamamlıyor | Dış giriş ona yönlendirilmelidir |
| Gerçek portal üzerinden erişilen kısıtlı teşhis sonuçları | Gerçek Web SAPI ve çalışan yapılandırma | Sürüm destek portunun iki CVE’yi kapsayıp kapsamadığı |
| Satıcı duyurusu veya tam yama kaydı | Bu hata düzeltmesi bu yapıya dahil edilmiştir | Tüm kopyalar dağıtıldı |
PHP_VERSION, PHP_SAPI, yüklenen yapılandırma dosyaları ve acil durum yapılandırmaları, mevcut dahili tanılama yetenekleri veya geçici ve erişim kontrollü tanılama portalları aracılığıyla kontrol edilebilir. İsteğin doğrudan CDN veya sayfa önbelleği tarafından döndürülmediğinden emin olun; tamamlandığında geçici tanı girişini kaldırın.
php -v genellikle yalnızca halihazırda kabuk tarafından seçilen CLI ikili dosyasını gösterir; php-fpm -i gibi komutlar, trafik alan mevcut çalışanın doğrulanmasına eşdeğer değildir. phpinfo() sayfasının tamamını uzun süre genel ağa maruz bırakmayın.
4.5 İş regresyon kontrolleri ve acil durum ayarlarının kaldırılması
Bu değişiklikten etkilenen işlevlerde normal oturum açma, oturum okuma ve yazma, form ve yükleme, içe aktarma, hata işleme ve çalışan kararlılığını doğrulayın. Hata oranının, yanıt gecikmesinin, bellek zirvesinin, işlem çıkışının ve yeniden oluşturma sıklığının anormal olup olmadığını kontrol edin.
memory_limit=-1 geçici olarak ayarlanırsa iş kapasitesine uygun sınırlı bütçe, resmi yama yürürlüğe girdikten sonra geri yüklenecektir; pm.max_requests=1 ayarlandıysa, kapasite değerlendirmeli yaşam döngüsü yapılandırması onarım onaylandıktan sonra geri yüklenecektir. Giriş boyutu sınırları ve kaynak erişim kontrolleri, iş ihtiyaçlarının gerektirdiği şekilde muhafaza edilebilir.
Yükseltme sırasında uyumluluk sorunları ortaya çıkarsa, etkilenen portalın askıya alınmasına, harici erişiminin kısıtlanmasına veya geri dönmeden önce uygulamanın ayarlanmasına öncelik verilmelidir. Onarılmamış çalışma zamanının doğrudan genel ağa hizmet vermesine izin vermek orijinal riski yeniden açacaktır.
5. Hemen yükseltmenin mümkün olmadığı durumlarda azaltıcı önlemler
Bu bölüm, maruziyetin kısa vadede azaltılması veya kullanılabilirliğin iyileştirilmesi için tasarlanmıştır. Her önlem yalnızca belirli bir yolu kapsar ve birden fazla önlemin birleşimi tam bir onarım anlamına gelmez. S1S2S3
5.1 PHP’den önce trafik kontrollerine öncelik verin
Hizmet izin veriyorsa, hassas uç noktaları geçici olarak güvenilir kaynaklarla sınırlayın veya PHP’den önce erişim kontrolünü zorunlu kılın. Yükleme iş yükleri için istek gövdesi boyutunu, alan sayılarını, parça sayılarını, parça başına başlıkları ve yerleştirme derinliğini sınırlayın. Çok parçaya ihtiyaç duymayan hizmetler ön uçta bunu reddedebilir. S2
Bu kısıtlamalar PHP’ye tüm girişleri kapsayacaktır. Yalnızca “upload” adlı URL’nin ele geçirilmesi, istek gövdesinde PHP tarafından otomatik olarak ayrıştırılan diğer girişleri kaçıracaktır. Parçalanmış aktarımlar, beyan edilen uzunluğun bulunmaması vb. gibi durumlarda sınır, gerçek okuma boyutuna dayanmalıdır; içeriğin sıkıştırmasını açarken veya tekrar genişletirken uygulamanın kendi çıktı boyutu bütçesine de sahip olması gerekir.
5.2 FPM pool yapılandırma şablonu
FPM pool yapılandırma bölümüne aşağıdaki ayarları, php.ini’de kelimesi kelimesine değil, gerçekte isteklere hizmet eden yerleştirin. 8M ve 4M değerleri iş yüküne göre ayarlamaya yönelik örneklerdir. POST isteğinin tamamını sınırlandırırken form alanları ve çok parçalı sınırlar için yer bırakın. S11S12
; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = offYalnızca PHP 8.5, artı:
php_admin_flag[fatal_error_backtraces] = offHer birinin işlevleri ve sınırları aşağıdaki gibidir:
| Yapılandırma | beklenen etki | Korunması gereken kısıtlamaların açıklaması |
|---|---|---|
memory_limit=-1 | Tahmin edilebilir PHP istek belleği üst limit tetikleme koşulunu kaldırın | Temel tahsisat hatasını engellemez; Orijinal bütçenin iptal edilmesi hafızanın tükenmesi ve hizmet kesintisi riskini artırabilir. |
Daha küçük post_max_size | Ayrıştırma işlemine giren verilerin boyutunu azaltın | Sabitlenmemiş ayrıştırıcının bilinen bir boşluğu vardır; Bellek amplifikasyonu bağımsız olarak önlenemez |
upload_max_filesize < post_max_size | Tek dosya boyutunu sınırlayın ve istek ek yükünü ayırın | Tüm alanları, meta verileri veya uygulama içi tahsisleri kısıtlamaz |
| Yükleme ilerlemesini kapat | Onaylanan oturumla ilgili yolu engelle | Diğer küresel durum değişkenlerini kapsamaz |
| PHP 8.5 ölümcül geri izlemeyi kapat | Onaylanmış ilgili durum üreticilerini engelle | Oturum gibi diğer yolları kapsamaz |
Tedbir sınırları resmi duyurudan alınmıştır; havuz sözdizimi ve yönetim düzeyinde yapılandırma semantiği için PHP kılavuzuna bakın. S1S2S3S11
Yönetim düzeyindeki php_admin_* ayarları, ini_set() aracılığıyla uygulamalar tarafından geçersiz kılınamaz. Gerçek isteklerdeki değerlerin beklendiği gibi olduğunu doğrulamak için tüm havuz, dizin düzeyi ve ön uç gelen yapılandırmaların yine de incelenmesi gerekir. Değişiklikten sonra, mevcut süreçlerin eski durumunu korumaya devam etmesini önlemek için tüm çalışanları yeniden oluşturun.
php.ini’yi doğrudan değiştirmeyi seçerseniz söz dizimi şu şekilde değiştirilmelidir:
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = OffHavuzdaki php_admin_value’den farklı olarak, php.ini’de yalnızca memory_limit=-1’yi ayarlamak uygulamanın onu tekrar değiştirmesini engellemez. Sınırlı değeri sıfırlayıp sıfırlamadıklarını görmek için çerçeve, uygulama kodu ve diğer yapılandırmalar kontrol edilmelidir; uygulama gerektiğinde mevcut SAPI için uygun yönetim düzeyi ayarlarını kullanın ve gerçek etkin değeri kontrol edin. S11S12
fatal_error_backtraces = Off’yi yalnızca PHP 8.5 için ekleyin. Yükleme ilerlemesini devre dışı bırakmak için uygulama düzeyindeki ini_set()’yi geçici çözüm olarak kullanmayın ve istek ayrıştırmadan önce bunun etkili olması için FPM .user.ini’ye güvenmeyin. S1S3
5.3 PHP bellek sınırlarını kaldırmanın maliyetini yönetin
memory_limit=-1, sabitlenmemiş ortamlar için geçici bir yol azaltımıdır ve uzun vadeli varsayılan yapılandırma olarak kopyalanmamalıdır. Bir uygulama veya istek kontrolden çıktığında ana bilgisayarın belleğinin daha fazlasını kullanabilir. Bu nedenle, kullanımdan önce eşzamanlılık sayısını, en yüksek tek çalışanı ve toplam hizmet kapasitesini değerlendirmeli ve ön uç giriş sınırlarını dağıtmalısınız. S2
Konteyner veya grup bellek sınırları, kullanılabilirlik sınırları sağlayabilir ancak ayırmaların hiçbir zaman başarısız olmayacağını garanti etmez; Limit tetiklendiğinde konteynerin tamamı, ana ve tüm çalışanlar da sonlandırılabilir. Yalıtım ayrıntı düzeyi ve sonlandırma stratejilerinin dağıtımla birlikte değerlendirilmesi gerekir ve bu iki CVE için tam koruma olarak adlandırılamaz. S2
Yukarıdaki stratejileri RLIMIT_AS, RLIMIT_DATA veya karşılık gelen işlem adresi alanı kısıtlamalarıyla değiştirmeyin; doğrudan temel tahsisin hâlâ sorunlu olan OOM yolunda başarısız olmasına neden olabilirler. S2
5.4 Nginx Yapılandırma Örneği
Nginx’nin istekleri PHP-FPM’ye ilettiği dağıtım için geçerlidir. Gerçek barındırma hizmetinin yapılandırma düzeyinde ayarlanabilir:
client_max_body_size 8m;
fastcgi_request_buffering on;client_max_body_size istek gövdesi boyutunu sınırlar; fastcgi_request_buffering on, Nginx’nin önce istek gövdesinin tamamını okumasını ve ardından onu FastCGI arka ucuna göndermesini sağlar. Belirli bir server’de mi yoksa location’de mi geçerli olacağı, mevcut miras ve kapsam ilişkileriyle birlikte kontrol edilmelidir. S13S14
Yalnızca işletmenin çok parçalı parçaya ihtiyacı olmadığında, ilgili hizmet girişine bir ret kuralı ekleyebilirsiniz:
if ($http_content_type ~* "multipart/form-data") {
return 403;
}Bu, ayrıştırıcı güvenlik açıklarına yönelik genel bir filtreleme kuralı değil, if ve return kullanan basit bir giriş kısıtlama şablonudur. Dağıtımdan önce yapılandırma sözdizimini ve normal istekleri doğrulayın ve özel error_page’nin 403 isteği PHP’ye yönlendirip yönlendirmediğini kontrol edin. Dize eşleştirme, tüm ayrıştırma farklılıkları konusunda tam garanti sağlamaz. S15
Ayrıca, bu yapılandırmalar veri miktarını, alan sayısını veya uygulama tarafından sıkıştırılmış PHP nesnelerinin sayısını otomatik olarak sınırlamaz; Yükleme yapması gereken işletmeler, isteklerinin yapısını anlayan ek kısıtlamalar kullanmalıdır.
5.5 İsteğe bağlı azaltım: FPM çalışanı başına bir istek
Genel giderleri karşılayabilecek FPM dağıtımları için kısa vadeli kurulumlar değerlendirilebilir:
pm.max_requests = 1Ve mevcut işçiyi yeniden inşa edin. Tanımlanan çapraz istek zincirini çalışanın yeniden kullanımı düzeyinde engeller, ancak süreç oluşturma ve başlatma yükünü artıracaktır; aynı zamanda aynı OOM isteğini ve CVE-2026-109618 temizleme sorunlarını onaramaz. Değer 1’den küçük ancak 1’den büyük olduğunda hâlâ bir istek yeniden kullanım penceresi vardır. S3S11
5.6 WAF ve Cloudflare kapsama sınırları
Cloudflare, Free planı da dahil olmak üzere PHP2Shell’ye karşı koruma için dağıtım düzenlemelerini duyurdu. Hizmetlerini kullanırken, gerçek trafiğin proxy üzerinden geçip geçmediğini, koruma kurallarının etkin olup olmadığını ve kaynak sitenin doğrudan atlanıp atlanamayacağını kontrol etmelisiniz; ücretli planlar için ilgili Yönetilen Kuralların yapılandırmasını ve istisnalarını da kontrol etmeniz gerekir. S16
Satıcı tarafından açıklanan algılamaların bazıları yanıt sinyallerini kullanır; dolayısıyla tüm korumalar “her saldırı PHP’ye ulaşmadan engellenir” şeklinde yorumlanamaz. WAF, maruziyetin azaltılmasına yardımcı olabilir ve gözlemsel bilgiler sağlayabilir, ancak PHP’ye yönelik sürekli yükseltmeler hala gereklidir. S16
5.7 Ortak önlemler neden yetersiz?
| önlemler veya hükümler | eksiklikler |
|---|---|
Yalnızca file_uploads’yi kapatın | Çok parçalı işlemlerin tümü kapsanamaz ve kendi OOM yolu uygulanamaz |
enable_post_data_reading=Off’nin ayarlanması | POST/FILES’ı otomatik olarak doldurma davranışını değiştirin; istek gövdesi uygulama tarafından hâlâ okunabilir ve normal işleri aksatabilir |
Hata görüntülemeyi kapatın, günlüğe kaydedin veya @ kullanın | Dahili tanılama işlemi hala bekleme durumuna erişebilir |
| İşçi miktarını artırın | Güvenli durum temizleme mekanizması oluşturmayın veya tek bir çalışanın yeniden kullanımını ortadan kaldırmayın |
Yalnızca disable_functions veya open_basedir’yi yapılandırın | Bu sınırlamalar C motor katmanı bellek bozulmasını düzeltmez |
| Bir sürümü veya tek bir kopyayı yalnızca bir kez kontrol edin | Tüm girişlerin ve çalışan örneklerin değiştirildiği kanıtlanamaz |
| İstisna günlüğü görünmüyor | Bu güvenlik açığının mevcut olmadığını veya daha önce istismar edilmediğini kanıtlayamaz. |
Bunlar arasında, PHP’nin yapılandırma ve güvenlik açığı mekanizmasının temeli S2S3S12’de bulunabilir; kapsam, kabul ve izin sınırlarına ilişkin yargılar bu mekanizmaların ortaya koyduğu uygulama önerilerine dayanmaktadır.
6. Resmi yamanın uygulama fikirleri ve inceleme noktaları
6.1 Doğru dal için tam düzeltmeleri kullanın
PHP 8.5 için temsili resmi başvuru şöyledir:
31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailoutTaahhüt, hem OOM çıkış mekanizmasını ayarlamak hem de başlatma aşamasında erişilebilecek genel durumu düzeltmek için iki CVE’yi açıkça ilişkilendirir. Tam farkı içeren sayfayı gönderin, bkz. S4S5. Diğer şubeler kendi resmi güvenlik sürümlerini veya eşleşen yamaları kullanmalıdır ve 8.5’de yapılan değişikliklerin herhangi bir eski sürüme doğrudan uygulanabileceği varsayılamaz.
6.2 OOM Onarım: önce işlenebilir durumu geri yükleyin ve ardından isteği sonlandırın
Resmi uygulama, yumuşak ve sert OOM işlemenin iki düzeyini sunar: Yumuşak sınıra ulaşıldığında bekleme durumu kaydedilir ve VM gibi güvenli bir konumda kontrollü bir çıkış gerçekleştirilir; Arızalı tahsis arayüzü, arayanın arızayı açıkça ele almasına olanak tanır. Doğrudan başarısızlıkla sonuçlanamayan tahsisler için, daha yüksek bir sabit eşiğin aşılması bekleniyorsa, isteklerin güvenli olmayan bir ara durumda işlenmesine devam edilmesini önlemek için süreç doğrudan sonlandırılacaktır. S2S5
Aşağıda, bekleyen OOM’yi işaretlemek için kullanılan 8.5 farkındaki anahtar kodun bir alıntısı bulunmaktadır:
EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);VM kesinti yönetimi ve diğer güvenli konumlar daha sonra zend_handle_delayed_oom()’yi arayın. Kullanıcı kodu yürütme bağlamı kontrollü bir çözme yolu kullanır; zor OOM yolu _exit(137)’yi çağırır. S5
Tasarım açısından bakıldığında, önemli değişiklikler şunlardır: Yapı bir ara durumdayken C çağrı yığınını keyfi olarak geçmekten kaçınır ve çıkışı, durum kısıtlamalarını koruyabilen bir konumuna yerleştirir. Yumuşak limit tetiklendikten sonra işlemi tamamlamak için ek hafızaya ihtiyaç duyulabilir, dolayısıyla yeni yumuşak eşik, prosesin toplam hafızası için mutlak bir üst limit olarak anlaşılamaz.
“PHP tüm zend_bailout()’yi sildi” şeklinde de özetlenemez. Yama hala belirli bağlamlarda ilgili mekanizmaları kullanıyor; sabit olan tehlikeli çıkış zamanlaması ve buna eşlik eden durum yönetimidir. S5
6.3 Tahsis arayanları ve çok parçalı ayrıştırmayı birlikte güncelleyin
Bir ayırma işlevini yalnızca “başarısızlık durumunda NULL döndür” olarak değiştirirseniz ve orijinal arayan kişi hala geçerli bir işaretçinin her zaman döndürüldüğünü varsayarsa, yeni boş işaretçi erişimleri veya eksik temizleme sunacaksınız. Yamadaki arızalı tahsis arayüzünün, arayan kontrolü ve istisna yayılımı ile birlikte gözden geçirilmesi gerekir. S5
çok parçalı ilgili düzeltmeler ayrıca gerçek okuma hacmine dayalı kümülatif kontrollerin gerçekleştirilmesini, gereksiz veya yinelenen başlıkların işlenmesini azaltmayı ve OOM beklemedeyken tutarlı çıkış ve temizleme mantığının benimsenmesini içerir. Bu değişiklikler hem kaynak amplifikasyonunu azaltır hem de ayrıştırıcının yeni OOM protokolüyle uyumlu olmasını sağlar. S5
Kendi şubelerine sahip ekipler için aşağıdaki konuların kod incelemesinin odak noktası olması önerilir:
- Durum tamamen başlatılmadan önce dış dünyaya görünür mü?
- Tahsis hatası veya geri arama istisnasından sonra sahiplik hala benzersiz ve net mi?
- Yarıda başarısız olursanız birleşik temizleme çıkışına ulaşabilir misiniz?
- Temizleme işlevi başlatılmamış veya serbest bırakılmış alanları tanıyabilir mi?
- Ayrıştırma bütçesi yalnızca güven isteği taleplerine değil, gerçek işlem hacmine mi dayanıyor?
- Yeni hata dönüş değeri tüm arayanlar tarafından ele alındı mı?
Bunlar düzeltme mekanizmasına göre özetlenen inceleme sorularıdır ve sağlanmayan bir kod tabanı için tamamlanmış bir denetimin sonucu değildir.
6.4 Çapraz istek düzeltmesi: başlatma daha erken, son temizleme daha sonra
CVE-2026-109619’ye karşılık gelen yama, aynı anda birden fazla yaşam döngüsü sınırlarını ayarlar. Aşağıda listelenen dosyalar ve işlemler örnek olarak PHP 8.5 resmi farkını almaktadır. S5
| konum | yön değiştir | Sorun çözüldü |
|---|---|---|
Zend/zend_execute_API.c vb. | Hatalar, istisnalar, işleyiciler, nesneler vb. gibi yürütücü durumunu sıfırlayın. | İstek sona erdikten sonra, bir sonraki isteğin erişebileceği eski referanslar hala mevcuttur. |
main/main.c’nin başlangıç yolu | SAPI etkinleştirilmeden önce php_basic_early_rinit()’yi arayın | Erken tüketici oluştuğunda, ilgili temel durum henüz başlatılmamıştır. |
main/main.c yolunu kapat | HTTP globals’yi yok edin ve tanımsız olarak işaretleyin | Serbest bırakılan değer hâlâ geçerli bir nesne olarak kabul ediliyor |
| istek yığını nihayet serbest bırakılmadan önce | Son hata mesajını tekrar temizleyin | Geç temizleme tanılamaları hata durumunu yeniden doldurur |
ext/session/session.c | yükleme ilerlemesi Erken yol, ilk oturum genel öğelerine başlatılır | Normal modül RINIT daha önce eski duruma erişti |
| Serileştirmeyle ilgili kod | Erken işlemlerde sınıf ayrıştırmayı ve kullanıcı geri aramalarını sınırlayın | Başlatma tamamlanmadığında ek kullanıcı kodunu yürütün |
Örneğin, başlatma sırası şunları içerir:
zend_activate();
php_basic_early_rinit();
sapi_activate();HTTP globals yok edildikten sonra durum hatası işaretini ekleyin:
zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);Bu alıntılar iki prensibi göstermektedir: Mümkün olan en erken tüketiciden önce başlat ve durumu yeniden oluşturabilecek son işlemden sonra son temizlemeyi gerçekleştir. Bir işaretçiyi yalnızca normal RINIT sırasında veya daha önceki bir kapatma aşamasında sıfırlamak, önceki veya sonraki erişimleri kaçırabilir. S5
6.5 Neden kendi “tek hat onarımınızı” yapmanız önerilmez?
Tüm zend_bailout()’yi _exit() ile değiştirmek veya yalnızca belirli bir girişe boş işaretçi denetimi eklemek, çok sayıda farklı yürütme bağlamını kapsayacaktır. Diğer durum alanlarını atlayabilir veya imhayı, genişletilmiş geri aramaları, işlem barındırmayı ve istek sonu semantiğini değiştirebilirler.
Desteklenen sürümler için, daha önce yayınlanmış olan tam düzeltmeler önceliklidir. Kendi şubelerinin geçişi, yamaların kaynağını, geçerli temel çizgileri, çatışma yönetimini ve davranış değişikliklerini kaydetmeli ve ilgili yukarı akış regresyon kullanım örneklerini ve bu iş sürecinin doğrulanmasını kullanmalıdır. Buradaki öneriler, ayırıcı, VM, oturum ve istek yaşam döngüsü değişiklikleri genelinde yamanın kapsamının analizinden gelmektedir. S4S5
7. PHP 7.4, 8.0, 8.1’nin acil durum desteği
PHP, ciddiyetine bağlı olarak üç eski dalın minimum kaynak kodu desteğini resmi olarak sağlar. Şube isimleri şunlardır:
PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619Şube bağlantıları için bkz. S7S8S9. Bunlar, bu güvenlik açığına yönelik acil durum teslimatlarıdır ve eski şube için düzenli yukarı akış desteğine dönüşü temsil etmez veya diğer güvenlik güncelleştirmelerinin yerine geçmez. S1
7.1 Örnek olarak PHP 8.1 destek portunu alın
PHP 8.1 için ilgili gönderimler şunlardır:
1d7dec178a094e6e75b229ce22754045f8c6070aStratejisi hızlı arızayı tercih eder: karşılık gelen OOM yolunda teşhis çıktısı aldıktan sonra _exit(1)’yi çağırmak ve genel durumu ve diğer ilgili düzeltmeleri dahil etmek; oturum yükleme ilerlemesinin ilgili işlenmesini dahili olarak devre dışı bırakırken. İlgili kaynak kodu gönderimi için bkz. S6.
Bu, desteklenen daldaki daha eksiksiz gecikmeli OOM tasarımından davranışsal bir farklılıktır. Yapılandırmanın hâlâ yükleme ilerlemesinin açık olduğunu göstermesi, bu destekten sonraki dahili işleme davranışının değişmeden kalacağı anlamına gelmez.
7.2 Dağıtım sırasında kabul etmeniz gereken fiyat
İşlemden doğrudan çıkmak, mevcut isteğin başarısız olmasına, normal PHP kapatma geri çağrılarının ve uygulamanın kapatılmasının bir kısmının atlanmasına neden olabilir; Ana bilgisayar bir iş parçacığı modelini benimserse, tüm ana bilgisayar işlemi çıkışının diğer eşzamanlı işler üzerindeki etkisini de değerlendirmek gerekir. Süreç yöneticisinin değiştirme sürecini zamanında başlatıp başlatamayacağı da doğrulamaya dahil edilmelidir.
Bu nedenle, eski sürümlerin kullanıcıları sırasıyla şunları dikkate almalıdır:
- Desteklenen PHP şubesine ve sabit sürümüne geçiş yapın.
- Hem CVE hem de LTS üretici güncellemesini açıkça kapsayan bir sürüm kullanın.
- Gerçekten kaynak kodun eski sürümüne tabiyse, tüm değişiklikleri ve uyumluluğu doğrulamak ve sonraki geçişi ayarlamak için eşleşen sürümün resmi acil durum destek raporunu kullanın.
Buradaki “minimum destek”, yetkili tarafından seçilen uyumluluk ve uygulama kapsamını açıklamaktadır ve otomatik olarak “bilinen eksik güvenlik açığı düzeltmeleri” olarak yorumlanmamalıdır. İlgili branşın kaynak koduna ve üreticinin duyurusuna göre karar vermeli, destekleyici değişiklikleri kendi başınıza silmemelisiniz. S1S6
8. Kabul kriterleri ve takip muayeneleri
Bu onarımın tamamlanması için aşağıdaki sonuçların temel olarak kullanılması önerilir:
| Kabul öğeleri | Tamamlama standartları |
|---|---|
| güvenlik açığı kapsamı | Derleme veya satıcı duyurusu, CVE-2026-109618 ve CVE-2026-109619’yi açıkça düzeltir |
| Dağıtım kapsamı | Tüm portallar, havuzlar, hizmetler ve replikalar onarılan çalışma zamanını kullanır |
| Süreç yürürlüğe giriyor | Eski işçi, eski ana bilgisayar işlemi ve eski kapsayıcının tümü çıkar |
| Orijinal istek doğrulaması | Onaylanmış SAPI, önbellek yanlış yönlendirmesini ortadan kaldırmak için gerçek Web bağlantısıyla oluşturulmuş ve yapılandırılmıştır |
| iş kullanılabilirliği | Oturum, yükleme, içe aktarma ve hata işleme gibi temel işlevler normal şekilde geri döndü. |
| Geçici önlemlerin sona ermesi | Sınırsız bellek ve aşırı çalışan geri dönüşüm yapılandırmaları, kapasite planına göre geri yüklendi veya açık bir saklama nedeni var |
| Değişimin kanıtı | Paket sürümünü veya görüntü özetini, güncelleme kapsamını, tamamlanma süresini ve doğrulama sonuçlarını kaydedin |
Yukarıdakiler uygulamaya yönelik önerilerdir. OOM davranışını, anormal çıkışı veya özel yamaları doğrulamanız gerekiyorsa bir kabul yöntemi olarak üretim ortamında tekrar tekrar bellek tükenmesi oluşmasını önlemek için yalıtılmış bir ortamda yukarı akış regresyon testini veya kontrollü hata eklemeyi kullanmalısınız.
Ayrıca güncelleme öncesinde ve sonrasında PHP ölümcül, çalışan kazası, anormal yeniden başlatma, istek hatası oranı ve WAF olaylarını da kontrol edin. Günlükler yalnızca araştırma ipuçları sağlayabilir: OOM’nin ortaya çıkması, istismar edildiği anlamına gelmez ve alarmların olmaması, herhangi bir istismarın meydana gelmediğini kanıtlamaz. Yükseltme, gelecekte ulaşılabilecek güvenlik açığı yollarını düzeltir; Dosyada tahrifat yapılması veya kimlik bilgilerinin sızması gibi anormallikler bulunursa ayrı olay incelemeleri yapılmalıdır.
Ek: Alıntılanan kaynaklar ve bağlantılar
Tüm kaynak bağlantıları aşağıda toplanmıştır. Öneriler, yamalar ve satıcı kılavuzları, 22 Ekim 2026 itibarıyla yapılan kontrolleri yansıtmaktadır; sonraki dağıtımlar satıcı güncellemelerini kontrol etmelidir. Metindeki numaralı alıntılar bu girişlere atıfta bulunmaktadır.
S1 — PHP resmi güvenlik bülteni ve onarım sürümü
- Kaynak: Project PHP, 21 Ekim 2026.
- Amaç: Eski şubeler için risk kapsamı, dört resmi onarım versiyonu, resmi geçici önlemler ve acil durum destek talimatları.
- Kaynak: PHP 2026 This security bulletin yıllık bülten arşivindedir
S2 — CVE-2026-109618 Resmi Teknik Bülten
- Kaynak: php/php-src GitHub Security Advisory, 21 Ekim 2026.
- Tanımlama: GHSA-w8hw-w9fx-j79w.
- Amaç: OOM için kapsama sınırı, çok parçalı amplifikasyon, SAPI farkı ve hafifletme.
- Kaynak: RCE via OOM corruption
S3 — CVE-2026-109619 Resmi Teknik Bülten
- Kaynak: php/php-src GitHub Security Advisory, 21 Ekim 2026.
- Tanımlama: GHSA-6wmf-4rv5-p3rp.
- Amaç: Çapraz istek sarkma durumu, üreticiler ve tüketiciler, erken başlatma, konfigürasyon azaltma.
- Kaynak: RCE via stale global state
S4 — PHP 8.5 resmi düzeltme gönderimi
- Kaynak: php/php-src.
- Gönder:
31c0ea7d7ff1d1fccb6492e52dab544011628065. - Amaç: İki güvenlik açığını aynı anda düzeltmek için resmi gönderimi onaylayın ve genel değişiklik yönünü açıklayın.
- Kaynak: Avoid state corruption via bailout
S5 — PHP 8.5 Resmi olarak restore edildi ve fark tamamlandı
- Kaynak: aynı resmi sunumdan farklı.
- Amaç: Ayırıcının, VM, HTTP globals, oturumun, serileştirmenin ve istek yaşam döngüsünün özel uygulamasını kontrol edin.
- Kaynak: official complete diff
S6 — PHP 8.1 resmi acil durum destek raporu gönderimi
- Kaynak: php/php-src.
- Gönder:
1d7dec178a094e6e75b229ce22754045f8c6070a. - Amaç: Eski dalların hızlı çıkışını kontrol etmek ve ilerleme durumu davranış değişikliklerini yüklemek.
- Kaynak: PHP 8.1 Emergency backport submission
- Kaynak: corresponds to complete diff
S7 — PHP 7.4 resmi acil durum destek şubesi
- Kaynak: Resmi güvenlik bülteninde listelenen php/php-src, PHP kaynak kodu dalları.
- Kaynak: PHP-7.4-CVE-2026-109618-109619
S8 — PHP 8.0 resmi acil durum destek şubesi
- Kaynak: Resmi güvenlik bülteninde listelenen php/php-src, PHP kaynak kodu dalları.
- Kaynak: PHP-8.0-CVE-2026-109618-109619
S9 — PHP 8.1 resmi acil durum destek şubesi
- Kaynak: Resmi güvenlik bülteninde listelenen php/php-src, PHP kaynak kodu dalları.
- Kaynak: PHP-8.1-CVE-2026-109618-109619
S10 — Ubuntu Güvenlik Bülteni USN-8948-1
- Kaynak: Canonical / Ubuntu, 21 Ekim 2026.
- Amaç: Destek raporunu yayınlayın ve paket sürümü örneklerini tamamlayın.
- Kaynak: USN-8948-1: PHP vulnerabilities
S11 — PHP-FPM Configuration Kılavuzu
- Kaynak: PHP resmi belge.
- Amaç:
php_admin_value,php_admin_flag,pm.max_requestsvb. gibi yapılandırma anlambilimi. - Kaynak: PHP-FPM Configuration
S12 — PHP Core INI Yapılandırma Kılavuzu
- Kaynak: PHP resmi belge.
- Amaç: İstek gövdesinin, yüklemenin, belleğin ve otomatik POST okuma yapılandırmasının tanımı ve kapsamı.
- Kaynak: Description of core php.ini directives
S13 — Nginx gövde boyutu sınırını talep ediyor
- Kaynak: Nginx resmi belge.
- Amaç:
client_max_body_size’nin anlamı ve mevcut yapılandırma düzeyleri. - Kaynak: ngx_http_core_module / client_max_body_size
S14 — Nginx FastCGI istek arabelleği
- Kaynak: Nginx resmi belge.
- Amaç:
fastcgi_request_buffering’nin işlem sırası ve işlevi. - Kaynak: ngx_http_fastcgi_module / fastcgi_request_buffering
S15 — Nginx Durum ve iade talimatları
- Kaynak: Nginx resmi belge.
- Amaç:
ifvereturn’nin yapılandırma söz dizimi. - Kaynak: ngx_http_rewrite_module
S16 — Cloudflare PHP2Shell Koruma Talimatları
- Kaynak: Cloudflare resmi blogu.
- Amaç: WAF dağıtım kapsamının, Free plan düzenlemesinin ve algılama mekanizmasının açıklaması.
- Kaynak: Cloudflare deploys protections against php2shell vulnerability