php2shell: PHP'deki Kritik Açık Siteniz İçin Ne Anlama Geliyor?

PHP projesinin duyurusuna göre 21 Ekim 2026'da iki kritik güvenlik açığını kapatan acil sürümler yayımlandı. Güvenlik dünyasında php2shell adıyla anılan bu açıklar bir eklentide ya da temada değil, PHP yorumlayıcısının kendisinde. Yani siteniz WordPress, Joomla, Laravel, OpenCart ya da kendi yazdığınız bir PHP uygulaması olsun, yamasız bir PHP sürümünde çalışıyorsa doğrudan etkileniyor.

Bu yazıda üç soruyu cevaplıyoruz: Ne oldu? Şimdi ne yapmalısınız? Ve yedeğinizin bu tablodaki yeri ne? Çünkü yama, kapıyı kapatır; ama kapı açıkken içeri girmiş birini dışarı çıkarmaz.

Ne oldu? Kısa özet

• Açıklar (PHP'nin güvenlik duyurusuna göre): CVE-2026-109618 (bellek yetersizliği sırasında yarım kalan istek verisinin geçerli sayılması) ve CVE-2026-109619 (serbest bırakılmış belleğin aynı işçide sonraki bir istek tarafından kullanılması).
• Önem derecesi: PHP her ikisini de CVSS v4.0'da 9,2 — Kritik olarak derecelendirdi.
• Etkisi: Kimlik doğrulaması gerektirmeden, web sunucusu kullanıcısının yetkileriyle uzaktan kod çalıştırma. PHP'nin duyurusu ayrıca bellek içeriğinin sızmasını da doğrulanmış etki olarak sayıyor; bu da sunucudaki parolaların, belirteçlerin ve API anahtarlarının açığa çıkabileceği anlamına geliyor.
• Kapsam: Web isteklerine hizmet veren bütün kurulumlar — PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed. Araştırmacılara göre etkilenen kod yolu PHP 5.4'e kadar uzanıyor.
• Zaman çizelgesi: Amazon'un tehdit istihbaratı ekibi ilk istismar denemesini 17 Ekim'de, yani duyurudan dört gün önce gördü. 20 Ekim'de CVE numaraları ambargo bitmeden sosyal medyada dolaşmaya başladı. PHP, 22 Ekim'e planlanan yamayı bir gün öne çekerek 21 Ekim'de yayımladı.
• Bugünkü durum: Amazon açığın artık geniş çapta istismar edildiğini, Cloudflare ise ilk saldırıları gördüğünü açıkladı. Bazı kurumlar önlem olarak servislerini geçici olarak kapattı.

Şimdi yapmanız gerekenler (sırasıyla)

1. Eski yedeklerinizi koruma altına alın

Bu adım çoğu rehberde atlanıyor ama en kritik olanı. Yedekleme sisteminiz "son 7 kopyayı tut" gibi bir kuralla çalışıyorsa, her yeni yedek en eskisini siler. Siteniz 17 Ekim'den sonra ele geçirildiyse, bundan sonra alınan her yedek ele geçirilmiş hâlin kopyası olur ve 17 Ekim öncesinin temiz kopyalarını sırayla dışarı iter. Bu yüzden ilk iş, 17 Ekim öncesine ait en az bir yedeği ayrı bir yere kopyalayın ya da saklama süresini geçici olarak uzatın. Yedekleriniz sitenin çalıştığı sunucuda duruyorsa bu "ayrı yer" mutlaka o sunucunun dışında olmalı; sonraki yedekler için de depolama hedefinizi uzak bir hedefe (bulut depolama ya da ayrı bir sunucu) geçirin.

2. PHP sürümünüzü öğrenin ve güncelleyin

Hosting panelinizdeki "PHP sürümü" ekranından ya da bir phpinfo() sayfasından tam sürüm numaranızı görün. Paylaşımlı hostingdeyseniz firmanıza açıkça sorun: "PHP paketleriniz 21 Ekim 2026 güvenlik yamalarını içeriyor mu?" Kendi sunucunuzu yönetiyorsanız dağıtımınızın güvenlik duyurusunu takip edin ve güncellemeden sonra bütün PHP işçilerini yeniden başlatın; eski süreçler bellekte eski kodu çalıştırmaya devam eder.

3. Hemen güncelleyemiyorsanız

PHP projesi bazı geçici yapılandırma önlemleri yayımladı (örneğin session.upload_progress.enabled=0). Bunları sunucu yöneticiniz ya da hosting firmanız uygulayabilir. Ancak PHP'nin kendi ifadesiyle bu ayarlar riski azaltır, kurulumu güvenli hâle getirmez. Yüksek riskli bir siteyi (ödeme alan bir e-ticaret sitesi gibi) güncellenene kadar bakım moduna almak makul bir seçenektir.

4. Sunucudaki sırları değiştirin

Açık bellek içeriğini sızdırabildiği için, sunucunuzda duran her türlü sır risk altında kabul edilmelidir: veritabanı parolası, wp-config.php içindeki güvenlik anahtarları, ödeme ve kargo entegrasyonlarının API anahtarları, SMTP parolası ve yedekleme hedefinizin erişim anahtarları. Güncellemeden sonra bunları yenileyin.

5. İz arayın

17 Ekim'den bu yana değişmiş PHP dosyalarına, yükleme klasörlerinde (uploads gibi) bulunmaması gereken .php dosyalarına, tanımadığınız yönetici hesaplarına ve yeni eklenmiş zamanlanmış görevlere bakın. Patchstack'in paylaştığı kayıt belirtileri (olağan dışı çok parçalı istekler ardından bellek sınırı hataları ya da HTTP 500 yanıtları, aşırı uzun veya bozuk PHPSESSID çerezleri, açıklanamayan işçi yeniden başlamaları) ipucu verir ama tek başına kanıt değildir.

6. "Hızlı çözüm" tuzaklarından uzak durun

İnternette dolaşan "php2shell yaması" eklentilerine ve kopyala-yapıştır kod parçalarına güvenmeyin. Ortalıkta dolaşan istismar kodlarının doğrulanmadığını ve zararlı yazılım içerebileceğini de güvenlik firmaları özellikle vurguluyor.

Yama kapıyı kapatır, içeridekini çıkarmaz

Asıl tehlikeli dönem, ilk istismar denemesinin görüldüğü 17 Ekim ile yamanın yayımlandığı 21 Ekim arasıdır — ve yamayı uygulayana kadar geçen her saat. Bu sürede sitenize giren biri genellikle ilk iş olarak kalıcı bir arka kapı bırakır. PHP'yi güncellemek yeni girişleri engeller; zaten bırakılmış bir arka kapıyı silmez.

Burada yedeğin rolü netleşiyor. Ele geçirilmiş bir siteyi dosya dosya temizlemek hem uzun sürer hem de bir şeyi gözden kaçırma riski taşır. En güvenilir yol, olaydan önceki temiz bir kopyaya dönmek, PHP'yi güncellemek ve sırları değiştirmektir. Ama bu yolun işlemesi için yedeğinizin üç şartı karşılaması gerekir.

Temiz yedeğin üç şartı

1. Olaydan önceye uzanmalı. Çoğu paylaşımlı hosting yedeği yalnızca birkaç gün saklanır. Sorunu 30 Ekim'de fark ederseniz, 17 Ekim öncesi kopya çoktan silinmiş olabilir.
2. Sunucudan bağımsız durmalı. Bu açık, saldırgana web kullanıcısının yetkilerini veriyor. Yedekleriniz aynı hesapta, aynı kullanıcının yazabildiği bir klasörde duruyorsa saldırgan onları da silebilir ya da şifreleyebilir.
3. Açılabildiği kanıtlanmış olmalı. "Panelde başarılı görünüyordu" ile "geri yüklenebiliyor" aynı şey değildir. Kötü günde ilk kez denenen yedek, çoğu zaman o gün sürpriz yapar.

Bir de dördüncü, bu açığa özgü bir risk var: Bellek sızıntısı yedekleme hedefinizin anahtarlarını da ele verebilir. Anahtarı ele geçiren biri, uzaktaki yedeklerinizi de silmeye çalışabilir. Bu senaryonun tek kesin cevabı, belirli bir süre boyunca kimsenin silemediği bir kopyadır.

Yedekalma bu tabloda ne sağlar?

Açık konuşalım: hiçbir yedekleme ürünü PHP açığını kapatmaz; PHP'yi güncellemek zorunludur. Yedeğin işi, açık istismar edildiyse geri dönüşü mümkün ve hızlı kılmaktır. Yedekalma'nın bu senaryoda işe yarayan özellikleri şunlar:

• Yedekleri sitenizin sunucusundan uzağa gönderebilirsiniz. Yedek sunucunuzda paketlenir; depolama hedefi olarak Google Drive, Amazon S3 ve S3 uyumlu servisler, OneDrive, Dropbox ya da ayrı bir sunucudaki Alıcı Modül'ü seçtiyseniz doğrudan oraya gönderilir ve siteniz ele geçirilse bile yedekleriniz aynı yerde durmaz. Yedekleri sitenin kendi sunucusunda tutuyorsanız bu koruma yoktur: o sunucuya giren saldırgan yedeklere de ulaşabilir. Bu durumda panelden depolama hedefinizi bu uzak hedeflerden birine geçirin.
• Silinemez kopya (WORM). Object Lock açık bir S3 kovasında yedekler belirlediğiniz süre boyunca kilitlenir. COMPLIANCE modunda, saldırgan sunucunuza ve bulut anahtarlarınıza erişse bile kilitli kopyayı süre dolana kadar silemez — anahtar sızıntısı senaryosunun doğrudan cevabı budur. WORM yedekleme nasıl çalışır?
• Doğrulanmış yedek. Her yedek 8 katmanda (kapsam, içerik, veritabanı, bütünlük, SHA-256 dahil) otomatik doğrulanır; her alan adının en son yedeği de sırayla, periyodik geri yükleme tatbikatıyla sınanır. Tatbikat eski kopyaları tek tek denemez: "17 Ekim öncesi yedeğim gerçekten açılıyor mu?" sorusunun kesin cevabı için o kopyayı bir test ortamına geri yükleyerek deneyin. Yedek doğrulama hakkında
• Tam ya da kısmi geri yükleme. Geri yükleme sihirbazıyla dosyaları, veritabanını ve e-postaları tamamen ya da kısmen geri getirebilirsiniz. Örneğin temiz kodu geri yükleyip veritabanını ayrıca incelemek mümkündür.
• İsteğe bağlı AES-256 şifreleme. Şifrelemeyi açarsanız arşiv daha sunucunuzdan çıkmadan şifrelenir; parola bizde saklanmaz.

Konuyla ilgili sayfalar: PHP yedekleme modülü · silinemez yedek (WORM) · WordPress hacklendi: ne yapmalı?

Sık Sorulan Sorular