PHP2Shell Açığı: Ubuntu ve Apache Sunucular İçin Adım Adım Güvenlik Rehberi

Bilgilerin kontrol tarihi: 22 Ekim 2026

PHP2Shell hakkında bir güvenlik duyurusu gördüğünüzde yapılacak ilk iş, sunucunuzda hangi PHP sürümünün gerçekten çalıştığını belirlemektir. Ardından kullandığınız paket kaynağında düzeltmenin sunulup sunulmadığını kontrol etmeli, yamalı paketi kurmalı ve PHP kodunu bellekte tutan servisleri yeniden başlatmalısınız.

Bu rehber; Ubuntu üzerinde APT ile kurulmuş PHP ve Apache kullanan sunucular için hazırlanmıştır. Docker, hosting paneli, kaynak koddan derlenmiş PHP veya farklı Linux dağıtımları kullanan sistemlerde güncelleme yöntemi değişebilir. İşleme başlamadan önce kullanılabilir bir yedeğiniz olduğundan emin olun ve kısa süreli hizmet kesintisi ihtimalini göz önünde bulundurun.

PHP2Shell nedir?

PHP2Shell, PHP çekirdeğinde tespit edilen iki kritik güvenlik açığı için kullanılan isimdir. Açıklar, uygun koşullarda kimlik doğrulama gerektirmeden uzaktan kod çalıştırılmasına yol açabilir. PHP projesi, ilgili düzeltmeleri 21 Ekim 2026 tarihinde yayımladı.

Güvenlik açığı Temel sorun CVE-2026-109618 Bellek yetersizliği sırasında yarım kalmış iç verilerin geçerli kabul edilmesi CVE-2026-109619 Bellek serbest bırakıldıktan sonra sonraki isteğin eski duruma erişebilmesi

Başarılı bir saldırı, genellikle web işçisinin yetkileriyle kod çalıştırılmasına neden olur. Bu durum doğrudan root erişimi anlamına gelmese de uygulamanın erişebildiği veritabanı parolaları, API anahtarları, .env dosyaları, kullanıcı verileri ve diğer sırlar açısından ciddi risk oluşturur.

Hangi sistemler etkileniyor?

Web isteği işleyen PHP kurulumlarının tamamı dikkatle değerlendirilmelidir. Apache üzerinde mod_php kullanılıyorsa risk özellikle önemlidir; doğrulanmış saldırı yollarından biri uygulama kodu çalışmaya başlamadan önce tetiklenebilir. PHP-FPM kullanmak da güncelleme gereksinimini ortadan kaldırmaz.

Dolayısıyla Laravel, Symfony, WordPress veya başka bir PHP çatısı kullanmanız güvenlik sorumluluğunu değiştirmez. Laravel bakım modu veya uygulama içinden eklenen bir koruma, PHP çalışma katmanından önce tetiklenebilen bir saldırı yolunu engelleyemeyebilir. Yama hemen uygulanamıyorsa PHP’ye yönelik dış erişimi sınırlandırmayı veya hizmeti geçici olarak kapatmayı değerlendirin.

Hangi PHP sürümüne geçmelisiniz?

Aşağıdaki tabloda, açıkları gideren ilk resmi PHP sürümleri yer alır. Mevcut dalınız için daha yeni bir güvenlik sürümü varsa her zaman onu tercih edin.

PHP dalı İlk yamalı resmi sürüm PHP 8.2 8.2.35 PHP 8.3 8.3.36 PHP 8.4 8.4.27 PHP 8.5 8.5.12

Ancak Ubuntu gibi dağıtımlar, güvenlik düzeltmelerini mevcut paket sürümüne geri taşıyabilir. Bu nedenle yalnızca php -v çıktısındaki kısa sürüm numarasına bakarak paketin güvensiz olduğu sonucuna varmayın. Örneğin Ubuntu’nun resmi paketlerinde daha eski görünen bir sürüm numarası, ilgili CVE düzeltmelerini içerebilir. Tam paket sürümünü ve paket kaynağını kontrol etmek gerekir.

1. Kurulu PHP paketlerini belirleyin

Önce komut satırında çalışan PHP sürümünü kontrol edin:

php -v

Bu komut yalnızca CLI ortamındaki PHP sürümünü gösterir. Apache’nin aynı sürümü kullandığını tek başına kanıtlamaz. Kurulu paketlerin envanterini almak için aşağıdaki komutu çalıştırın:

dpkg-query -W \
  -f='${db:Status-Status}\t${binary:Package}\t${Version}\n' \
  'php*' 'libapache2-mod-php*' |
awk '$1 == "installed"'

Bu çıktı sayesinde kurulu PHP dallarını, uzantıları, FPM paketlerini ve Apache modüllerini birlikte görebilirsiniz. Sunucuda birden fazla PHP sürümü bulunabileceğini unutmayın.

2. Apache’nin hangi PHP çalışma biçimini kullandığını kontrol edin

Apache yüklü modüllerini görmek için:

sudo apache2ctl -M

Çıktıda php_module bulunuyorsa Apache, mod_php kullanıyor olabilir. Sürüm dalını öğrenmek için:

grep -RnE 'LoadModule.*php' /etc/apache2/mods-enabled

Örneğin libphp8.4.so sonucunu görmeniz Apache’nin PHP 8.4 modülünü yüklediğini gösterir. Fakat bunun hangi paket revizyonuna ait olduğunu ayrıca kontrol etmeniz gerekir.

PHP-FPM servislerini ve Apache’nin FPM soketlerine yönlendirilip yönlendirilmediğini incelemek için:

systemctl list-units --type=service --all 'php*-fpm.service'

grep -RnE 'SetHandler|ProxyPassMatch|php.*fpm' \
  /etc/apache2/sites-enabled /etc/apache2/conf-enabled

Farklı sitelerin farklı PHP-FPM sürümlerini kullanması mümkündür. Bu nedenle yalnızca varsayılan domaini değil, sunucudaki tüm etkin site yapılandırmalarını değerlendirin.

3. Depodaki güncel paketi inceleyin

Önce APT paket indeksini güncelleyin:

sudo apt update

Ardından örneğin PHP 8.4 paketlerinin kurulu ve aday sürümlerini kontrol edin:

apt-cache policy \
  php8.4-cli php8.4-common php8.4-fpm libapache2-mod-php8.4

apt-mark showhold

Installed alanı kurulu sürümü, Candidate alanı ise APT yapılandırmanıza göre kurulabilecek sürümü gösterir. Candidate sürümünün yamalı olması, güncellemenin henüz uygulandığı anlamına gelmez. Ayrıca apt update yalnızca paket bilgisini yeniler; paketleri yükseltmez.

4. Kurulu PHP paketlerini güncelleyin

Önce hangi PHP 8.2 ve PHP 8.4 paketlerinin kurulu olduğunu listeleyin:

mapfile -t php_packages < <(
  dpkg-query -W -f='${db:Status-Status} ${binary:Package}\n' \
    'php8.2*' 'php8.4*' \
    'libapache2-mod-php8.2' 'libapache2-mod-php8.4' |
  awk '$1 == "installed" {print $2}'
)

printf '%s\n' "${php_packages[@]}"

Listeyi dikkatle kontrol ettikten sonra önce simülasyon çalıştırın:

sudo apt-get --simulate --no-remove install --only-upgrade "${php_packages[@]}"

Beklenmedik paket kaldırma işlemi veya bağımlılık sorunu yoksa güncellemeyi başlatın:

sudo apt-get --no-remove install --only-upgrade "${php_packages[@]}"

Yalnızca php8.4-cli paketini güncellemek yeterli değildir. Apache modülü, PHP-FPM, ortak PHP paketleri ve kullanılan uzantılar da güncel olmalıdır. Yerel olarak değiştirilmiş yapılandırma dosyalarıyla ilgili bir soru gelirse farkları incelemeden varsayılan dosyaların üzerine yazmayın.

5. Apache ve PHP-FPM servislerini yeniden başlatın

Paket güncellemesi tamamlandığında eski süreçler belleklerinde önceki PHP kodunu çalıştırmaya devam edebilir. Bu nedenle servis yeniden başlatma adımı kritik önem taşır.

sudo apache2ctl configtest
sudo systemctl restart apache2

Yapılandırma testi Syntax OK sonucu veriyorsa Apache yeniden başlatılabilir. PHP 8.4 FPM kullanıyorsanız ilgili servisi de yenileyin:

sudo systemctl try-restart php8.4-fpm

Farklı bir PHP dalı kullanıyorsanız servis adını buna göre değiştirin. Laravel Horizon, queue worker, Octane, Supervisor veya systemd üzerinden çalışan uzun ömürlü PHP süreçlerini de uygulamanızın çalışma biçimine uygun olarak yeniden başlatın.

6. Güncellemeyi doğrulayın

Güncellemeden sonra hem paketlerin hem de servislerin durumunu kontrol edin:

php -v

dpkg-query -W \
  -f='${db:Status-Status}\t${binary:Package}\t${Version}\n' \
  php8.4-cli php8.4-common php8.4-fpm libapache2-mod-php8.4

systemctl is-active apache2
systemctl --failed

Doğrulama üç aşamadan oluşmalıdır: doğru paket sürümünün kurulu olması, sitenin doğru PHP ortamına yönlenmesi ve ilgili servislerin yeniden başlatılmış olması. Herkese açık bir phpinfo() sayfası bırakmayın. Gerekirse yalnızca yöneticilerin erişebildiği geçici bir tanılama yöntemi kullanın ve işlem tamamlandığında kaldırın.

Yama sonrasında ihlal belirtilerini inceleyin

Yama, güvenlik açığını kapatır; ancak daha önce gerçekleşmiş olası bir saldırıyı geri almaz. Apache ve uygulama kayıtlarını incelemek iyi bir başlangıçtır:

sudo journalctl -u apache2 --since "24 hours ago" --no-pager -n 200
sudo tail -n 200 /var/log/apache2/error.log

Beklenmeyen çökmeler, bellek hataları, değiştirilmiş PHP dosyaları, yeni cron görevleri, tanımadığınız SSH anahtarları ve olağandışı dış bağlantılar incelenmelidir. Loglarda hata bulunmaması sistemin kesin olarak güvenli olduğunu göstermez. İhlal şüphesi varsa sistemi izole edin, mümkünse log ve disk kanıtlarını koruyun, ardından erişilmiş olabilecek parolaları ve API anahtarlarını yenileyin.

Sonuç

PHP2Shell gibi çekirdek seviyesindeki açıklar, uygulama bağımlılıklarını güncellemekten daha geniş bir müdahale gerektirir. Composer paketlerini güncellemek tek başına yeterli değildir; web isteklerini işleyen PHP paketleri, Apache modülleri, FPM servisleri ve uzun süre çalışan işçi süreçleri birlikte ele alınmalıdır.

Gelecekteki güvenlik duyurularına daha hızlı yanıt verebilmek için her sitenin PHP sürümünü, paket kaynağını, Apache veya FPM kullanımını, sorumlu servislerini ve son güncelleme tarihini kayıt altında tutun.

Kaynaklar

• PHP projesi: 21 Ekim 2026 kritik güvenlik duyurusu
• CVE-2026-109618 güvenlik duyurusu
• CVE-2026-109619 güvenlik duyurusu
• PHP Foundation güvenlik değerlendirmesi
• NCSC: PHP’yi etkileyen kritik güvenlik sorunu
• Ubuntu USN-8948-1: PHP güvenlik açıkları