PHP2Shell Nedir? Kritik PHP Açıkları (CVE-2026-109618 / 109619) ve Partnerfy'ın Aldığı Önlemler

Kısa cevap: PHP2Shell, PHP'nin çekirdeğinde bulunan ve 21 Ekim 2026'da yamalanan iki kritik güvenlik açığına verilen ad: CVE-2026-109618 ve CVE-2026-109619. İkisi de CVSS v4.0 ölçeğinde 9.2 (kritik) puan aldı. En kötü senaryoda saldırgan hiçbir hesaba ihtiyaç duymadan, özel hazırlanmış HTTP istekleriyle web sunucusunda kod çalıştırabiliyor (RCE). Sorun sizin uygulamanızda değil, PHP'nin kendisinde. Yani kodu tertemiz bir WordPress, Laravel ya da basit bir "Merhaba Dünya" sitesi bile açıklı bir PHP sürümünde çalışıyorsa risk altında. Tek tam çözüm, PHP'yi 8.5.12, 8.4.27, 8.3.36 veya 8.2.35 sürümüne (ya da dağıtımınızın yamalı paketine) güncelleyip tüm PHP işçilerini yeniden başlatmak. Partnerfy olarak resmî yamayı beklemedik: yama yayımlanmadan yaklaşık üç saat önce sunucularımızda geçici önlemi devreye aldık, hesapların tam yedeğini aldık ve savunmayı katman katman sıkılaştırdık. Bu yazıda açığın nasıl ortaya çıktığını, teknik olarak ne olduğunu, sizin ne yapmanız gerektiğini ve bizim tarafta neler yaptığımızı anlatıyoruz.

Bu yazı; web sitesi, e-ticaret altyapısı ya da özel yazılımı PHP üzerinde çalışan işletme sahipleri ve teknik ekipler için hazırlandı. Teknik ayrıntılar PHP projesinin resmî güvenlik duyurusuna, PHP'nin GitHub güvenlik bültenlerine (GHSA) ve açığı bulan araştırmacıların yayınlarına dayanıyor. Kaynakların birbiriyle çeliştiği yerleri açıkça belirttik. Durum hızla gelişiyor; bu yazı 21 Ekim 2026 akşamı itibarıyla günceldir.

PHP2Shell nedir, neden bu kadar ciddi?

PHP, web'in en yaygın sunucu tarafı dillerinden biri. WordPress, WooCommerce, Drupal, Joomla, Magento ve Laravel'in hepsi PHP üzerinde çalışıyor. PHP2Shell'i ciddi yapan üç özellik var:

• Kimlik doğrulama gerektirmiyor. Saldırganın sitenize üye olması, şifre bilmesi ya da bir form doldurması gerekmiyor. Özel hazırlanmış istekler yeterli.
• Uygulama kodu çalışmadan önce tetiklenebiliyor. PHP projesine göre risk en yüksek Apache mod_php kurulumlarında. Burada kimliği doğrulanmamış bir isteğin, herhangi bir uygulama kodu çalışmadan önce saldırıyı tetiklediği gösterildi. Eklentilerinizi güncellemek, kodunuzu temiz tutmak ya da uygulama içi güvenlik kontrolleri bu yolu kapatmıyor.
• Etki alanı çok geniş. PHP projesine göre risk altında olan, "web isteği sunan tüm PHP kurulumları": PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed. Açığı bulan ekiplerden Wiz'e göre son on yılda çıkan her PHP sürümü, 5.4'e kadar geriye, iki açıktan en az birinden etkileniyor. Bu kapsam iddiası Wiz'e ait; PHP'nin resmî bülteni yalnızca desteklenen 8.2–8.5 dallarını listeliyor.

Değerlendirmeler de sert. Wiz bulguların "PHP'de keşfedilmiş en ağır açıklar arasında" olduğunu yazıyor. Basına yansıyan açıklamalara göre Birleşik Krallık Ulusal Siber Güvenlik Merkezi (NCSC), hemen yamalanamayan sistemlerin çevrim dışı alınmasını önerdi. CERT-EU da internete açık uygulamaların yama gelene kadar izole edilmesini tavsiye etti. Güvenlik araştırmacısı Kevin Beaumont'un yorumu durumu iyi özetliyor: "PHP meselesi bir olay yığınına yol açacak."

Açık nasıl ortaya çıktı? Zaman çizelgesi

PHP2Shell'in hikâyesi 2024'te başlıyor ve 2026'nın en hareketli siber güvenlik haftalarından birine dönüşüyor. Saatler Türkiye saatiyle (TSİ) verilmiştir.

Yazının yayımlandığı saat itibarıyla kamuya açık kaynaklarda belirli bir sunucunun bu açıkla başarıyla ele geçirildiği doğrulanmış değil. Ancak denemeler başladı ve araştırmacılar uzun bir kuyruk bekliyor. Olay müdahale uzmanı Hal Pomeranz'ın ifadesiyle: "Bunun kuyruğu uzun olacak."

Yapay zekâ faktörü: Yama ile istismar arasındaki süre artık saatlerle ölçülüyor

PHP2Shell'i 2026'ya özgü kılan bir ayrıntı daha var: açığın keşfinde ve istismar yolunun bulunmasında yapay zekâ modelleri rol oynadı. OpenAI'ın Codex Security ekibi bulgulardan birini bağımsız olarak raporladı. Wiz ise "öncü yapay zekâ modellerinin bu engeli ciddi biçimde düşürdüğünü, uzun süredir var olan bir kusuru çalışan bir istismara dönüştürdüğünü" yazıyor. 2024'te teoride kalan bir hata, 2026'da makinelerin yardımıyla silaha dönüştü. Savunma tarafı için mesaj net: yama yayımlandığı anda saat işlemeye başlıyor ve "hafta sonu bakarız" lüksü artık yok.

Teknik olarak ne oluyor? İki açık, iki farklı kök neden

Her iki açık da birer bellek güvenliği hatası. İkisi de PHP'nin bir isteği işlerken karşılaştığı ölümcül hataları (özellikle bellek yetersizliği hatalarını) nasıl ele aldığıyla ilgili. Ama mekanizmaları farklı.

CVE-2026-109618: Bellek tükendiği anda "yarım kalan" veri

PHP, bir istek sırasında bellek limiti aşıldığında (out-of-memory, OOM) longjmp() adlı bir mekanizmayla bulunduğu bağlamdan aniden çıkar ve isteği iptal eder. Resmî bülten sorunu şöyle tarif ediyor: bazı anlarda istek belleği, tamamen hazırlanmadan önce erişilebilir hâle geliyor. Tam o anda bir bellek ayırma işlemi başarısız olursa PHP bu erken çıkışı doğru hesaba katmıyor ve bellek geçersiz bir durumda kalıyor. Ardından isteği kapatma rutini bu yarım veriyi okuyup ona göre işlem yapıyor. Sonuç bellek bozulması; doğru kurgulandığında da kod çalıştırma.

Bir benzetmeyle: mutfakta bir sipariş fişi yazılırken garson aniden başka yere çağrılıyor ve fiş yarım kalıyor. Kapanışta gelen ekip fişi tamamlanmış sanıp üzerindekileri uyguluyor. Saldırgan bu yarım fişi kendi istediği gibi doldurabiliyorsa, mutfağı yönetmeye başlıyor.

Saldırgan bu anı nasıl yakalıyor? Bültende listelenen yöntemler, dosya yüklemelerinde kullanılan multipart/form-data biçimine dayanıyor:

• Kullanılabilir bir içerik uzunluğu bildirmeyen multipart istekler ilk post_max_size kontrolünü geçebiliyor.
• Bir multipart parçası sınırsız sayıda başlık içerebiliyor.
• Boş dosya alanları max_file_uploads sınırına sayılmıyor ama yine de dosya meta veri dizileri oluşturuyor.
• İç içe alan adları, oluşturulan dizi işini katlıyor.

Kısacası saldırgan, PHP'yi tam yanlış anda belleğin sonuna dayatacak bir istek hazırlıyor. Wiz'in vurguladığı gibi PHP multipart istekleri istek başlangıcında, normal modül başlatma tamamlanmadan önce ayrıştırıyor. Apache mod_php ise istek başlangıcı başarısız olsa bile kapatma rutinini koşulsuz çalıştırıyor. Bu yüzden zincirin tamamı, uygulamanıza ait tek satır kod çalışmadan tamamlanabiliyor. Tam RCE, varsayılan PHP girdi ve bellek limitleriyle, birden fazla işçili olağan prefork yapılandırmasındaki mod_php'ye karşı HTTP üzerinden doğrulandı. PHP-FPM'de istek başlangıcı başarısız olduğunda işçi süreç sonlandırıldığı için durum farklı: kaynak kod analizi FPM'in de etkilenebilir olduğunu gösteriyor, ancak bu açık için FPM'e karşı tam bir istismar henüz gösterilmedi.

CVE-2026-109619: Önceki isteğin "hayaleti"

PHP işçi süreçleri (worker) tek bir isteği işleyip kapanmaz; aynı süreç arka arkaya pek çok isteğe hizmet eder. PHP'nin hata, oturum (session), nesne ve eklenti durumları gibi global durumları vardır. Bülten, bu durumların bir kısmının işçi tarafından saklandığını ama aslında tek bir isteğe ait belleği gösterdiğini anlatıyor. Bir istek beklenmedik bir anda biterse bu işaretçiler geride kalıyor. Aynı işçiye gelen sonraki istek, normal başlatma onları sıfırlamadan önce bu bayat duruma dokunuyor. Bu, klasik bir use-after-free (serbest bırakılmış belleği kullanma) hatası. Stratejik olarak hazırlanmış bir bellek (heap) yerleşimiyle tam uzaktan kod çalıştırmaya varabiliyor.

Benzetmesi: otelde bir önceki misafirin kart anahtarı hâlâ çalışıyor ve oda temizlenmeden yeni misafir içeri giriyor. İçeride önceki misafirin eşyaları duruyor.

Bu açığın bir de veri sızıntısı boyutu var. Wiz'e göre bellek ifşası, başka isteklere ya da sunucunun kendisine ait şifreleri, kimlik doğrulama jetonlarını, API anahtarlarını ve sertifikaları içerebilir. Doğrulanmış yollardan biri oturum yükleme ilerlemesi (session upload progress) özelliği. Bu özellik varsayılan olarak açık ve uygulamanın session_start() çağırmasına bile gerek yok; oturum işleme, olağan oturum başlatmadan önce devreye girebiliyor. Bülten, PHP 8.5'teki ölümcül hata geri izleme (fatal error backtrace) yolunu da doğrulanmış ikinci yol olarak listeliyor. Oturum yaşam döngüsü üzerinden RCE hem mod_php hem PHP-FPM üzerinde doğrulandı.

Önemli bir not: PHP'nin resmî tanımına göre CVE-2026-109618 bellek yetersizliği anındaki yarım veriyle, CVE-2026-109619 ise istekler arasında kalan bayat durumla ilgili. Bazı kaynaklar (Wiz dahil) saldırı yöntemlerini CVE numaralarıyla farklı eşleştiriyor. Biz burada PHP'nin GitHub güvenlik bültenlerini esas aldık.

Kimler etkileniyor? Sürüm tablosu

Hangi uygulamayı kullandığınız fark etmiyor. Wiz, gösterimlerini resmî WordPress, Drupal ve Joomla imajları üzerinde yaptı. Bunun nedeni bu yazılımların açıklı olması değil, hepsinin PHP üzerinde çalışması. WordPress çekirdeğini ya da eklentilerinizi güncellemek bu açığı kapatmaz; güncellenmesi gereken, sunucudaki PHP'nin kendisi.

Ölçek hakkında fikir vermesi için: Mallory'nin Shodan verisine dayanan analizine göre 20 Ekim itibarıyla internette, HTTP başlığında PHP 8.1 veya daha eskisini bildiren yaklaşık 884 bin sunucu vardı. Bu sürümler resmî yama alamıyor. Bu bir başlık sayımı, doğrulanmış etkilenen sistem sayısı değil; ama uzun kuyruğun ne kadar uzun olacağını gösteriyor.

Partnerfy ne yaptı? Yamayı beklemeyen 6 katmanlı savunma

Açığın varlığı sızdığında elimizde net bir tablo vardı: resmî yama saatler uzaktaydı, saldırganlar ise çoktan hazırlanıyordu. Üstelik dünya genelinde herkes aynı anda güncelleme çekmeye çalıştığı için paket depolarında ciddi yoğunluk ve kilitlenmeler yaşanıyordu. Bu yüzden "yamayı bekleyelim" demedik; savunmayı katman katman kurduk.

1. Erken müdahale: Resmî yamadan saatler önce geçici önlem

DevOps ekibimiz sızıntı haberini ve ilk teknik değerlendirmeleri yakından takip etti ve resmî yama yayımlanmadan yaklaşık üç saat önce sunucu genelinde session.upload_progress.enabled ayarını kapattı. Bu, PHP'nin CVE-2026-109619 için önerdiği geçici önlemin ta kendisi. Ayrıca ayarı doğru yerde yaptık. PHP ekibi bu ayarın ini_set() ya da .user.ini ile değil, ana yapılandırma (php.ini / sunucu yapılandırması) düzeyinde yapılmasını istiyor. Bizim değişikliğimiz tam olarak bu düzeyde ve canlı yapılandırmada doğrulandı.

2. Kenar katmanı: Saldırıyı sunucuya ulaşmadan süzmek

Kurumsal sitemiz partnerfy.co ve Cloudflare arkasında yayın yapan projelerimiz, Cloudflare'in kenar ağıyla korunuyor. Cloudflare, bilinen PHP2Shell vektörlerine karşı ilk WAF kural setini 21 Ekim sabahı varsayılan olarak devreye aldı. Böylece şüpheli isteklerin önemli bir kısmı daha bizim sunucularımıza gelmeden süzülüyor. Saldırganların ilk kuralları aşmak için yüklerini değiştirdiği raporlandığından bu katmanı tek başına yeterli saymıyoruz; arkasında diğer katmanlar devrede.

3. Sertleştirilmiş PHP yapılandırması: Saldırganın bir sonraki adımını kesmek

Sunucularımızdaki PHP yapılandırması bu krizden çok önce sertleştirilmişti. Sistem komutu çalıştırmaya yarayan fonksiyonlar (system, popen, proc_open ve benzerleri) kapalı; uzak dosya dahil etme (allow_url_include) kapalı. Açık konuşalım: bellek düzeyinde bir RCE bu kısıtları teorik olarak aşabilir. Ama gerçek dünyada saldırganın ilk işi genellikle bir komut kabuğu açmak, araç indirmek ya da web shell bırakmaktır. Bu kısıtlar, istismar sonrasındaki o kritik adımları çok daha zor ve çok daha gürültülü hâle getiriyor. Gürültü de yakalanmak demek.

4. Hesap izolasyonu: Bir kapı açılsa bile koridor kapalı

Sunucularımızdaki her hesap, kendi izole dosya sistemi "kafesinde" çalışıyor. Bir hesapta en kötü senaryo yaşansa bile saldırganın diğer hesapların dosyalarına ve süreçlerine yatay geçiş yapması ciddi biçimde kısıtlanıyor. Zincirdeki bir halkanın kopması, bütün zincirin kopması anlamına gelmiyor.

5. Felaket senaryosu yedekleri: En kötüsüne hazır olmak

Yama penceresi öncesinde sunucularımızdaki hesapların tam yedeklerini aldık. Amaç basit: bir şey ters giderse "ne kaybettik" diye değil, "hangi temiz noktaya döneceğiz" diye sormak. İyi bir güvenlik stratejisi yalnızca saldırıyı engellemeyi değil, saldırı başarılı olsa bile hızla temiz bir duruma dönebilmeyi de kapsar.

6. Yama, yeniden başlatma ve iz takibi

Resmî yamalı paketler dağıtım kanallarına düştükçe sunucularımıza uyguluyor ve ardından tüm PHP işçilerini yeniden başlatıyoruz. Yeniden başlatma şart: çalışmaya devam eden eski işçiler eski kodu kullanmayı sürdürür. Yama yeni bir sert bellek sınırı getirdiği için bellek ayarlarımızı da bu çerçevede yeniden gözden geçiriyoruz.

Aynı zamanda erişim kayıtlarımızı araştırmacıların tarif ettiği işaretlere göre taradık. Somut bir örnek: yamanın yayımlanmasından yaklaşık üç saat sonra tek bir bulut IP adresinden, kendini art arda farklı arama motoru ve yapay zekâ botları gibi gösteren (CCBot, Amazonbot, ClaudeBot ve benzerleri) bir dizi POST isteği sitemizin kök dizinine ve /api, /app gibi yollara geldi. Bu isteklerin tamamı, uygulamamıza ulaşmadan sunucu tarafındaki güvenlik katmanında 403 ile reddedildi. Bunların PHP2Shell denemesi olduğunu kesin olarak söyleyemeyiz; ama zamanlama ve sahte kimlik deseni, yama sonrasında başlayan toplu taramalarla tutarlı. Bu yazının yayımlandığı saat itibarıyla sistemlerimizde herhangi bir ihlal belirtisi tespit etmedik.

Partnerfy'ın yaklaşımı: Güvenliği tek bir kilide emanet etmiyoruz. Kenarda filtre, sunucuda sertleştirme, hesaplarda izolasyon, arkada yedek, önde hızlı müdahale. Biri aşılırsa diğeri devrede.

Siz ne yapmalısınız? Adım adım kontrol listesi

1. PHP sürümünüzü öğrenin

cPanel kullanıyorsanız "MultiPHP Manager" ya da "PHP Sürümü Seç" ekranından, sunucuya erişiminiz varsa php -v ile kontrol edebilirsiniz. Dikkat: komut satırındaki PHP sürümü, web sitenizi çalıştıran sürümden farklı olabilir. En kesin yöntem, sitenizin kullandığı PHP'yi barındırma firmanıza sormak ya da geçici bir phpinfo() sayfasıyla görüp hemen silmektir. Paylaşımlı hosting kullanıyorsanız güncelleme sizin değil, hosting firmanızın işidir. Bugün onlara "PHP2Shell yamasını uyguladınız mı?" diye sorun.

2. Güncelleyin ve yeniden başlatın

Hedef sürümler: 8.5.12, 8.4.27, 8.3.36 veya 8.2.35. Linux dağıtımlarının paketlerinde sürüm numarası farklı görünebilir. Debian'ın da önerdiği gibi, sürüm numarasına değil paket değişiklik kaydında (changelog) CVE numarasına bakın. Güncellemeden sonra Apache'yi, PHP-FPM'i ve uzun süre çalışan tüm PHP işçilerini yeniden başlatın.

3. Hemen güncelleyemiyorsanız: Geçici önlemler

PHP projesinin uyarısını baştan yazalım: bu önlemler "belirli saldırı yollarına maruziyeti azaltır ama kurulumu güvenli hâle getirmez." Tek tam çözüm güncellemedir.

4. Eski PHP sürümündeyseniz: Yükseltmeyi erteleyemezsiniz

PHP 8.1 ve öncesi PHP projesinden artık güncelleme almıyor. Bu sürümlerde çalışan bir site için gerçek çözüm yama değil, yükseltmedir. Unutmayın: PHP 8.2'nin desteği de 31 Aralık 2026'da bitiyor. Bugün 8.2.35'e geçmeniz sizi kurtarır; ama 2027'ye 8.2 ile girerseniz bir sonraki krizde yama alamayacaksınız. Eski kod tabanınız yeni PHP sürümlerinde çalışmıyorsa, bu bir yazılım modernizasyonu projesinin zamanının geldiğini gösterir.

5. İz kontrolü yapın

Araştırmacıların yama sonrası için önerdiği işaretler:

• Olağandışı multipart istekler ve hemen ardından bellek limiti hataları ya da art arda gelen HTTP 500 yanıtları
• Beklenmedik büyüklükte ya da bozuk PHPSESSID çerezleri
• Açıklanamayan PHP işçi yeniden başlamaları ya da çökmeleri
• php-fpm, httpd ya da apache2 süreçlerinin kabuk, yorumlayıcı ya da indirme aracı (sh, bash, curl, wget gibi) başlatması
• Web kök dizininde yeni dosyalar (web shell), yeni cron işleri, yeni kullanıcı hesapları

Saldırı uygulama katmanının altında gerçekleştiği için uygulama kayıtlarınızda çok az iz kalabilir. Web sunucusu ve PHP kayıtlarına bakın. Şüpheli bir durum varsa sunucuyu izole edin, kayıtları koruyun, sonra inceleyin. CVE-2026-109619 bellek ifşasına da yol açabildiği için şüphe durumunda veritabanı şifrelerini, API anahtarlarını ve oturum gizli anahtarlarını yenilemeniz de mantıklı olur.

Bu krizden çıkan ders: Güvenlik bir ürün değil, bir refleks

PHP2Shell üç şeyi açıkça gösterdi. Birincisi, uygulamanız ne kadar temiz olursa olsun altında çalıştığı platform kadar güvenlisiniz. İkincisi, yapay zekâ çağında yama ile istismar arasındaki süre saatlere indi. Üçüncüsü, sızıntılar ve ambargo ihlalleri yaşandığında "resmî takvime göre hareket ederiz" yaklaşımı çöküyor. Kazananlar, haberi ilk saatte okuyup geçici önlemi alan, yedeğini hazır tutan ve savunmasını tek bir kilide emanet etmeyen ekipler oluyor.

Partnerfy olarak yönetilen hosting ve sunucu yönetimi, siber güvenlik ve yedekleme ve felaket kurtarma hizmetlerimizde bu refleksi standart olarak sunuyoruz. Sakarya merkezli, Türkiye, Almanya, Rusya ve İrlanda'da ofisleri bulunan bir yazılım şirketi olarak; sitenizin hangi PHP sürümünde çalıştığını, PHP2Shell'e karşı açık olup olmadığını ve 8.2'nin destek sonuna nasıl hazırlanacağınızı birlikte netleştirebiliriz. Bizimle iletişime geçin; sitenizi birlikte kontrol edelim.

Kaynaklar

• PHP: 21 Ekim 2026 güvenlik duyurusu
• GHSA-w8hw-w9fx-j79w: CVE-2026-109618 (RCE via OOM corruption)
• GHSA-6wmf-4rv5-p3rp: CVE-2026-109619 (RCE via stale global state)
• The PHP Foundation: Bugünkü güvenlik sürümü ve PHP güvenliğini güçlendirme planı
• Wiz: PHP2Shell araştırması
• Help Net Security: PHP2Shell yamaları yayımlandı
• The Hacker News: PHP'den iki kritik açık için acil yama

Sıkça Sorulan Sorular (S.S.S.)