# PHP2Shell Nedir? PHP'deki Kritik Açık ve Sitenizi Korumak İçin Yapmanız Gerekenler

> 21 Ekim 2026'da PHP'de, giriş yapmadan sunucuyu ele geçirmeye izin veren iki kritik açık kapatıldı. Adı PHP2Shell. Sitenizin etkilenip etkilenmediğini nasıl anlarsınız, paylaşımlı hostingde ne yapmalısınız, hosting firmanıza ne sormalısınız? Adım adım anlattım.

- URL: https://atakankademli.com.tr/blog/php2shell
- Yazar: Atakan Kademli
- Yayın: 2026-10-22
- Güncelleme: 2026-10-22
- Kategori: Web Tasarım & Performans

## Kısa Cevap

**PHP2Shell**, PHP yorumlayıcısının çekirdeğinde bulunan ve 21 Ekim 2026'da kapatılan iki kritik açığın (**CVE-2026-109618** ve **CVE-2026-109619**, CVSS 9.2) ortak adıdır. Saldırgan **hiç giriş yapmadan**, tek bir istekle sunucuda kod çalıştırabiliyor. Son 10 yılın neredeyse tüm PHP sürümleri etkileniyor. WordPress, Drupal ve Joomla dahil PHP ile çalışan her site risk altında. Çözüm tek: PHP'yi **8.5.12, 8.4.27, 8.3.36 veya 8.2.35** sürümüne (ya da hosting firmanızın yamalı paketine) güncellemek. Eklenti veya site içi ayar bu açığı kapatmaz.

## Önemli Çıkarımlar

- PHP2Shell, PHP çekirdeğindeki iki kritik açığın (CVE-2026-109618 ve CVE-2026-109619, CVSS 9.2) ortak adıdır ve giriş yapmadan uzaktan kod çalıştırmaya izin verir.
- Son on yılın neredeyse tüm PHP sürümleri etkileniyor; WordPress, Drupal ve Joomla dahil PHP ile çalışan her site risk altında.
- Güvenli sürümler 8.5.12, 8.4.27, 8.3.36 ve 8.2.35; 8.1 ve altı için resmi güncelleme yok.
- Paylaşımlı hostingde PHP'yi hosting firması günceller; yama durumunu mutlaka sorun.
- Eklentiler veya site içi ayarlar açığı kapatmaz; tek tam çözüm PHP güncellemesidir.
- Yama sonrası veritabanı şifresi ve API anahtarları gibi kimlik bilgilerini yenileyin.

WordPress siteniz güncel, eklentileriniz güncel, şifreniz güçlü. Buna rağmen siteniz bu hafta risk altında olabilir. Çünkü sorun sitenizde değil, sitenizin üzerinde çalıştığı **PHP**'nin kendisinde.

21 Ekim 2026'da PHP ekibi, **PHP2Shell** adı verilen iki kritik açığı kapatan acil bir güvenlik güncellemesi yayımladı. Açığı bulan Wiz araştırmacılarına göre bunlar PHP'de bugüne kadar bulunan en ciddi açıklar arasında. Güvenlik araştırmacısı Kevin Beaumont ise durumu "son yılların en büyük açıklarından biri, çok sayıda olaya yol açacak" diye özetledi.

Bu yazıda teknik ayrıntılara boğulmadan şu soruları cevaplıyorum: **PHP2Shell nedir, siteniz etkileniyor mu, bugün ne yapmalısınız?** Özellikle Türkiye'deki çoğu işletmenin kullandığı **paylaşımlı hosting ve cPanel** tarafına odaklandım.

**Hemen yapılacak tek şey**
Bu yazıyı sonuna kadar okumaya vaktiniz yoksa: Hosting firmanıza "PHP2Shell (CVE-2026-109618 ve CVE-2026-109619) yamaları sunucumuza uygulandı mı?" diye yazın. Cevap "hayır" ya da "bilmiyoruz" ise bu yazıdaki adımlara dönün.


## PHP2Shell nedir?

PHP2Shell, PHP'nin çekirdeğinde bulunan iki ayrı güvenlik açığının ortak adıdır. İki açık da **kimlik doğrulama gerektirmeden uzaktan kod çalıştırmaya** (unauthenticated RCE) izin veriyor.

| | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| Önem derecesi | CVSS 9.2 (kritik) | CVSS 9.2 (kritik) |
| Sorunun kaynağı | Bellek yetersizliği (out-of-memory) anında bozulan bellek | Bir istekten kalan verinin sonraki istekte yeniden kullanılması |
| Sonuç | Uzaktan kod çalıştırma, sunucu belleğinin okunması | Uzaktan kod çalıştırma |
| Giriş gerekiyor mu? | Hayır | Hayır |

Bu iki açığı sıradan güvenlik açıklarından ayıran üç özellik var:

1. **Uygulamadan bağımsız:** Açık sitenizin kodunda veya eklentilerinizde değil, PHP'nin kendisinde. Kullandığınız yazılım ne olursa olsun, PHP sürümünüz açıklıysa siteniz de açık.
2. **Tek istek yetiyor:** PHP'nin açıklamasına göre saldırı, sitenizin kendi kodu daha çalışmaya başlamadan, tek bir istekle tetiklenebiliyor.
3. **Bellek okunabiliyor:** Saldırgan PHP'nin belleğini okuyabildiği için orada duran **veritabanı şifreleri, oturum bilgileri ve API anahtarları** açığa çıkabiliyor.

### Neden "PHP2Shell" deniyor?

Güvenlik dünyasında "shell" (kabuk), bir sunucuda komut çalıştırabilme yetkisi demektir. Bir saldırganın "shell alması", sunucunun kontrolünü ele geçirmesi anlamına gelir. PHP2Shell adı da açığın PHP üzerinden doğrudan sunucu kontrolüne götürebildiğini anlatıyor.

## Hangi siteler etkileniyor?

Kısa cevap: **PHP ile çalışan ve güncellenmemiş neredeyse her site.**

- Wiz'e göre PHP 5.4'ten bu yana, yani son on yılda yayımlanmış **her PHP sürümünde** bu açıklardan en az biri var.
- Wiz, açığın en güncel **WordPress, Drupal ve Joomla** kurulumlarında çalıştığını gösterdi.
- PHP'nin web isteklerini işlediği tüm kurulum türleri etkileniyor: **PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed**. PHP ekibine göre en acil durum **Apache mod_php** kullanan sunucular.
- Wiz, PHP'nin internetteki sitelerin yaklaşık **%70'ini** çalıştırdığını belirtiyor.

Türkiye'deki kurumsal sitelerin, e-ticaret sitelerinin ve blogların büyük kısmı WordPress veya başka bir PHP altyapısıyla çalıştığı için bu açık doğrudan Türkiye'deki işletmeleri de ilgilendiriyor.

### Güvenli sürümler

| PHP sürüm dalı | Açığın kapatıldığı sürüm | Durum |
|---|---|---|
| PHP 8.5 | **8.5.12** | Destekleniyor |
| PHP 8.4 | **8.4.27** | Destekleniyor |
| PHP 8.3 | **8.3.36** | Destekleniyor |
| PHP 8.2 | **8.2.35** | Destekleniyor (31 Aralık 2026'da sona eriyor) |
| PHP 8.1, 8.0, 7.4 | Resmi sürüm yok | Desteği bitti. PHP ekibi yalnızca kaynak koddan derleyenler için asgari yamalar yayımladı |
| PHP 7.3 ve öncesi | Yama yok | Hemen yükseltilmeli |

**Sürüm numarası her zaman tüm hikâyeyi anlatmaz**
Ubuntu, Debian, Red Hat veya CloudLinux gibi dağıtımlar yamayı eski sürüm numarasını koruyarak da uygulayabiliyor. Bu yüzden sunucunuzda "8.3.36" görmüyorsanız bu tek başına açık olduğunuzu kanıtlamaz. Kesin cevap için hosting firmanıza veya kullandığınız dağıtımın güvenlik duyurusuna bakın.


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

| Tarih | Olay |
|---|---|
| 19 Ağustos 2026 | Wiz araştırmacıları ilk hatayı buldu |
| 20–21 Ağustos 2026 | Drupal ve WordPress üzerinde giriş yapmadan uzaktan kod çalıştırma doğrulandı |
| 24 Ağustos 2026 | Açık PHP güvenlik ekibine bildirildi |
| 21 Eylül 2026 | PHP ekibi koordineli düzeltme sürecini başlattı |
| 17 Ekim 2026 | Amazon'un tuzak sunucuları (MadPot) açığı kullanmaya yönelik bir saldırı girişimi kaydetti. Bu, açık duyurulmadan **4 gün önce** |
| 20 Ekim 2026 | PHP, kritik bir güvenlik güncellemesinin geleceğini önceden duyurdu |
| 21 Ekim 2026 | Yamalı sürümler yayımlandı. Cloudflare ilk koruma kurallarını devreye aldı |

17 Ekim'deki girişim önemli: Amazon'un tespitine göre en az bir saldırgan açıktan, kamuoyu duyurulmadan önce haberdardı. Bilgiye nasıl ulaştığı bilinmiyor.

### Açığı yapay zekâ buldu

PHP2Shell'in bir ilginç yanı daha var. Wiz, açığı bulurken kendi aracı Wiz Atlas'ın yanında **Gemini 4 Argon** ve **GPT-5.6 Sol** modellerini kullandığını açıkladı. Wiz'e göre yapay zekâ sayesinde tek bir araştırmacı, eskiden bir ekibin aylarını alacak işi bir haftada tamamladı. Google DeepMind'ın Gemini güvenlik sorumlusu Raluca Ada Popa da bu çalışmanın "öncü yapay zekânın siber savunmada neden oyunun kurallarını değiştirdiğini" gösterdiğini söyledi. Gemini 4 Argon'un güvenlik yetenekleri için [Gemini 4 Argon yazıma](/blog/gemini-4-argon) göz atabilirsiniz.

Bu, madalyonun iki yüzünü de gösteriyor: Yapay zekâ açıkları savunanlar için daha hızlı bulduruyor, ama aynı hız saldırganlar için de geçerli. Yama ile saldırı arasındaki süre giderek kısalıyor.

## Saldırılar başladı mı?

Evet, ilk işaretler var:

- **Patchstack**, 21 Ekim sabahı hosting iş ortaklarından birden fazla aktif saldırı olayı bildirildiğini açıkladı. Aynı günün öğleden sonrasında kendi verilerinde ise yalnızca "yoklama" (probing) girişimleri görüyordu, ama bunun değişmesini beklediğini belirtti.
- **Cloudflare**'in teknoloji direktörü Dane Knecht, ilk saldırıları gördüklerini ve ücretsiz plan dahil tüm müşteriler için koruma kuralları yayınladıklarını duyurdu.
- **CERT-EU**, ilk kavram kanıtı (PoC) kodlarının dolaşıma girdiğini ve bunun saldırı ihtimalini artırdığını belirtti.
- Adli bilişim uzmanı Hal Pomeranz'ın uyarısı ise uzun vadeli riski özetliyor: "Asla yamalanmayacak çok sayıda gömülü kurulum var."

## Siteniz etkileniyor mu? 5 dakikalık kontrol

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

**cPanel kullanıyorsanız:** "Yazılım" bölümündeki **MultiPHP Yöneticisi** ya da **PHP Sürümünü Seç** (CloudLinux PHP Selector) ekranında sitenizin hangi PHP dalını (8.2, 8.3 gibi) kullandığını görebilirsiniz. Ancak bu ekranlar genellikle **ara sürümü** (8.3.**36** gibi) göstermez.

**WordPress kullanıyorsanız:** Yönetim paneli → **Araçlar → Site Sağlığı → Bilgi → Sunucu** bölümünde PHP sürümü tam olarak yazar.

**Tam sürümü görmek için:** Hosting firmanıza sorun ya da teknik ekibinizden, sitenin gerçekten kullandığı PHP sürümünü kontrol etmesini isteyin. Sunucuda komut satırında `php -v` ile görülen sürüm, web sitesinin kullandığı sürümden farklı olabilir. Bu, sık yapılan bir yanılgı.

### 2. Sürümü tabloyla karşılaştırın

- 8.5.12, 8.4.27, 8.3.36, 8.2.35 veya üzeri: **Yama uygulanmış.**
- Bunların altında ama 8.2 ve üzeri: **Büyük ihtimalle açık.** Hosting firmanızın yamayı farklı numarayla uygulayıp uygulamadığını sorun.
- 8.1 ve altı: **Risk yüksek.** Sürümün desteği bitmiş durumda; yükseltme planı yapın.

### 3. Hosting firmanıza sorun

Paylaşımlı hostingdeyseniz PHP'yi siz değil, hosting firmanız günceller. Şu mesajı kopyalayıp destek talebi olarak gönderebilirsiniz:

> Merhaba, PHP2Shell olarak bilinen CVE-2026-109618 ve CVE-2026-109619 açıklarıyla ilgili olarak:
> 1. Hesabımın bulunduğu sunucudaki PHP sürümlerine yamalar uygulandı mı? Uygulanmadıysa planlanan tarih nedir?
> 2. Yamalar uygulanana kadar sunucu düzeyinde geçici önlem alındı mı?
> 3. Sunucuda bu açığa yönelik saldırı belirtisi tespit edildi mi?
> Teşekkürler.

ABD'li hosting firması InMotion gibi bazı firmalar, yama gelmeden önce sunucu düzeyinde geçici önlemler aldı ve müşterilerine duyurdu. Firmanız bir duyuru yapmadıysa sormak sizin hakkınız.

## Bugün yapmanız gerekenler

### Paylaşımlı hosting kullanıyorsanız

1. **Hosting firmanıza yukarıdaki mesajı gönderin.**
2. **Destek süresi bitmiş PHP sürümlerinden çıkın.** Siteniz PHP 8.1 veya altındaysa, cPanel'den 8.3 veya 8.4'e geçmeyi planlayın. Geçişten önce yedek alın ve siteyi test edin. Eski bir tema veya eklenti yeni sürümde hata verebilir.
3. **Sitenizin yedeğini alın.** Hem dosyaları hem veritabanını, sunucu dışında bir yere.
4. **Kulaktan dolma "tek satırlık çözümlere" güvenmeyin.** Patchstack, internette dolaşan resmi olmayan "düzeltme" eklentileri ve kod parçalarının doğrulanmadığını ve siteyi bozabileceğini belirtiyor. Açığı kapatan şey PHP güncellemesidir; site içinden yapılacak bir ayar bunu sağlamaz.

### Kendi sunucunuzu (VPS, sanal sunucu) yönetiyorsanız

1. **PHP paketlerini güncelleyin.** Dağıtımınızın veya kontrol panelinizin (cPanel EasyApache, CloudLinux alt-php, Plesk, LiteSpeed) güvenlik duyurusunu takip edin.
2. **Tüm PHP süreçlerini yeniden başlatın.** Paket güncellense bile çalışan eski süreçler eski kodu kullanmaya devam edebilir. Qualys, güncellemeden sonra çalışan süreçlerin gerçekten yeni sürümü kullandığını doğrulamayı öneriyor.
3. **Kullanmadığınız PHP sürümlerini kaldırın.** cPanel'de MultiPHP Yöneticisi sürüm *atar*, paket *güncellemez*. Eski bir sürüme bağlı unutulmuş tek bir alan adı bile risk oluşturur.
4. **Yamayı hemen uygulayamıyorsanız** PHP ekibinin ve CERT-EU'nun önerdiği geçici yapılandırma önlemlerine bakın. Bunlar riski azaltır ama ortadan kaldırmaz. Bu önlemlerin bir kısmı (ör. `session.upload_progress.enabled=0`) yalnızca `php.ini` veya FPM havuzu düzeyinde ayarlandığında etkilidir; `.user.ini` veya site kodu ile yapılamaz.
5. **Yama mümkün değilse siteyi geçici olarak kapatın.** İngiltere'nin siber güvenlik merkezi NCSC, yamalanamayan sistemlerin çevrim dışı alınmasını öneriyor.

**Cloudflare kullanıyorsanız**
Cloudflare'in yayınladığı kurallar ücretsiz planda da devrede. Ama bu yalnızca sitenize gelen tüm trafik Cloudflare üzerinden geçiyorsa işe yarar ve **yamanın yerini tutmaz**. Geçici bir kalkan olarak düşünün.


## Saldırıya uğradığımı nasıl anlarım?

Açık, sitenizin kodunun altında, PHP katmanında çalıştığı için site loglarında iz bırakmayabilir. Wiz'in paylaştığı ve sunucu yöneticilerinin izleyebileceği işaretler:

- Ardından bellek limiti hataları gelen olağandışı dosya yükleme (multipart) istekleri,
- Tekrarlayan **HTTP 500** hataları,
- Yanıtlarda beklenmedik şekilde büyük veya bozuk `PHPSESSID` çerezleri,
- Açıklanamayan PHP süreç yeniden başlamaları.

Bu işaretler tek başına kesin kanıt değil, ama hosting firmanızla paylaşılması gereken bilgiler.

### Yama sonrası güvenlik kontrolü

Yama uygulandıktan sonra, özellikle siteniz yama gelmeden önce bir süre açıkta kaldıysa, şu genel güvenlik adımlarını atmanızı öneririm:

1. **Şifreleri değiştirin.** PHP belleği okunabildiği için Patchstack, sunucudaki kimlik bilgilerinin yenilenmesini öneriyor: veritabanı şifresi (WordPress'te `wp-config.php` içindeki), yönetici şifreleri, ödeme ve kargo entegrasyonlarının API anahtarları.
2. **Yönetici hesaplarını kontrol edin.** Tanımadığınız bir kullanıcı var mı?
3. **Son değişen dosyalara bakın.** Özellikle yükleme klasörlerinde beklenmedik `.php` dosyaları bir uyarı işaretidir.
4. **Bir güvenlik taraması yapın.** WordPress için güvenilir bir güvenlik eklentisiyle veya hosting firmanızın kötü amaçlı yazılım tarayıcısıyla.

## Bu açıktan çıkarılacak dersler

**Eski PHP sürümü "çalışıyor" olsa da güvenli değil.** Bir geliştiricinin açık duyurulduğu sabah yayınladığı kontrol aracıyla sitesinin tam PHP sürümünü kontrol edip sonucu paylaşan 26 site sahibinden 11'inin (yaklaşık **%42**) desteği bitmiş bir PHP sürümü kullandığı görüldü. Bu örneklem küçük ve temsili değil, ama sorunun yaygınlığı hakkında bir fikir veriyor.

**Güvenlik sadece eklenti güncellemek değil.** Çoğu site sahibi WordPress ve eklenti güncellemelerini takip eder, ama altındaki PHP sürümüne hiç bakmaz. PHP2Shell, en güncel WordPress'in bile eski bir PHP üzerinde savunmasız kalabileceğini gösterdi.

**Hosting seçimi bir güvenlik kararıdır.** Kritik bir açıkta hosting firmanızın ne kadar hızlı yama uyguladığı ve sizi ne kadar şeffaf bilgilendirdiği, sitenizin güvenliğini doğrudan belirler. Web sitesi altyapısı seçerken dikkat edilmesi gereken diğer noktalar için [Web sitesi yaptırırken dikkat edilmesi gerekenler](/blog/web-sitesi-yaptirirken-dikkat-edilmesi-gerekenler) rehberime bakabilirsiniz.

## Sonuç

PHP2Shell, sitenin kendisi güncel olsa bile altındaki altyapı yüzünden açık verilebileceğini gösteren ciddi bir açık. İyi haber şu: Çözümü net. PHP'yi güncel sürüme yükseltmek açığı tamamen kapatıyor.

Bugün yapmanız gereken üç şey: **PHP sürümünüzü öğrenin, hosting firmanıza yamayı sorun, destek süresi bitmiş bir sürümdeyseniz yükseltme planı yapın.** Sitenizin güvenlik kontrolü ve PHP geçişi için destek isterseniz [floopping](https://floopping.com) ekibiyle iletişime geçebilirsiniz.

Bu yazıyı hosting firmalarının yama durumları ve yeni gelişmeler netleştikçe güncelleyeceğim.

## Sıkça Sorulan Sorular

### PHP2Shell nedir?

PHP2Shell, PHP yorumlayıcısının çekirdeğinde bulunan ve 21 Ekim 2026'da kapatılan iki kritik güvenlik açığının (CVE-2026-109618 ve CVE-2026-109619) ortak adıdır. Saldırganın hiç giriş yapmadan sunucuda kod çalıştırmasına izin verir.

### WordPress sitem PHP2Shell'den etkilenir mi?

Siteniz yamalanmamış bir PHP sürümünde çalışıyorsa evet. Açık WordPress'te değil PHP'de olduğu için WordPress ve eklentileriniz güncel olsa bile risk devam eder. Wiz, açığın en güncel WordPress kurulumunda çalıştığını gösterdi.

### Hangi PHP sürümleri güvenli?

PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 ile bunların üzerindeki sürümler yamalıdır. Bazı dağıtımlar ve hosting firmaları yamayı eski sürüm numarasıyla uygulayabildiği için kesin bilgi için hosting firmanıza danışın.

### PHP sürümümü nasıl öğrenirim?

cPanel'de MultiPHP Yöneticisi veya PHP Sürümünü Seç ekranında PHP dalını görebilirsiniz. WordPress'te Araçlar, Site Sağlığı, Bilgi, Sunucu bölümünde tam sürüm yazar. En kesin bilgiyi hosting firmanız verebilir.

### Bir güvenlik eklentisi PHP2Shell'e karşı korur mu?

Hayır. Açık PHP katmanında, sitenin kodu çalışmadan önce tetiklenebildiği için WordPress eklentileri bu açığı kapatamaz. Tek tam çözüm PHP'nin güncellenmesidir. Cloudflare gibi güvenlik duvarları yalnızca geçici koruma sağlar.

### PHP 7.4 veya 8.1 kullanıyorum, ne yapmalıyım?

Bu sürümlerin resmi desteği bitti ve PHP ekibi bunlar için normal bir güncelleme yayımlamadı. Sitenizin yedeğini alıp test ederek PHP 8.3 veya 8.4'e geçmeniz önerilir. Geçiş mümkün değilse hosting firmanıza yamalı bir paket sunup sunmadığını sorun.

## Kaynaklar

- [Wiz Research — PHP2Shell: Critical RCE vulnerabilities in PHP](https://www.wiz.io/blog/php2shell-php-rce)
- [CERT-EU — Security Advisory 2026-018: Critical Vulnerabilities in PHP](https://cert.europa.eu/publications/security-advisories/2026-018/)
- [Help Net Security — PHP2Shell: Critical PHP vulnerabilities patched (21 Ekim 2026)](https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/)
- [Qualys — PHP announces critical security release for two vulnerabilities](https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities)
- [Patchstack — Major security alert: PHP vulnerable to critical RCE](https://patchstack.com/articles/php-major-vulnerability-alert-10-2026/)
- [InMotion Hosting — PHP critical security release, October 2026](https://www.inmotionhosting.com/support/news/php-critical-security-release-october-2026/)
- [MassiveGrid — How to patch PHP for CVE-2026-109618 and CVE-2026-109619](https://massivegrid.com/blog/how-to-patch-php-cve-2026-109618-109619-every-platform/)
- [DEV Community — PHP2Shell checker: what 650 checks showed](https://dev.to/kyleclouthier/i-built-a-php2shell-checker-the-morning-the-patch-dropped-heres-what-650-checks-showed-3e4j)