PHP'de kritik güvenlik açığı php2shell: hangi sürüme güncellemelisin?

PHP, 21 Ekim 2026'da iki kritik güvenlik açığını kapatan acil sürümler yayınladı. Açıklar, internetten gelen tek bir istekle, hiçbir kullanıcı adı ya da şifre gerekmeden sunucuda kod çalıştırmaya kadar gidebiliyor. Birleşik Krallık'ın siber güvenlik merkezi NCSC aynı gün "hemen harekete geçin" diye uyarı yayınladı. Saldırı girişimleri ise yamadan önce başlamıştı.

PHP ile bir proje yayınladıysan, kulübünün WordPress sitesini sen kuruyorsan ya da stajda PHP çalıştıran bir sunucuya erişimin varsa bu yazı senin için. Önce ne olduğunu, sonra yapman gerekenleri sırayla anlatıyoruz.

Kısaca: ne yapmalısın?

• PHP'yi kullandığın dalın yamalı sürümüne güncelle: 8.5.12, 8.4.27, 8.3.36 ya da 8.2.35.
• Güncellemeden sonra PHP-FPM'i ya da Apache'yi yeniden başlat. Eski süreçler eski kodla çalışmaya devam eder.
• Hemen güncelleyemiyorsan aşağıdaki geçici önlemleri uygula. Bunlar tam çözüm değil.
• Sunucun 17 Ekim'den beri internete açıksa beklenmedik dosya ve kullanıcılara bak.

Ne oldu?

PHP projesi iki açık için ayrı güvenlik bildirimleri yayınladı. İkisi de CVSS 4.0 ölçeğinde 9.2, yani kritik:

• CVE-2026-109618, "OOM bozulmasıyla uzaktan kod çalıştırma": PHP bir istek sırasında belleği tükendiğinde (out of memory, OOM) işi yarıda kesip çıkıyor. Bildirime göre bu çıkış, isteğin henüz tam hazırlanmamış verisini geçersiz bırakabiliyor; istek kapanırken bu bozuk veri okunuyor ve saldırgan bunu kod çalıştırmaya çevirebiliyor.
• CVE-2026-109619, "bayat genel durumla uzaktan kod çalıştırma": Aynı çalışan süreç (worker) birden çok isteği sırayla karşılıyor. İkinci bildirime göre bir isteğe ait bazı durum bilgileri, bellekleri serbest bırakıldıktan sonra da süreçte kalabiliyor. Bir sonraki istek bunları kullanınca ortaya klasik bir "use-after-free" hatası çıkıyor.

Saldırganın bellek taşmasını tetiklemek için özel bir şeye ihtiyacı yok. Bildirimler, çok parçalı (multipart) form gönderimlerinin PHP içinde ağdan göründüğünden çok daha fazla bellek harcatabildiğini anlatıyor. Varsayılan olarak açık gelen oturum yükleme ilerlemesi (session.upload_progress) özelliği de doğrulanmış saldırı yollarından biri. Yani uygulamanın kodu hiç çalışmadan, sıradan bir POST isteğiyle risk oluşuyor.

Açığa verilen ad olan php2shell, Tenable'ın SSS yazısına göre Calif.io'dan araştırmacının çalışan saldırı kodunu gösteren videodan geliyor.

Dört günde ne oldu?

• 17 Ekim: Amazon, açıklamadan dört gün önce tuzak sunucularında (honeypot) bir saldırı girişimi gördüğünü söylüyor. Bu yüzden incelemeye 21 Ekim'den değil, 17 Ekim'den başlamanı öneriyor.
• 20 Ekim: CVE kimlikleri Hacker News'te ve sosyal medyada dolaşmaya başladı. PHP, 22 Ekim'e planladığı yamayı bir gün öne çekti. Sızan iddia CVSS 10 diyordu; PHP'nin kendi puanı 9.2.
• 21 Ekim, 14.00 UTC (17.00 TSİ): Yamalı sürümler yayınlandı. NCSC, Hollanda'nın NCSC'si ve CERT-EU uyarılar yayınladı.
• Aynı gün: watchTowr ve Cloudflare saldırı girişimleri gördüklerini bildirdi. The Hacker News'in güncellemesine göre belirli bir sunucuya başarılı bir sızma henüz doğrulanmış değil. Ama "henüz doğrulanmadı", "olmadı" demek değil.

Kimler etkileniyor?

Kısa cevap: web isteği karşılayan her PHP kurulumu. Hollanda NCSC'sinin php2shell sayfasına göre PHP-FPM, Apache ile mod_php, php-cgi, FrankenPHP ve LiteSpeed risk altında. PHP en yüksek riski Apache + mod_php için görüyor; orada çalışan bir saldırı, uygulama kodu başlamadan tetiklenebiliyor.

Ölçek de büyük. Tenable'ın aktardığına göre sunucu tarafı dili bilinen web sitelerinin yaklaşık yüzde 69'u PHP kullanıyor ve internete açık 1,9 milyondan fazla sunucu PHP çalıştırıyor.

Bir de görünmeyen PHP'ler var. Modemler, ağ cihazları ve yönetim panelleri de içlerinde PHP taşıyabiliyor; bunları sen güncelleyemezsin, üreticinin yamasını beklemen gerekir. NCSC-NL, PHP'ye bağımlı ürünlerin bir listesini aynı depoda tutuyor.

WordPress'i ya da Laravel'i güncellemek PHP'yi güncellemez. Açık, uygulamanın altındaki PHP'nin kendisinde. Onu sunucun, hosting firman ya da kullandığın Docker imajı getiriyor.

Hangi PHP sürümü güvenli?

• PHP 8.5: 8.5.12 ve sonrası
• PHP 8.4: 8.4.27 ve sonrası
• PHP 8.3: 8.3.36 ve sonrası
• PHP 8.2: 8.2.35 ve sonrası
• PHP 7.4, 8.0 ve 8.1: Resmî yeni sürüm yok. PHP, kaynaktan derleyenler için asgari yamalar yayınladı; Linux dağıtımları ve uzun süreli destek veren firmalar kendi paketlerini çıkarabilir. Asıl çözüm, desteklenen bir dala geçmek.
• PHP 7.3 ve öncesi: Yama yok. Bu sürümleri internete açık bir sunucuda çalıştırmaya devam etmemelisin.

1. Sunucundaki PHP sürümünü öğren

Komut satırına erişimin varsa:

php -v

Dikkat: Komut satırındaki PHP ile web isteklerini karşılayan PHP aynı olmak zorunda değil. Nginx kullanıyorsan PHP-FPM'in sürümüne ayrıca bak:

php-fpm8.3 -v          # dağıtıma göre: php-fpm -v
systemctl list-units 'php*-fpm*'

Komut satırın yoksa ya da web'deki sürümden emin olmak istiyorsan sitenin köküne geçici bir dosya koyup tarayıcıdan aç:

<?php echo PHP_VERSION;

Sürümü gördükten sonra dosyayı hemen sil. phpinfo() sayfasını açık unutmak, saldırganlara sunucunun haritasını vermek demek.

WordPress kullanıyorsan panelde Araçlar → Site Sağlığı → Bilgi → Sunucu bölümü PHP sürümünü gösteriyor.

Dağıtım paketlerinde sürüm numarası yanıltabilir

Debian ve Ubuntu gibi dağıtımlar yamayı çoğu zaman eski sürüm numarasının üstüne uyguluyor. Yani php -v hâlâ 8.2.x gösterirken paket yamalı olabilir. Debian'ın önerisi, sürüm numarasına değil paketin değişiklik kaydına bakmak:

apt changelog php8.2-fpm | grep -m1 CVE-2026-109618

Satır çıkıyorsa kurulu paket bu CVE için yamalı.

2. Güncelle ve yeniden başlat

Ortamına göre yol değişiyor.

Ubuntu ya da Debian sunucu:

sudo apt update
sudo apt upgrade
sudo systemctl restart php8.3-fpm   # mod_php kullanıyorsan: sudo systemctl restart apache2

Yeniden başlatmayı atlama. Çalışan PHP süreçleri, diskteki dosya değişse de eski kodla çalışmaya devam eder.

Docker: Yamalı sürümü içeren bir taban imaja geç (FROM php:8.5-fpm gibi bir etiket kullanıyorsan imajı yeniden çek) ve konteyneri yeniden oluştur:

docker compose build --pull
docker compose up -d
docker compose exec app php -v

app yerine kendi servisinin adını yaz. Docker'a yeniysen, bu hafta yayınlanacak Docker'a ilk adım yazımız imaj ve konteyner farkını anlatıyor.

Paylaşımlı hosting (cPanel, Plesk): Yama seviyesini hosting firması yönetiyor; panelden yalnızca dalı (8.3, 8.4 gibi) seçebiliyorsun. Firmanın duyurularına bak ya da destek talebi açıp "CVE-2026-109618 ve CVE-2026-109619 için PHP yamalandı mı?" diye sor. Hâlâ 7.x ya da 8.1 seçiliyse desteklenen bir dala geç; geçmeden önce sitenin yeni sürümde çalıştığını bir kopya üzerinde dene.

Kendi bilgisayarın: Homebrew'da brew upgrade php, XAMPP ya da Laragon kullanıyorsan yeni paketini bekle. Yerel geliştirme ortamı internete açık olmadığı için risk daha düşük, ama yerel sunucunu aynı ağdaki başkalarına açtıysan önce onu kapat.

Projeni nerede yayınladığını hatırlamıyorsan, ücretsiz yayın seçeneklerini karşılaştırdığımız yazıdaki liste iyi bir hatırlatıcı. Bundan sonra projenin gerektirdiği PHP sürümünü README'ne yazmak da güncellemeleri kolaylaştırır.

3. Hemen güncelleyemiyorsan: geçici önlemler

PHP'nin bildirimleri açık: tek güvenilir çözüm güncellemek. Aşağıdakiler yalnızca bilinen saldırı yollarını daraltıyor ve güncelleyene kadar zaman kazandırıyor.

Sunucu genelindeki php.ini dosyasına (site bazlı .htaccess ya da .user.ini ile değil, yönetici olarak):

; Doğrulanmış saldırı yollarından birini kapatır.
; Özelliği kullanmıyorsan yamadan sonra da kapalı kalabilir.
session.upload_progress.enabled = 0

; Yalnız PHP 8.5: doğrulanmış RCE yolunu kapatır.
fatal_error_backtraces = 0

Sonra bütün PHP süreçlerini yeniden başlat. Bunlara ek olarak:

• İstek boyutunu sınırla: post_max_size değerini makul tut, aynı sınırı Nginx'te client_max_body_size ile ya da yük dengeleyicide de uygula.
• Multipart'ı kes: Uygulaman dosya yüklemiyor ve form-data almıyorsa multipart/form-data isteklerini PHP'ye ulaşmadan engelle.
• Süreçleri yeniden kullanma: PHP-FPM'de pm.max_requests = 1, her isteği yeni bir süreçte karşılatarak bayat durumu taşıyan saldırıyı zorlaştırır. Performans maliyeti var; yük kaldırıyorsa geçici olarak kullan.

Bunların hiçbiri mümkün değilse NCSC'nin tavsiyesi net: sistemi yamalanana kadar internetten çekmeyi düşün.

4. 17 Ekim'den beri açıktaysan iz ara

İlk saldırı girişimi 17 Ekim'de görüldüğü için kontrolü o tarihten başlat:

• Web kök dizininde ve yükleme klasörlerinde 17 Ekim'den sonra oluşmuş beklenmedik .php dosyalarını ara:

sudo find /var/www -name "*.php" -newermt "2026-10-17" -type f

• WordPress'te tanımadığın yönetici hesapları, yeni eklentiler ya da değişmiş tema dosyaları var mı bak.
• Sunucuda tanımadığın cron görevleri, yeni SSH anahtarları ya da beklenmedik süreçler var mı kontrol et.
• Erişim kayıtlarında aynı adrese gelen, olağandışı büyük ya da yoğun multipart POST isteklerine bak.

Bir şey bulursan sistemi kapatmadan önce kayıtları sakla, şifreleri ve anahtarları değiştir. Bir kurumun sunucusuysa işi tek başına yürütme, sistemden sorumlu kişiye ya da güvenlik ekibine haber ver.

Sık sorulanlar

Laravel ya da WordPress'i güncellemem yeterli mi?

Hayır. Açık PHP'nin çekirdeğinde. Uygulamanı güncellemek iyi bir alışkanlık ama bu açığı kapatmaz; PHP'nin kendisini güncellemen gerekiyor.

Nginx ile PHP-FPM kullanıyorum, ben de etkileniyor muyum?

Evet. Bildirimlere göre en kolay saldırı mod_php'de doğrulandı, ama PHP-FPM de risk altında ve oturum yükleme ilerlemesi üzerinden saldırı FPM'de de doğrulandı.

Sitem Cloudflare arkasında, güvende miyim?

Cloudflare 21 Ekim'de güvenlik duvarı kuralları devreye aldı, ama saldırganların kuralları atlatmak için isteklerini değiştirdiğini de bildirdi. Bu kurallar güncellemenin yerini tutmaz, yalnızca zaman kazandırır.

PHP 7.4 kullanıyorum, ne yapmalıyım?

7.4 için resmî yeni sürüm yok. Kullandığın dağıtımın yamalı paket çıkarıp çıkarmadığına bak, ama asıl yapman gereken desteklenen bir dala, en azından 8.2'ye geçmek. Bu açık kapansa da 7.4 başka açıklar için yama almıyor.

Bu açığı kim buldu, neden bu kadar gecikti?

Açıklar birden fazla araştırmacı tarafından bildirildi; PHP'nin gönüllü çekirdek geliştiricileri yamayı aylarca süren bir çalışmayla hazırladı. PHP Vakfı, The Hacker News'in aktardığına göre bu gecikmeyi karar süreçlerindeki ve kaynaklarındaki "yapısal bir başarısızlık" olarak niteledi. İnternetin büyük kısmının birkaç gönüllünün emeğine dayandığını bir kez daha gösteren bir olay. Açık kaynağa nasıl katkı verebileceğini merak ediyorsan ilk PR rehberimiz iyi bir başlangıç.

Kaynaklar

• NCSC: Critical security issue affecting PHP
• PHP güvenlik bildirimi: RCE via OOM corruption (CVE-2026-109618)
• PHP güvenlik bildirimi: RCE via stale global state (CVE-2026-109619)
• NCSC-NL: php2shell bilgi deposu ve etkilenen ürün listesi
• Tenable: php2shell sık sorulan sorular
• PHP: desteklenen sürümler

Sunucunu birlikte kontrol etmek ister misin? re:make her pazar 15.00'te Buca'da buluşuyor; laptopunu al gel, üye olman gerekmiyor. Yeri ve saati burada.