Son günlerde PHP ekosistemini ciddi şekilde etkileyen **PHP2Shell** olarak adlandırılan iki kritik güvenlik açığı konuşuluyor: **CVE-2026-109618** ve **CVE-2026-109619**. Bu açıklar WordPress, Laravel, Drupal gibi uygulamaların kendisinde değil, doğrudan **PHP interpreter’ında** bulunuyor. Bu nedenle sadece WordPress çekirdeğini, tema ve eklentileri güncellemek tek başına yeterli değil; sunucudaki **PHP sürümünün de güncellenmesi** gerekiyor.
PHP güvenlik ekibi, bu iki açık için acil yamalar yayınladı. İki açık da uzaktan kod çalıştırma (RCE) riski taşıyor ve CVSS v4.0 ölçeğinde **9.2 Critical** olarak değerlendiriliyor.[1][2]
## Açıklar Ne Yapıyor?
**CVE-2026-109618**, bellek sınırı aşımı sonrasında eksik başlatılmış bellek bölgesinin kullanılmasına dayanıyor. Saldırgan, özel hazırlanmış bir HTTP isteğiyle PHP işleminin bellek yönetimini bozabiliyor ve sistemde komut çalıştırabiliyor.
**CVE-2026-109619** ise PHP worker process’inde kalan geçersiz ya da eski global state ve use-after-free durumu üzerinden tetiklenebiliyor. Yani önceki isteklerden arta kalan durum, sonraki istekte kötüye kullanılabiliyor.
En kritik nokta şu: Saldırı, uygulamanın kendi kodu çalışmaya başlamadan önce tetiklenebiliyor. Bu yüzden uygulama tarafındaki login kontrolü, WAF kuralı ya da CMS güvenlik eklentisi tek başına tam koruma sağlamayabiliyor.[1][3]
## Kimler Etkileniyor?
Aşağıdaki kurulumlar risk altında:
- Apache `mod_php` ile çalışan sunucular
- PHP-FPM kullanan Nginx/Apache kurulumları
- IIS üzerinde FastCGI ile çalışan PHP
- `php-cgi` tabanlı hosting yapılandırmaları
- FrankenPHP ve LiteSpeed gibi PHP çalıştıran web sunucuları
- Docker, Kubernetes veya benzeri container ortamlarında çalışan PHP imajları
Yani yalnızca VPS/dedicated sunucu sahipleri değil; paylaşımlı hosting kullanıyorsanız da hosting sağlayıcınızın PHP sürümünü kontrol etmeniz gerekiyor.[2]
## Etkilenen ve Yamalı PHP Sürümleri
| PHP Dalı | Yamalı Sürüm |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 ve altı | Resmî upstream yama yok; dağıtım/vendor backport’u kontrol edilmeli |
PHP 8.1 ve daha eski sürümleri kullananlar için resmî PHP projesinden doğrudan yama yayınlanmadı. Bu durumda dağıtımın LTS güvenlik güncellemesi olup olmadığı kontrol edilmeli; yoksa PHP sürümü yükseltilmeli ya da servis internete açıkken riskli kabul edilmelidir.[2][3]
## Sunucunuzda PHP Sürümünü Nasıl Kontrol Edersiniz?
SSH erişiminiz varsa:
```bash
php -v
```
Windows/IIS ortamında PowerShell ile:
```powershell
& 'C
hpphp.exe' -v```
Paylaşımlı hosting kullanıyorsanız cPanel, Plesk veya hosting panelinizdeki **PHP Selector / PHP Version** bölümünden aktif PHP sürümünü görebilirsiniz.
Ayrıca web root’unuza geçici olarak şu içeriğe sahip bir `phpinfo.php` dosyası oluşturup tarayıcıdan kontrol edebilirsiniz:
```php
<?php
phpinfo();
```
**Önemli
* Kontrol bittikten sonra bu dosyayı mutlaka silin. `phpinfo()` çıktısı sunucu yapılandırmanız hakkında hassas bilgi içerir.## Acil Olarak Yapılması Gerekenler
### 1. PHP’yi Yamalı Sürüme Güncelleyin
Kalıcı çözüm, PHP’yi yukarıdaki tablodaki yamalı sürümlerden birine çıkarmaktır:
```text
PHP 8.2.35
PHP 8.3.36
PHP 8.4.27
PHP 8.5.12
```
Ubuntu/Debian üzerinde:
```bash
sudo apt update && sudo apt upgrade
```
CentOS/RHEL/AlmaLinux/Rocky Linux üzerinde:
```bash
sudo dnf update php*
```
Docker kullanıyorsanız sadece container’ı yeniden başlatmak yetmez. Base image’ı güncelleyip uygulamayı yeniden build etmeniz gerekir:
```bash
docker compose build --no-cache
docker compose up -d
```
### 2. PHP-FPM / Apache / IIS Worker’larını Yeniden Başlatın
PHP güncellemesi sonrası eski worker süreçleri bellekte kalabilir. Bu yüzden servisi yeniden başlatın.
Nginx + PHP-FPM:
```bash
sudo systemctl restart php8.3-fpm
sudo systemctl restart nginx
```
Apache:
```bash
sudo systemctl restart apache2
```
IIS üzerinde PowerShell:
```powershell
Import-Module WebAdministration
Get-ChildItem IIS:AppPools | ForEach-Object {
Restart-WebAppPool -Name $_.Name
}
```
### 3. Geçici Önlem: `session.upload_progress` Kapatın
PHP yamasını hemen uygulayamıyorsanız, `php.ini` içinde şu ayarı kapatın:
```ini
session.upload_progress.enabled = 0
```
Ardından PHP-FPM, Apache veya IIS uygulama havuzunu yeniden başlatın.
### 4. Bellek ve Yükleme Ayarlarını Gözden Geçirin
CVE-2026-109618 için bilinen saldırı senaryosunda şu koşul önemli:
```text
memory_limit < 4 x post_max_size
```
Örneğin `post_max_size=64M` iken `memory_limit=128M` ise bu koşul sağlanmış olur. Geçici olarak `post_max_size` değerini düşürmek ve `memory_limit` yapılandırmasını gözden geçirmek faydalı olabilir. Ancak bunlar kalıcı çözüm değildir; PHP güncellemesi şarttır.[1][2]
## Saldırı Belirtileri Neler Olabilir?
Loglarınızda şu tür işaretler varsa dikkatli olun:
- PHP worker süreçlerinin `cmd.exe`, `powershell.exe`, `curl`, `wget`, `certutil` gibi süreçleri başlatması
- `uploads`, `tmp`, `cache` veya web root içinde açıklanamayan yeni `.php` dosyaları
- Aşağıdaki gibi, uygulama kodu çalışmadan oluşan bellek hataları:
```text
PHP Fatal error: Allowed memory size of ... bytes exhausted ... in Unknown on line 0
```
`in Unknown on line 0` ifadesi, hatanın uygulama dosyanızda değil, PHP’nin istek işleme sürecinin erken aşamasında oluştuğuna işaret edebilir.[1][3]
## WordPress / Laravel Kullanıcıları İçin Not
WordPress, Laravel, Symfony, Drupal gibi uygulamaların güncel olması elbette önemli. Ancak bu açık PHP çekirdeğinde olduğu için:
- WordPress çekirdeği güncel olsa bile risk devam edebilir.
- Güvenlik eklentisi kurulu olsa bile tam koruma garanti edilmez.
- Hosting panelinden PHP sürümü değiştirilebiliyorsa, yamalı sürüme geçmek en hızlı çözümdür.
- Hosting sağlayıcınız güncelleme yapmıyorsa destek talebi açın ve PHP sürümünün yamalı olup olmadığını sorun.
## Özet Kontrol Listesi
- [ ] Aktif PHP sürümünü kontrol et
- [ ] PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 sürümlerinden birine geç
- [ ] PHP-FPM, Apache veya IIS uygulama havuzlarını yeniden başlat
- [ ] `session.upload_progress.enabled = 0` ayarını değerlendir
- [ ] `memory_limit` ve `post_max_size` yapılandırmasını kontrol et
- [ ] Web root, uploads ve tmp klasörlerinde şüpheli `.php` dosyası var mı bak
- [ ] Web sunucusu ve PHP error loglarını incele
- [ ] Container kullanıyorsanız base image’ı güncelle ve yeniden build et
- [ ] Paylaşımlı hosting kullanıyorsan hosting sağlayıcına PHP yamasını sor
## Kaynaklar
- BleepingComputer — PHP ships emergency patches for critical PHP2Shell flaws: [https://www.bleepingcomputer.com/new...p2shell-flaws/)[2]
- CrowdStrike — PHP RCE zero-day koruması: [https://www.crowdstrike.com/en-us/bl...rce-zero-days/)[1]
- Kaspersky — PHP2Shell: How to Protect Your Server: [https://www.kaspersky.com/blog/cve-2...ilities/56583/)
- Datadog Security Labs — PHP2Shell detection, analysis and remediation: [https://securitylabs.datadoghq.com/a...ilities-in-php)[3]
- Check Point — PHP2Shell: What We Know About the Leaked Critical PHP Vulnerabilities: [https://blog.checkpoint.com/security...ve-2026-109619)[4]
***
**Not
* Bu başlık yalnızca sunucu güvenliği, yama ve tespit amaçlı hazırlanmıştır. Sahibi olmadığınız ya da yazılı izin almadığınız sistemlerde exploit/PoC denemesi yapmayın.Atıflar:
[1] CrowdStrike Protects Customers from Threats Delivered via ... https://www.crowdstrike.com/en-us/bl...rce-zero-days/
[2] www.bleepingcomputer.com › news › securityPHP ships emergency patches for critical PHP2Shell flaws https://www.bleepingcomputer.com/new...p2shell-flaws/
[3] PHP2Shell - Critical vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619): detection, analysis, and remediation https://securitylabs.datadoghq.com/a...ilities-in-php
[4] blog.checkpoint.com · security · php2shell-what-wePatch Now: php2shell: What We Know About the Leaked Critical ... https://blog.checkpoint.com/security...ve-2026-109619
