Ekim 2026'nın üçüncü haftasında PHP güvenlik ekibi, PHP'nin kendi çekirdeğinde bulunan iki kritik açığı duyurdu ve aynı gün yamalı sürümleri yayımladı. CVE-2026-109618 ve CVE-2026-109619 numaralarıyla kayda geçen bu açıklar, güvenlik topluluğunda birlikte PHP2Shell adıyla anılıyor. Açıklar kimlik doğrulama gerektirmeden uzaktan kod çalıştırmaya imkân veriyor, yalnızca tek bir HTTP isteğiyle tetiklenebiliyor ve duyurudan önce bile istismar girişimleri tespit edildi. PHP ile çalışan kurumsal siteler, e-ticaret mağazaları, içerik yönetim sistemleri ve özel paneller için bu, "bir ara bakarız" denebilecek bir güncelleme değil. Bu yazıda PHP2Shell'in ne olduğunu, kimleri etkilediğini, sunucunuzun durumunu nasıl kontrol edeceğinizi ve yamadan sonra atlanmaması gereken adımları anlatıyoruz.
PHP2Shell nedir?
PHP2Shell, PHP yorumlayıcısının bellek yönetimindeki iki ayrı hatanın ortak adıdır. Her ikisi de PHP güvenlik ekibi tarafından CVSS v4.0 ölçeğinde 9.2 puanla kritik olarak sınıflandırıldı.
| Açık | Kısa açıklama |
|---|---|
| CVE-2026-109618 | Bellek yetersizliği (out-of-memory) durumunda bozulma. Bir isteğin hazırlık aşaması bellek hatası nedeniyle yarıda kaldığında, PHP'nin temizlik rutini geride kalan geçersiz veriyi geçerliymiş gibi işliyor. Bu durum uzaktan kod çalıştırmaya kadar ilerleyebiliyor. |
| CVE-2026-109619 | Eskimiş genel durum (stale global state). Bir isteğe ait iç durum bilgisi, kullandığı bellek serbest bırakıldıktan sonra da yaşamaya devam ediyor. Aynı PHP işçi sürecinin işlediği bir sonraki istek bu artık veriler üzerinde işlem yapıyor; bu da hem kod çalıştırmaya hem de bellek içeriğinin sızmasına yol açabiliyor. |
Bu açıkları diğer pek çok PHP güvenlik sorunundan ayıran en önemli özellik, saldırının uygulama kodu hiç çalışmadan önce tetiklenebilmesidir. Sitenizin hangi çatıyla yazıldığı, hangi CMS'i kullandığı veya kodunun ne kadar özenli olduğu bu açık açısından fark yaratmıyor; sorun PHP'nin isteği karşıladığı ilk katmanda. Araştırmacılar ayrıca kimlik doğrulamasız olarak PHP işçi süreçlerinin belleğinden veri okunabildiğini gösterdi. Bu bellekte şifreler, oturum belirteçleri ve API anahtarları gibi hassas bilgiler bulunabilir.
PHP2Shell kimleri etkiler?
Kısa cevap: Web isteklerine yanıt veren hemen her PHP kurulumu. Açıklar PHP'nin uzun bir sürüm aralığını, 5.4'ten 8.5'e kadar olan hatları kapsıyor. Etkilenen çalışma biçimleri şunlardır:
- Apache mod_php: Araştırmacıların değerlendirmesine göre en yüksek riskli yapı budur.
- PHP-FPM: Nginx veya Apache ile birlikte en yaygın kullanılan modern kurulum biçimi.
- php-cgi
- FrankenPHP
- LiteSpeed (paylaşımlı hostinglerde sık kullanılır)
Yamalı sürümler ve eski sürüm hatlarının durumu şöyledir:
| Sürüm hattı | Durum |
|---|---|
| PHP 8.5 | 8.5.12 ile düzeltildi. |
| PHP 8.4 | 8.4.27 ile düzeltildi. |
| PHP 8.3 | 8.3.36 ile düzeltildi. |
| PHP 8.2 | 8.2.35 ile düzeltildi. |
| PHP 7.4, 8.0 ve 8.1 | Resmî destek sona erdiği için yeni sürüm yayımlanmadı; yalnızca kaynak koda uygulanabilecek asgari düzeltmeler paylaşıldı. Uzun süreli destek veren bir sağlayıcı veya desteklenen bir sürüme geçiş gerekir. |
| PHP 5.4 – 7.3 | Desteği çoktan sona ermiş sürümler; düzeltme yok. Tek gerçekçi yol yükseltmedir. |
PHP2Shell neden bu kadar acil?
Açıkların varlığı, koordineli duyuru süreci tamamlanmadan 20 Ekim 2026'da kamuoyuna sızdı. PHP ekibi bunun üzerine 21 Ekim'de resmî güvenlik bültenlerini ve yamalı sürümleri yayımladı. Amazon'un tehdit istihbaratı ekibi, bal küpü (honeypot) sistemlerinde 17 Ekim'de, yani resmî duyurudan dört gün önce bir istismar girişimi kaydettiğini açıkladı. watchTowr başta olmak üzere çeşitli güvenlik araştırma ekipleri, duyurunun ardından açığın aktif olarak istismar edildiğini raporladı ve çalışan istismar kodları kamuya açık hale geldi.
Bu tablo iki anlama geliyor. Birincisi, yama yapmayan her PHP sunucusu otomatik tarama botlarının hedefindedir; botlar sitenin büyüklüğüne bakmaz. İkincisi, istismar duyurudan önce başladığı için, yamayı hızlı uygulamış olsanız bile sunucunuzun daha önce denenmiş olma ihtimali vardır. Bu nedenle yama tek başına yeterli değildir; aşağıda anlattığımız yama sonrası kontroller de yapılmalıdır.
Sunucumdaki PHP sürümünü nasıl kontrol ederim?
Kontrol yöntemi barındırma modelinize göre değişir:
- Komut satırı: Sunucuya erişiminiz varsa php -v komutu sürümü gösterir. Ancak dikkat: komut satırındaki PHP (CLI) ile web isteklerini karşılayan PHP-FPM veya mod_php farklı sürümler olabilir. Aynı sunucuda birden fazla PHP sürümü kurulu olması oldukça yaygındır.
- Web tarafındaki gerçek sürüm: Web isteklerini karşılayan sürümü görmek için geçici bir phpinfo sayfası kullanılabilir. Bu sayfa sunucu hakkında çok fazla bilgi verdiği için kontrolden hemen sonra silinmeli, mümkünse yalnızca belirli bir IP adresine açılmalıdır.
- Hosting paneli: cPanel, Plesk ve benzeri panellerde her alan adı için kullanılan PHP sürümü ayrı ayrı görülebilir. Birden fazla siteniz varsa hepsini kontrol edin.
- Paket yöneticisi: Linux dağıtımlarında PHP'yi dağıtımın kendi paketlerinden kurduysanız, dağıtımlar düzeltmeyi kendi sürüm numaralandırmalarıyla eski sürümlere geri taşıyabilir. Bu durumda dağıtımın güvenlik bültenine bakmak gerekir; sürüm numarası tek başına yanıltıcı olabilir.
PHP2Shell için yama nasıl yapılır?
PHP güncellemeleri kendiliğinden yüklenmez. Sunucunun yönetimi sizdeyse veya projeyi geliştiren ekipteyse şu adımlar izlenmelidir:
- Kullandığınız sürüm hattının yamalı sürümünü dağıtımınızın paketlerinden veya kullandığınız resmî depodan kurun.
- PHP-FPM veya Apache'yi yeniden başlatın. Bu adım sık atlanır. Paket güncellense bile, çalışan süreçler yeniden başlatılmadan eski kod bellekte çalışmaya devam eder.
- Web tarafındaki sürümü yeniden kontrol ederek yamanın gerçekten devrede olduğunu doğrulayın.
- Konteyner kullanıyorsanız temel imajı güncelleyip imajları yeniden derleyin ve dağıtın; çalışan eski konteynerleri kapatın.
- Test, hazırlık ve unutulmuş eski kurulumları da aynı şekilde güncelleyin. Saldırganlar en çok bu sahipsiz ortamları bulur.
- Desteği bitmiş bir sürüm hattındaysanız (8.1 ve öncesi), desteklenen bir sürüme geçişi planlayın. Bu geçiş uygulama kodunda uyarlama gerektirebilir; bu süre içinde riski azaltmak için aşağıdaki geçici önlemleri uygulayın.
Paylaşımlı hosting kullanıyorsanız PHP'yi siz güncelleyemezsiniz. Barındırma firmanıza PHP2Shell için yamalı sürümlerin kurulup kurulmadığını ve PHP süreçlerinin yeniden başlatılıp başlatılmadığını yazılı olarak sorun. Panelden eski bir PHP sürümü seçiliyse, firmanın yamalı paketlerini sunduğu desteklenen bir sürüme geçin.
Yama yapamıyorsam geçici olarak ne yapabilirim?
PHP güvenlik ekibi ve araştırmacılar, yamayı hemen uygulayamayanlar için bazı yapılandırma önlemleri paylaştı. Bu önlemler riski azaltır ancak tam koruma sağlamaz; ayrıntılar ve güncel öneriler için PHP'nin resmî güvenlik bültenlerini esas alın. Cloudflare gibi sağlayıcılar, bilinen saldırı vektörlerini engelleyen web uygulama güvenlik duvarı (WAF) kuralları yayımladı. WAF, yamaya kadar zaman kazandıran değerli bir katmandır; ancak kurallar bilinen kalıplara göre yazıldığı için farklı biçimde hazırlanmış isteklerle atlatılabilir. Yama yapılana kadar kritik sistemleri internetten erişime kapatmak veya erişimi belirli IP adresleriyle sınırlamak da değerlendirilmelidir.
Yama sonrası hangi kontroller yapılmalı?
Sırları ve şifreleri yenileyin
İstismar duyurudan önce başladığı ve bellek içeriğinin sızdırılabildiği gösterildiği için, internete açık bir PHP sunucusunda tutulan sırların ele geçmiş olabileceği varsayılmalıdır. .env dosyasında veya yapılandırma dosyalarında bulunan veritabanı şifreleri, API anahtarları, ödeme sağlayıcısı anahtarları, SMTP şifreleri ve uygulama şifreleme anahtarları yenilenmeli, eski değerler iptal edilmelidir. Oturum anahtarı değişen uygulamalarda kullanıcıların yeniden giriş yapması gerekebilir; bu, kabul edilebilir bir bedeldir. Aynı yaklaşımı, kısa süre önce React tarafında yaşanan benzer bir olay için React2Shell nedir yazımızda da ayrıntılı olarak anlattık.
Web shell arayın
Uzaktan kod çalıştırma açıklarında saldırganın ilk işi genellikle sunucuya bir web shell yerleştirmektir. Web shell, tarayıcı üzerinden çağrılarak komut çalıştırmaya, dosya okumaya ve yüklemeye yarayan küçük bir betiktir. Açık kapatılsa bile dosya sunucuda kaldığı sürece saldırgan geri dönebilir. Aramada şunlara odaklanın:
- Görsel, belge, önbellek ve geçici dosya klasörlerinde bulunan .php, .phtml, .phar gibi çalıştırılabilir uzantılı dosyalar. Bu klasörlerde PHP dosyası olmamalıdır.
- Son günlerde değiştirilmiş .php dosyaları. Bu değişiklikler bilinen bir güncellemeye karşılık gelmiyorsa şüphelidir. Saldırganların dosya tarihlerini değiştirebildiğini de unutmayın.
- base64_decode, gzinflate veya str_rot13 gibi fonksiyonların eval ile iç içe kullanıldığı, uzun ve anlamsız karakter dizileri içeren gizlenmiş kodlar.
- Sürüm kontrol sistemindeki temiz kodla veya CMS'in resmî paketleriyle karşılaştırıldığında fazladan bulunan ya da değişmiş dosyalar.
- Zamanlanmış görevlere (cron) eklenmiş yeni satırlar, tanımadığınız süreçler ve SSH yetkili anahtar dosyalarına eklenmiş yabancı anahtarlar.
Logları inceleyin
Web sunucusu erişim ve hata loglarında 17 Ekim ve sonrasına ait olağan dışı istekleri, PHP-FPM loglarında beklenmedik süreç çökmelerini ve bellek hatalarını, yükleme klasöründeki dosyalara yapılan POST isteklerini inceleyin. Şüpheli bir dosya bulursanız ona yapılan ilk erişimin tarihini ve kaynak IP adresini tespit etmek, olayın kapsamını anlamaya yardımcı olur.
Ciddi bulgu varsa temiz kurulum yapın
Ele geçirilmeye dair güçlü bir işaret bulduysanız tek tek dosya silmek yerine, kodu temiz kaynaktan yeni bir sunucuya kurmak daha güvenlidir. Saldırganlar çoğu zaman farklı yerlere birden fazla arka kapı bırakır. Kişisel veri işleyen sistemlerde 6698 sayılı Kanun kapsamındaki bildirim yükümlülükleri de gündeme gelebilir; bu konuda güncel mevzuatı ve hukuk danışmanınızın görüşünü esas alın.
Web shell yüklemesine karşı kalıcı önlemler nelerdir?
PHP2Shell, PHP'nin kendisindeki bir açık. Ancak PHP sitelerine web shell yerleştirilmesinin daha sık görülen başka yolları da var: güvensiz dosya yükleme formları, kullanıcı girdisinin include veya eval ile işlenmesi, güncellenmemiş CMS eklentileri, kullanıcı verisiyle çağrılan unserialize ve çalınmış yönetici şifreleri. Aşağıdaki önlemler, hem bu yollara karşı hem de bir sonraki çekirdek açığında hasarı sınırlamak için kalıcı bir zemin oluşturur.
| Önlem | Uygulama ve amacı |
|---|---|
| Yükleme klasörlerinde PHP'yi kapatmak | Nginx'te yükleme klasörü için PHP işleyicisinden önce eşleşen ayrı bir location bloğu tanımlanır ve bu klasördeki .php, .phtml, .phar isteklerine "deny all" uygulanır. Apache'de aynı klasör için PHP motoru kapatılır. Böylece doğrulamayı aşan bir dosya bile çalıştırılamaz. Kural uygulandıktan sonra zararsız bir test dosyasıyla doğrulanmalıdır. |
| Güvenli dosya yükleme | İzin verilen uzantılardan oluşan beyaz liste, sunucu tarafında içerik doğrulaması, sunucunun ürettiği rastgele dosya adları ve mümkünse dosyaların web kök dizini dışında saklanması. |
| disable_functions | Uygulamanın kullanmadığı exec, shell_exec, system, passthru, proc_open, popen gibi komut çalıştıran fonksiyonların php.ini üzerinden kapatılması. Tek başına aşılmaz bir engel değildir, ancak saldırganın işini zorlaştırır. |
| Diğer php.ini ayarları | allow_url_include kapalı, üretimde display_errors kapalı, expose_php kapalı; open_basedir ile PHP'nin erişebileceği dizinlerin sınırlandırılması. |
| En az yetki | Uygulama kodu PHP süreci tarafından yalnızca okunabilir olmalı; yazma yetkisi yalnızca yükleme, önbellek ve log klasörlerine verilmelidir. Her site ayrı sistem kullanıcısı ve ayrı PHP-FPM havuzu ile çalışmalı, 777 gibi izinler kullanılmamalıdır. |
| Güncelleme disiplini | PHP, CMS çekirdeği, eklentiler ve Composer bağımlılıkları düzenli güncellenmeli; desteği bitmiş PHP sürümleri kullanılmamalıdır. |
| Yedekleme | Dosya ve veritabanı yedekleri sunucu dışında, birkaç haftalık geçmişle saklanmalıdır; böylece bulaşmanın tarihinden önceki temiz bir duruma dönülebilir. |
| Dosya bütünlüğü izleme | Kod dizinindeki beklenmedik değişikliklerde uyarı üreten izleme, bulaşmanın saatler içinde fark edilmesini sağlar. |
En az yetki ilkesinin PHP2Shell açısından da doğrudan bir karşılığı var: açık, kodu web sunucusu kullanıcısının yetkileriyle çalıştırıyor. Bu kullanıcının uygulama dosyalarını değiştiremediği, başka sitelerin dosyalarına erişemediği bir yapıda saldırganın hareket alanı belirgin biçimde daralır. Hazır bir paket yerine ihtiyaca göre geliştirilen sistemlerde bu yapı en baştan kurgulanabilir; bu tercihin artı ve eksilerini hazır yazılım mı, özel yazılım mı yazımızda karşılaştırdık.
Sık yapılan hatalar
- Paketi güncelleyip PHP-FPM'i yeniden başlatmamak: Eski kod bellekte çalışmaya devam eder.
- Yalnızca php -v çıktısına güvenmek: Komut satırı sürümü, web isteklerini karşılayan sürümle aynı olmayabilir.
- "Bizim kodumuz güvenli" diye düşünmek: Açık, uygulama kodu çalışmadan önce tetiklenir.
- Sırları yenilememek: İstismar duyurudan önce başladığı için yama tek başına yeterli değildir.
- WAF kuralına güvenip yamayı ertelemek: Kurallar atlatılabilir, yamanın yerini tutmaz.
Sonuç
PHP2Shell, PHP ekosisteminin son yıllarda karşılaştığı en ciddi açıklardan biri. Yapılacaklar net: web tarafında çalışan PHP sürümünü kontrol edin, 8.5.12, 8.4.27, 8.3.36 veya 8.2.35 sürümlerinden size uygun olanına geçin, PHP süreçlerini yeniden başlatın, sırları yenileyin ve sunucuda web shell izi arayın. Desteği bitmiş bir sürümdeyseniz yükseltmeyi ertelemeyin. PHP tabanlı kurumsal siteleriniz için web tasarım, özel paneller ve iş uygulamaları için özel yazılım geliştirme, ödeme ve müşteri verisi işleyen mağazalar için ise e-ticaret yazılımı sayfalarımızı inceleyebilirsiniz. Sunucunuzun güncelleme ve kontrol sürecinde destek almak isterseniz bizimle iletişime geçin.
Sık sorulan sorular
PHP2Shell açığı WordPress sitelerini etkiler mi?
Evet. Açık PHP'nin çekirdeğinde bulunduğu ve uygulama kodu çalışmadan önce tetiklenebildiği için WordPress dahil PHP ile çalışan tüm CMS'ler ve çatılar etkilenir. Çözüm, sunucudaki PHP'yi yamalı sürüme yükseltmek ve PHP süreçlerini yeniden başlatmaktır.
PHP2Shell için hangi PHP sürümüne geçmeliyim?
Kullandığınız sürüm hattına göre PHP 8.5.12, 8.4.27, 8.3.36 veya 8.2.35 sürümüne geçmelisiniz. PHP 8.1 ve öncesi için resmî yeni sürüm yayımlanmadı; bu durumda desteklenen bir sürüme geçiş veya uzun süreli destek veren bir sağlayıcı gerekir.
Paylaşımlı hosting kullanıyorum, ne yapmalıyım?
Paylaşımlı hostingde PHP'yi barındırma firması günceller. Firmanıza yamalı sürümlerin kurulup kurulmadığını ve PHP süreçlerinin yeniden başlatılıp başlatılmadığını yazılı olarak sorun, panelde eski bir PHP sürümü seçiliyse desteklenen bir sürüme geçin.
Yama yaptıktan sonra şifreleri değiştirmek gerekli mi?
Evet, önerilir. İstismar girişimleri resmî duyurudan önce başladı ve araştırmacılar PHP süreç belleğinden veri sızdırılabildiğini gösterdi. Bu nedenle veritabanı şifreleri, API anahtarları ve uygulama şifreleme anahtarları yenilenmeli, eski değerler iptal edilmelidir.
WAF kullanmak PHP2Shell'e karşı yeterli mi?
Hayır. WAF kuralları bilinen saldırı vektörlerini engeller ve yamaya kadar zaman kazandırır, ancak farklı biçimde hazırlanmış isteklerle atlatılabilir. Kalıcı çözüm PHP'nin yamalı sürüme yükseltilmesidir.
