PHP Güvenlik Güncellemesi 2026: PHP2Shell CVSS 9.2 Rehberi

Sürecin kendisi de alışılmadık şekilde ilerledi. PHP güvenlik ekibi 20 Ekim'de önceden bir uyarı yayımladı, sürümü 21 Ekim saat 14:00 UTC için planladı ve gerekirse öne çekme hakkını saklı tuttu. CVE numaraları planlı ifşadan bir gün önce sızdı; beraberinde şiddet ve etkilenen sürüm iddiaları şişirilmiş halde dolaştı. İşletim sistemi dağıtımları yamaları çoktan almıştı, ulusal CERT'ler kod yayımlanmadan rehber paylaşmaya başlamıştı. Yani sürüm çıktığında gecikmeyi açıklayacak meşru bir gerekçe kalmamıştı.

Tek Acil Sürümde İki Açık

Bunlardan hiçbiri uygulamada yapılan bir mantık hatası değil. İkisi de PHP'nin isteği nasıl hazırlayıp nasıl kapattığıyla ilgili; bu yüzden hiçbir framework güncellemesi, eklenti güncellemesi ya da WAF kuralı interpreter güncellemesinin yerini tutmuyor.

CVE-2026-109618 — bellek taşması (OOM) kaynaklı durum bozulmasıyla RCE. PHP bellek sınırına dayandığında isteğe devam etmek yerine onu sonlandırıyor. Duyuruda anlatılan senaryoda bu sonlandırma, PHP dahili istek verileri kısmen başlatılmışken devreye giriyor; istek temizleme adımı da geçersiz veriyi geçerli sayıyor. Bellek kullanımını sınıra zorlayabilen bir saldırgan bundan sonrasını yönlendirebiliyor. Bu açık, önerilen önlemi bu kadar tuhaf kılıyor: yöneticilere kendi bellek sınırını sıkılaştırmaları değil, PHP'yi o sınıra hiç vurdurmamaları söyleniyor.

CVE-2026-109619 — bayat global durumla RCE. Bir isteğe ait dahili durum, arkasındaki bellek serbest bırakıldıktan sonra var olmayı sürdürebiliyor. Aynı worker sürecinin işlediği bir sonraki istek, normal başlatma sıfırlamadan önce o bayat durumu kullanabiliyor. Uzun ömürlü worker'larda — yani tam olarak PHP-FPM, mod_php ve LiteSpeed'in çalışma şeklinde — bellek yeniden kullanımı sıradan ve kalıcı bir durum. Bu yüzden egzotik kurulumlara özgü bir kenar vakası değil.

PHP2Shell adı PHP projesinin resmî bir etiketi değil; araştırmacıların ve güvenlik satıcılarının kullandığı isim yerleşti. Bu yüzden tarayıcı çıktılarında, hosting duyurularında ve CERT bültenlerinde tam olarak bu iki CVE'yi anlatan metinlerde göreceksiniz.

Gerçekte Kim Risk Altında

Duyuru net: web isteği karşılayan tüm PHP kurulumları risk altında. nginx veya Apache arkasında PHP-FPM, mod_php ile Apache, php-cgi, LiteSpeed ve FrankenPHP'nin hepsi kapsamda. Aralarındaki fark, saldırganın ne kadar iş yapmak zorunda olduğu.

Ticaret işletmeniz için WordPress, WooCommerce, Laravel, Magento, Magento tarafı bir ERP ya da herhangi bir PHP sipariş portalı barındırıyorsanız, uygulama kodu kusursuz olsa bile ilk üç satırdasınız. Bu işi kimin sahiplenmesi gerektiği konusunda Türkiye'de IT outsourcing rehberimize bakabilirsiniz.

İki Dakikada Sürümünüzü Kontrol Edin

Tuzak sürüm aritmetiğinde. Dağıtımlar PHP 8.3.6 veya 8.2.x sürümünü yıllarca taşır ve güvenlik düzeltmelerini aynı görünen sürüm numarasının içine işler; yani php -v tek başına korumalı olup olmadığınızı söylemez. Üç şeye birlikte bakın.

1. Görünen PHP sürümü ve trafiğe bakan SAPI.

2. Upstream değil, dağıtım paket sürümü. Debian ve Ubuntu'da dürüst cevap changelog'dadır; RPM tabanlı sistemlerde paketin changelog'una sorun.

Changelog, kurulu sürüm için bu iki CVE'yi listeliyorsa php -v hâlâ 8.3.6 dese bile yamalı durumdasınız. Gerçek bir güvenlik cevabı ile sürüm numarası batıl inancı arasındaki fark budur.

3. Çalışan süreç yamalanmış binary'yi gerçekten yükledi mi? Paket güncellemesinden sonra restart yapılmazsa eski bellekteki kod çalışmaya devam eder. Servis başlama zamanı ile paket kurulum zamanını karşılaştırın:

cPanel, Plesk, DirectAdmin veya managed platformlarda bunun karşılığı PHP seçicisi ve sağlayıcının kendi güvenlik bültenidir: panelde reklamı yapılan en yeni sürümü değil, hesabınızın gerçekten atandığı çalışan sürümü öğrenin. Hostunuz bir yama tarihi veremiyorsa sitenizi yamasız sayın. Dijital altyapı hizmetlerimiz bu denetimi ve bizzat güncellemeyi kapsıyor; ayrıca kullandığınız yığını yazmanız yeterli, neyi kontrol edeceğimizi bize ulaşarak ücretsiz öğrenebilirsiniz.

DüzeltiLEN Sürümler ve EOL Uçurumu

PHP bir branşı iki yıl aktif geliştirme, ardından iki yıl yalnızca güvenlik düzeltmesiyle destekler. 21 Ekim'de dört eşzamanlı düzeltmenin çıkmasının sebebi bu politika — eski branşları yapayalnız bırakan da yine bu politika.

Duyurudan iki pratik uyarı. Birincisi, PHP'yi dağıtımınız yerine topluluk deposundan kuruyorsanız o depo güvenlik penceresinin gerisinde kalabilir: yaygın kullanılan Remi paketlerinin geliştiricileri aynı gün güncelleme yayımlamayacaklarını belirttiler; güvenli yol dağıtım paketları ya da kaynaktan derleme. İkincisi, PHP 8.1 veya daha eskiye takılıysanız "hostumuzu bekliyoruz" demek, müşterileriniz adına verdiğiniz bir güvenlik kararıdır — ya belgeleyin ya da değiştirin.

Üretim Sunucusunu Olay Çıkarmadan Yamalamak

Aynı minor sürümdeki güvenlik güncellemeleri uygulamayı nadiren kırar; kıran şey teste alınmamış restart'lardır. Aşağıdaki sıra, canlı ticaret platformlarında kullandığımız sıradır: risk penceresini kısaltır, siteni kumara atmaz.

1. Önce snapshot. Test edip gerçekten geri dönebildiğiniz bir hypervisor veya disk anlık görüntüsü, yama kararını ucuzlatır.
2. Sürümü staging'de birebir tekrarlayın. Aynı branş, aynı eklentiler, aynı PHP yapılandırma dosyaları, üretim verisinin bir kopyası. Sadece anasayfayı değil; sepet, teklif formu ve ödeme akışını çalıştırın.
3. Paket setini tek parça halinde güncelleyin. Güncellenmiş bir CLI ile eski bir FPM binary'sini yan yana bırakmak, yamalı bir php -v ile yamasız bir web yoluna sahip olmanın klasik yoludur: apt-get update && apt-get install --only-upgrade 'php8.3-*', RPM tabanlı sistemlerde dnf update --security 'php*'.
4. İstek karşılayan süreci restart edin, sonra restart edildiğini doğrulayın. systemctl restart php8.3-fpm (veya Apache reload / LiteSpeed restart), ardından servis başlama zamanını yeniden kontrol edin ve sürüm–changelog sorgularını tekrar çalıştırın.
5. Bir saat hata günlüğünü izleyin. OOM mesajları, yeni fatal-error imzaları ve anormal 5xx oranı, aşağıdaki önlem ayarlarının elden geçirilmesi gerektiğinin işaretidir — ertelemek gerekçesi değil.
6. Kanıtı arşivleyin. Paket sürümü, iki CVE'yi anan changelog satırı, restart zaman damgası. Müşteriler, denetçiler ve ISO 27001 benzeri kontrol incelemeleri tam olarak bunu ister; kaydetmesi on saniye sürer.

Güncellemenin beklemesi gereken yerler — doğrulanmış bir ERP entegrasyonu, yasaklı bir yayın takvimi, müşteri onay döngüsü — için aynı gün telafi edici bir kontrol ekleyin; portu açık bırakıp umut etmek yerine. Ulusal CERT bültenlerinin bu tür durumlar için önerisi tam olarak buydu: derhal yamanamıyorsanız, internete bakan PHP uygulamalarını genel ağdan izole edin.

Ara Önlemler: Pencereyi Daraltır, Kapatmaz

PHP duyurusu açıkça söylüyor: eksiksiz bir önlem yok, güvenli tek tercih güncelleme. Aşağıdakileri hafta değil gün bazında örtü olarak düşünün; uygulamanın ezemeyeceği bir katmanda uygulayın ve ardından tüm worker'ları restart edin.

CVE-2026-109618 (bellek taşması yolu) için

• PHP kendi bellek tavanına çarpmak yerine makinenin belleğini tüketebilsin: memory_limit = -1, mümkünse uygulama kodu geri koyamasın diye php_admin_value memory_limit = -1 olarak.
• İstek gövdesini interpreter seviyesinde küçük tutun: duyurunun rehberi yükleme yoksa ~8 MB, varsa ~32 MB civarı; upload_max_filesize değeri post_max_size altında kalmalı.
• Maliyetli limitleri proxy'de zorunlu kılın, çünkü zarar ağ boyutunda değil çözülmüş istekte: toplam çözülmüş gövde boyutu, alan sayısı, multipart bölüm sayısı, başlık sayısı, iç içe derinlik — ve kullanılabilir bir Content-Length taşımayan istekleri de kapsayın.
• Etki alanını bir konteyner ya da cgroup bellek limitiyle sınırlayın ki öldürülen worker makine olayı değil erişilebilirlik olayı olsun. RLIMIT_AS veya RLIMIT_DATA ile ikame etmeyin: bu sınırlar tam da savunmasız kod yolunda tetiklenen tahsis hatasını üretir.

CVE-2026-109619 (bayat durum yolu) için

• Oturum yükleme ilerlemesini session.upload_progress.enabled = 0 ile kapatın; php.ini, FPM havuzu veya sunucu yapılandırmasında, yani istek ayrıştırmasından önce geçerli olacak bir yerde. Sonra her worker'ı restart edin, çünkü FPM başlatılmış modül durumunu istekler arasında paylaşır. ini_set() ve .user.ini iş için çok geç kalır.
• PHP 8.5'te fatal_error_backtraces = 0 yapın ve restart edin.
• Geçersiz ya da kullanımdan kaldırılmış olduğu için erken başlatma sırasında tanılama üreten istek bazlı ayarları kaldırın. Mesajı error_reporting, display_errors veya @ ile bastırmak kod yolunu ortadan kaldırmaz.
• Saldırganın erişebildiği fatal hataları ve uzun zaman aşımını avlayın: yükleme ve içe aktarma işleyicileri, callback kodları, temizleme rutinleri — yani iki açığın yaşadığı yerler.

Önündeki bir CDN veya WAF yine de işe yarar: hız sınırlama, anormal istek şekillerinin engellenmesi ve sanal yama gürültüyü azaltır, fırsatçı taramayı yavaşlatır. Hedefli bir saldırgan için hız tümseğidir; giderim olarak imzalayacağınız bir kontrol değildir.

Hosting Firmanıza Bugün Soracaklarınız

Destek scriptleri bu soruyu "biz her zaman yamalıyız" diye yanıtlar. Siz dosyaya koyabileceğiniz kanıt isteyin:

• Hesabımıza atanmış çalışan PHP sürümü nedir; dağıtım paketi mi, satıcı derlemesi mi?
• CVE-2026-109618 ve CVE-2026-109619 düzeltmeleri filonuzun tamamına hangi tarihte ulaştı; iç paket sürüm dizesi nedir?
• Düzeltme sitemize hizmet veren SAPI'nin (FPM, LiteSpeed, mod_php) tamamını mı kapsıyor; geri dönebileceğimiz staging ve yedek düğümler dahil mi?
• Platform henüz yamalı değilse: hangi telafi edici kontrol var ve ne zamana kadar?
• EOL branşlardaki politikanız nedir — PHP 8.2 güvenlik desteği durduğunda 1 Ocak 2027'de siteme ne olacak?

Bu beş soruyu tek e-postada yanıtlayan sağlayıcıyı tutun. Pazarlama metniyle geri dönen, taşıma görüşmesinin konusudur; aynı özen ISO 27001 gap assessment çalışmalarımızda da geçerlidir: orada teslim edilen şey güvence değil, kanıttır.

Ele Geçirildiğinizi Varsaymalı mısınız?

Otomatik olarak hayır — ama tahmin yerine kontrol edin; özellikle yamanızdan önceki pencerede sunucu herkese açıktıysa.

• Sizin oluşturmadığınız süreçler, dinleyen portlar ve cron kayıtları; PHP worker kullanıcısından çıkan ağ bağlantıları arayın.
• Yazılabilir uygulama dizinlerini referans dağıtımınızla karşılaştırın: yeni PHP dosyaları, değişmiş upload dizinleri, beklenmedik şekilde çalıştırılabilir temp klasörleri.
• Web loglarında ifşa saatlerindeki istek fırtınalarını, olağandışı büyük multipart gövdelerini veya PHP hata günlüğünde OOM imzasıyla dönen 500'leri tarayın.
• Yamalı binary'nin gerçekten çalıştığını doğrulayın — yukarıdaki restart zamanı karşılaştırması bunu yanıtlar.
• Bir şey ters görünüyorsa olay müdahalesi başlatın: diski ve logları koruyun, uygulamanın okuyabildiği her kimlik bilgisini döndürün, bilinen iyi bir imajdan yeniden kurun. Ele geçirilmiş bir hostun üstüne PHP paketi kurmak giderim sayılmaz.

Kendi Altyapımızdan Çalışan Bir Örnek

worldwidetradex.com Ubuntu 24.04 LTS üzerinde nginx ve PHP-FPM ile çalışıyor; biz de yukarıdaki kontrolleri 22 Ekim'de kendimize uyguladık. Sonuç, sürüm aritmetiğinin neden önemli olduğunu iyi anlatıyor:

Ders her yığına taşınır: güvenlik duruşunuz pazarlama sürüm numarası değil, paket sürümü artı changelog artı restart'tır.

Yamayı Kahramanlık Değil, Rutin Haline Getirmek

PHP2Shell egzotik olduğu için değil, web'in büyük kısmının üzerinde çalıştığı interpreter kritik ve kimlik doğrulama öncesi bir açık verdiği, binlerce hostun saatler içinde tepki vermesi gerektiği için akılda kaldı. Bunu sorunsuz atlatan ekipler şanslı değildi — otomasyonları vardı.

• Interpreter için otomatik güvenlik güncellemeleri; sürüm ve restart otomatik olarak kaydedilsin.
• Her sitenin hangi SAPI ve hangi PHP branşını kullandığını bilen bir envanter: staging, yedekler ve 2019'dan kalma o WordPress dahil.
• Provası yapılmış bir geri dönüş yolu; "şimdi yamala" kararı asla "geri dönemiyoruz" ile tartılmasın.
• Bir branş planı: güvenlik desteği önümüzdeki on iki ay içinde biten hiçbir PHP sürümünde kalmayın.
• Sunucu başına atanmış bir sorumlu ve yama çarşamba günü 14:00 UTC'de düştüğünde izlenecek yazılı bir tırmanma yolu.

Bu yetkinliği kadro kurarak değil satın alarak elde etmek isterseniz, PHP üretim platformlarının sahipliğini üstleniyoruz — yama temposu, izleme, yedekler ve belgelenmiş geri dönüşler — yönetilen altyapı işimizin parçası olarak. Kısa bir ihtiyaç tanımı ve miktarlarla başlayın: teklif isteyin.

Sıkça Sorulan Sorular

Kaynaklar

• PHP — "Critical remote code execution vulnerabilities, update now" güvenlik duyurusu ve 21 Ekim 2026 sürüm duyuruları; önlem rehberi ve destek zaman çizelgesi supported versions sayfasında.
• PHP deposunun GitHub güvenlik danışmanlıkları: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) ve GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).
• CERT-EU — Her iki CVE'yi adlandıran 2026-018 numaralı "Critical Vulnerabilities in PHP" güvenlik danışmanlığı.
• Infosecurity Magazine — "Planlı Güvenlik Yamalarından Önce Sızdırılan Kritik PHP Açıkları" (21 Ekim 2026) ve "PHP2Shell Sömürü Girişimi Amazon Tarafından İfşadan Dört Gün Önce Tespit Edildi" (22 Ekim 2026).

Güncellemeyi size yapacak birine mi ihtiyacınız var? Yama, sürüm denetimi, yönetilen ve yamalı bir PHP platformuna taşıma veya bu platformun altyapısı için bize ulaşın veya +90 505 679 78 03 numarasını arayın.