Merhaba arkadaşlar,

PHP çekirdeğinde edilen ve **PHP2Shell** olarak adlandırılan iki kritik RCE açığı hakkında kısa bir başlık açmak istedim. WordPress, Laravel, Drupal gibi uygulamaların kendilerinde değil, **PHP interpreter’ının kendisinde** bulunan bu açıklar nedeniyle yalnızca CMS/framework güncellemek yeterli değil; PHP çalışma zamanını güncellemek gerekiyor.[1][2]

## Özet

- **CVE-2026-109618 * Bellek sınırı aşımı sonrası eksik başlatılmış bellek üzerinden RCE.
- **CVE-2026-109619 * Worker process’te kalan geçersiz/eski global state ve use-after-free üzerinden RCE.
- İkisi de **CVSS v4.0 9.2 Critical** olarak işaretlendi.[1]
- Saldırı, uygulama kodu çalışmadan önce tetiklenebiliyor; bu nedenle login, WAF, uygulama tarafı doğrulama vb. tek başına tam koruma sağlamıyor.[2]
- Apache `mod_php`, PHP-FPM, `php-cgi`, FrankenPHP ve LiteSpeed gibi web isteklerini işleyen kurulumlar etki kapsamında.[1]

## Etkilenen / Yamalı Sürümler

| PHP dalı | Yamalı sürüm |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1 ve altı | Upstream resmî yama yok; dağıtım/LTS vendor backport’u kontrol edin veya yükseltin. [1][2] |

## PowerShell ile Hızlı Envanter

Windows üzerinde `php.exe`, `php-cgi.exe` veya IIS/FastCGI üzerinden çalışan PHP kurulumlarını tespit etmek için şu script’i kullanabilirsiniz:

```powershell
$phpPaths = @()

$phpPaths += Get-ChildItem -Path 'C:' -Filter 'php.exe' -Recurse -ErrorAction SilentlyContinue |
Select-Object -ExpandProperty FullName

$phpPaths += Get-ChildItem -Path 'C:' -Filter 'php-cgi.exe' -Recurse -ErrorAction SilentlyContinue |
Select-Object -ExpandProperty FullName

$phpPaths = $phpPaths | Sort-Object -Unique

foreach ($php in $phpPaths) {
try {
$version = & $php -v 2>$null | Select-Object -First 1
[PSCustomObject]@{
Path = $php
Version = $version
}
}
catch {
[PSCustomObject]@{
Path = $php
Version = 'Sürüm alınamadı'
}
}
}
```

Tüm diskte tarama uzun sürebilir; önce `C:Program Files`, `Chp`, `C:inetpub`, `C:xampp`, `C:wamp64`, `C:laragon` gibi olası lokasyonları tarayabilirsiniz.

## PowerShell ile Yapılandırma Kontrolü

Aşağıdaki komut, CLI tarafındaki `memory_limit`, `post_max_size` ve `session.upload_progress.enabled` değerlerini gösterir. Ancak dikkat: **CLI ayarları, IIS/FastCGI veya Apache mod_php tarafından kullanılan ayarlarla farklı olabilir.**[2]

```powershell
$php = 'Chpphp.exe' # Kendi php.exe yolunuzu yazın

& $php -i | Select-String -Pattern '^(memory_limit|post_max_size|upload_max_filesize| session.upload_progress.enabled|Loaded Configuration File)'
```

Özellikle şu koşul, CVE-2026-109618 için bilinen saldırı yolunu kolaylaştırabiliyor:

```text
memory_limit < 4 x post_max_size
```

Örneğin `post_max_size=64M` ve `memory_limit=128M` kombinasyonu bu koşulu sağlıyor.

## Geçici Önlemler

Önemli: Bunlar **tam çözüm değil**; resmî PHP yaması tek kalıcı çözüm.[1][2]

### 1. `session.upload_progress` kapatma

`php.ini` içinde:

```ini
session.upload_progress.enabled = 0
```

IIS/FastCGI ortamında ilgili `php.ini` dosyasını düzenledikten sonra IIS uygulama havuzunu veya web sunucusunu yeniden başlatın.

### 2. `memory_limit` yönetimi

CVE-2026-109618’e karşı PHP ekibinin önerdiği geçici yaklaşım, `memory_limit=-1` ayarı ve düşük `post_max_size` kullanımı. Ancak bu, sistem belleği tükenmesine karşı ek limitler olmadan tek başına yeterli değil.[1][2]

```ini
memory_limit = -1
post_max_size = 8M
```

Dosya yükleme gerekiyorsa:

```ini
post_max_size = 32M
```

### 3. PHP 8.5 kullanıyorsanız

```ini
fatal_error_backtraces = 0
```

Bu ayar yalnızca CVE-2026-109619 için doğrulanmış backtrace tetikleyicisini kapatır; diğer yolları kapatmaz.[1][2]

## PowerShell ile IIS Uygulama Havuzu Restart

PHP güncellemesinden sonra eski worker’ların bellekte kalmasını önlemek için restart şart:

```powershell
Import-Module WebAdministration

Get-ChildItem IIS:AppPools | ForEach-Object {
$poolName = $_.Name
Write-Host "Restarting application pool: $poolName"
Restart-WebAppPool -Name $poolName
}
```

Ya da yalnızca PHP kullanan belirli bir pool için:

```powershell
Restart-WebAppPool -Name 'DefaultAppPool'
```

## Tespit / Log İpuçları

Şu işaretleri araştırmaya değer:

- PHP worker süreçlerinin `cmd.exe`, `powershell.exe`, `curl`, `wget`, `certutil`, `nc` gibi süreçleri başlatması.[3]
- Web root, `tmp`, `uploads`, `cache` klasörlerinde yeni `.php` dosyaları.
- Aşağıdaki türde, script başlamadan önce 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 kodunda değil, PHP’nin istek başlatma aşamasında oluştuğuna işaret edebiliyor.[2]

## Ne Yapmalı?

1. İnternete açık tüm PHP sunucularını envanterleyin.
2. PHP’yi resmî yamalı sürüme çıkarın: **8.2.35 / 8.3.36 / 8.4.27 / 8.5.12**.[1][2]
3. Container kullanıyorsanız base image’ı güncelleyip image’ı yeniden build edin.
4. IIS uygulama havuzlarını veya Apache/PHP-FPM worker’larını yeniden başlatın.
5. Eski PHP sürümlerinde vendor backport olup olmadığını kontrol edin; yoksa servisi internete kapatın ya da erişimi kısıtlayın.[1]
6. Şüpheli aktivite görürseniz sunucuyu izole edin, logları saklayın ve sunucudaki secret/token’ları rotate etmeyi değerlendirin.[4]

***

**Not * Bu konu yalnızca tespit, yama ve savunma amaçlıdır. Sahibi olmadığınız ya da açık yazılı izin almadığınız sistemlerde test/exploit denemesi yapmayın.

Kaynaklar: PHP acil yama duyurusu, CrowdStrike/Check Point/Datadog analizleri ve Kaspersky önerileri.[1][2]

Atıflar:
[1] www.bleepingcomputer.com › news › securityPHP ships emergency patches for critical PHP2Shell flaws https://www.bleepingcomputer.com/new...p2shell-flaws/
[2] PHP2Shell - Critical vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619): detection, analysis, and remediation https://securitylabs.datadoghq.com/a...ilities-in-php
[3] php2shell-CVE-2026-109618-CVE-2026-109619-PoC/README.md at main · eness/php2shell-CVE-2026-109618-CVE-2026-109619-PoC https://github.com/eness/php2shell-C...main/README.md
[4] PHP2Shell explained: CVE-2026-109618 and CVE-2026-109619 https://safeguard.sh/resources/blog/...9619-explained