PHP2Shell: Sunucunuzda Herkesin Kod Çalıştırmasına İzin Veren PHP Hatası (Hemen Yamalayın)

21 Ekim 2026'da PHP projesi, kimliği doğrulanmamış bir saldırganın bir web sunucusunda kod çalıştırmasına olanak tanıyan iki kritik hata için acil sürümler yayınladı. İkili, CVE-2026-109618 ve CVE-2026-109619 olarak izleniyor ve PHP2Shell adıyla anılıyor. Her ikisi de CVSS v4.0'da 9.2 puan alıyor, her ikisi de HTTP hizmeti veren her PHP kurulumunu vuruyor ve Amazon'un honeypot'ları, yama ortaya çıkmadan dört gün önce, 17 Ekim'de istismar girişimlerini kaydetti.

Sunucu tarafı dili bilinen web sitelerinin %69,3'ünde PHP çalışıyor (W3Techs). Bir PHP API'si, bir Laravel veya Symfony arka ucu, bir WordPress sitesi ya da içine PHP gömülü bir konteyner imajı işletiyorsanız, bu sizi ilgilendiriyor.

Bu rehber; hataların ne yaptığını, hangi sürümlerin etkilendiğini, sunucularınızı nasıl kontrol edeceğinizi, hafifletme önlemlerinin gerçekte ne kazandırdığını ve yamayı uyguladıktan sonra API'nizin hâlâ çalıştığını nasıl kanıtlayacağınızı kapsıyor.

TL;DR

PHP2Shell gerçekte nedir

Her iki hatanın da tek bir kök nedeni var: PHP, bir istek anormal şekilde sona erdiğinde belleğini bozuk bir durumda bırakabiliyor ve temizleme kodu sonrasında bu bozuk duruma güveniyor.

CVE-2026-109618: istek başlangıcı sırasında bellek yetersizliği kaynaklı bozulma. PHP, form verisini $_POST içine ayrıştırırken Zend motorunun hash tablosu kodu, yeni anahtarı ayırmadan önce giriş sayacını artırıyor. Datadog'un analizi bunu zend_hash.c içindeki _zend_hash_str_add_or_update_i() fonksiyonuna kadar izliyor. Eğer bu ayırma memory_limit sınırını aşarsa, PHP ölümcül bir hata fırlatıyor ve ekleme işlemini terk ediyor. Sayaç artık hiç kurulmamış bir bucket'ı da içeriyor. Kapanış sırasında PHP $_POST'u yok ediyor ve sayılan her bucket'ı gerçekmiş gibi işliyor.

API ekiplerini endişelendirmesi gereken kısım: bu, PHP istek gövdesini hâlâ ayrıştırırken, sizin kodunuzun tek bir satırı çalışmadan önce gerçekleşiyor. Kimlik doğrulama ara katmanınız, hız sınırlayıcınız ve girdi doğrulamanız bu isteği hiç görmez. Datadog bunu bir dosya yüklemesiyle değil, düz bir application/x-www-form-urlencoded gövdesiyle yeniden üretti.

CVE-2026-109619: istekler arası bayat küresel durum. PHP, worker genelinde istek başına belleği işaret eden bazı durumları tutuyor. Eğer ölümcül bir hata bu durumun sıfırlanmasını keserse veya geç bir kapanış teşhis işlemi temizlikten sonra bunu yeniden oluşturursa, aynı worker üzerindeki bir sonraki istek serbest bırakılmış belleği okur. PHP iki yolu doğruladı:

• Ölümcül hata geri izlemeleri (yalnızca PHP 8.5): sonraki bir istekteki bir yapılandırma teşhis işlemi, geriye kalan geri izleme durumunu okur. mod_php üzerinde komut çalıştırma doğrulandı.
• Yükleme işleme: ölümcül bir hatanın ardından oturum yükleme ilerlemesi, sonraki bir yükleme için durum bırakabilir. Yükleme ilerlemesi varsayılan olarak açıktır ve uygulamanız session_start() çağırmasa bile çalışır. mod_php ve PHP-FPM üzerinde komut çalıştırma doğrulandı.

PHP güvenlik ekibi, gösterilen istismar herhangi bir uygulama kodu yüklenmeden önce tek bir kimliği doğrulanmamış istekle tetiklendiği için mod_php'yi en yüksek risk olarak değerlendiriyor.

Kim buldu (ve neden yapay zekâ manşetlerde)

Hatalar PHP 5.4.0'da eklenen koda dayanıyor, yani on yıldan uzun süre kod tabanında kaldılar. PHP Foundation; Calif, OpenAI ve Wiz'e teşekkür etti.

Decrypt ve The Next Web'in haberlerine göre Calif araştırmacısı Ryan Austin, açıkları Ağustos ayında OpenAI'ın GPT-5.6 Sol'u desteğiyle yürüttüğü bir kaynak kodu denetimi sırasında buldu. OpenAI, kendi ekibinin Eylül ayında "Patch the Planet" çalışmasının bir parçası olarak daha kapsamlı bir sürümü bulduğunu söylüyor. Wiz ise her iki hatayı da Gemini 4 Argon, Wiz Atlas ve GPT-5.6 Sol kullanarak kendi başına bulduğunu belirtiyor. Kredi konusunda anlaşmazlık var; ama çıkarılacak ders aynı. Yapay zekâ destekli denetimler artık çekirdek altyapıda on yıllık bellek hatalarını buluyor ve saldırganlar da aynı modellere sahip.

Zaman çizelgesi: yama neden bir gün erken geldi

Amazon, açıklanma tarihinden değil, 17 Ekim'den itibaren inceleme yapılmasını öneriyor (Tenable'ın SSS'si tüm zaman çizelgesini takip ediyor). Sürüm sırasında PHP ekibi, sızıntıdan sonra ortaya çıkan kavram kanıtı kodunu incelediğini ve çalışan bir istismar bulamadığını söyledi. watchTowr ise o zamandan beri her iki hatayı da yeniden ürettiğini belirtti. Bulduğunuz her "PoC" deposuna şüpheyle yaklaşın: doğrulanmamış istismar kodu çoğu zaman kötü amaçlı yazılım içerir.

Etkileniyor musunuz? Beş dakikada kontrol edin

1. Trafiği karşılayan çalışma zamanını kontrol edin, dizüstü bilgisayarınızı değil. CLI ikilisi, sürüm ve yapılandırma açısından FPM veya Apache modülünden farklı olabilir.

# On the server or inside the running container
php -v
php-fpm -v
# Apache mod_php: check the loaded module version
apachectl -M 2>/dev/null | grep -i php

Ya da korumalı bir rotadan bir kez açığa çıkarıp ardından kaldırın:

<?php echo PHP_VERSION, ' ', PHP_SAPI;

2. Düzeltilmiş sürümlerle karşılaştırın.

Debian, Ubuntu, Red Hat ve diğer dağıtımlar genellikle üst kaynak sürüm dizesini değiştirmeden düzeltmeleri geri taşır. php -v daha eski bir numara gösteriyorsa, paniğe kapılmadan önce dağıtımınızın uyarısını okuyun.

3. Gizli PHP'leri envanterleyin. Aylar önce FROM php:8.3-fpm ile oluşturulmuş konteynerler, satıcı cihazları, kendi derlediğiniz yapılar, unutulmuş alt alan adlarındaki yönetim panelleri. Cisco, kendi ürün hattını kontrol etmek için şimdiden bir uyarı yayımladı. Shodan, internete açık 1,9 milyondan fazla PHP ana makinesi sayıyor; bir araştırmacı 1,3 milyon veya daha fazlasının savunmasız olabileceğini tahmin ediyor.

Nasıl yamalanır

# Debian / Ubuntu (Ondřej Surý PPA or distro packages)
sudo apt update && sudo apt install --only-upgrade 'php8.*'

# RHEL / Rocky / Alma with Remi
sudo dnf upgrade 'php*'

# Official Docker image: rebuild on a fixed tag
docker pull php:8.4.27-fpm
docker build --pull -t my-api:patched .

Ardından çoğu ekibin unuttuğu adımı yapın: her PHP worker'ını yeniden başlatın veya değiştirin. Çalışan bir FPM havuzu eski ikiliyi bellekte tutar. php-fpm'i yeniden başlatın, Apache'yi yeniden yükleyin ve tüm konteynerleri döndürün. CVE-2026-109619, bir worker içinde istekler arası yaşayan durumla ilgilidir, yani yeniden başlatılmamış bir worker hâlâ savunmasızdır.

8.1 veya daha eskisinde üç seçeneğiniz var: bir satıcı LTS paketi, PHP'nin kaynak geri taşımasından derleme ya da 8.2+ sürümüne yükseltme. CISA, yamalanamayan PHP sistemlerinin çevrimdışı alınmasını öneriyor; İngiltere NCSC ve FBI da aynısını söyledi.

Bugün yamayamıyorsanız hafifletme önlemleri

Bunlar zaman kazandırır. PHP çekirdek ekibinden Gina Peter Banyard, BleepingComputer'a hiçbir hafifletme önleminin saldırıları tamamen engellemediğini söyledi.

CVE-2026-109618 için:

• Uygulamaların geçersiz kılamayacağı yerlerde memory_limit=-1 ayarlayın (FPM havuzunda veya Apache yapılandırmasında php_admin_value). Bu, bilinen yolu engeller ama bir ayırmanın başarısız olabileceği her yolu değil.
• post_max_size değerini düşürün (yükleme yoksa 8M, yükleme varsa 32M).
• Ters proxy'de istek gövdesi boyutunu sınırlayın (nginx'de client_max_body_size) ve kullanılabilirlik sınırı olarak konteyner veya cgroup bellek limitleri belirleyin.
• RLIMIT_AS veya RLIMIT_DATA süreç limitlerini kullanmayın. Bunlar istismarın ihtiyaç duyduğu ayırma hatalarına yol açabilir.

CVE-2026-109619 için:

• İstek ayrıştırmasından önce yüklenen yapılandırmada session.upload_progress.enabled=0 ayarlayın.
• PHP 8.5'te ayrıca fatal_error_backtraces=0 ayarlayın.
• Hataları display_errors=0 veya @ ile gizlemek hiçbir şey yapmaz. Bayat durum hâlâ oradadır.

Uçta: Cloudflare, bilinen vektörler için ücretsiz dâhil tüm planlarda WAF kurallarını devreye aldı. CTO'su bunları geçici olarak nitelendirdi.

Herhangi bir php.ini değişikliğinden sonra, her worker'ı yeniden başlatın yoksa etkili olmaz.

Zaten vurulduğunuza dair işaretler

Datadog'un tespit rehberi dört sinyale indirgeniyor:

• Günlük satırı: Unknown on line 0 ile birlikte PHP Fatal error: Allowed memory size of ... bytes exhausted. Bu, PHP'nin herhangi bir betik çalışmadan, istek başlangıcı sırasında öldüğü anlamına gelir.
• Apache çökmeleri: AH00052: child pid ... exit signal Segmentation fault (11), muhtemelen başarısız bir istismar denemesi.
• Tuhaf form gönderimleri: birkaç megabayt uzunluğunda bir alan adı ya da boş adlı bir alanda ikili ve null baytları.
• En güçlüsü: bir web worker'ının (php-fpm, apache2, httpd) bir kabuk başlatması.

Durum kodlarına güvenmeyin. Datadog'un geliştirilmiş istismarı HTTP 200 döndürdü ve worker çalışmaya devam etti. Günlükleri 17 Ekim'e kadar geriye doğru arayın.

Yamadan sonra API'nizin hâlâ çalıştığını kanıtlayın: ajanınız çalıştırsın

Üretimde baskı altında PHP yamamak, küçük bir sürüm yükseltmesinin bir şeyi değiştirdiğini tam da bu şekilde fark edersiniz. Düzeltmeyi yayına almadan önce ve sonra, API test paketinizi staging ortamına karşı çalıştırın ve kodlama ajanınızın bunu Apidog CLI ile yapmasına izin verin.

Kurulum (bir kez):

npm install -g apidog-cli
apidog auth login --with-token <your-access-token>
apidog test-suite list --project <projectId>

Claude Code, Codex veya Cursor'a tek bir istem:

PHP2Shell için staging ortamında PHP'yi 8.4.27 sürümüne yükselttik. Apidog CLI kullanarak regresyon test paketimizi staging ortamına karşı çalıştır, HTML ve JUnit raporları yaz ve başarısız olan uç noktaları özetle. Ardından, nginx client_max_body_size değerimizin üzerinde gövdeye sahip bir POST isteğinin PHP'ye ulaşmak yerine proxy'de 413 ile reddedildiğini doğrula.

Ajanın çalıştırdıkları:

apidog test-suite run <testSuiteId> --project <projectId> -e <stagingEnvId>

apidog run --test-suite <testSuiteId> --project <projectId> -e <stagingEnvId> \
  -r cli,html,junit --out-dir ./php2shell-reports --upload-report

-r raporlayıcıları seçer, --out-dir raporların nereye düşeceğini belirler ve --upload-report, Apidog uygulamasında açabileceğiniz bir özeti gönderir. Ekibinize yalnızca bir şey bozulduğunda haber vermek için --notification-failed-event <targetId> ekleyin. Aynı apidog run satırını CI'ya koyun, böylece yeniden derlenen her PHP imajı yayına çıkmadan önce test edilsin. Claude Code kurulum rehberi ve CI/CD iş akışı anlatımı her ikisini de ayrıntılı olarak ele alıyor.

Paketi bir kez eski sürümde bir temel almak için, bir kez de yükseltmeden sonra çalıştırın ve karşılaştırın. Başarısız olmasını hiç beklemediğiniz bir test başarısız olursa, kullanıcılarınızdan önce siz öğrenirsiniz. CLI'nin çalıştırdığı test paketlerini oluşturmak ve yönetmek için Apidog'u indirin.

SSS

PHP2Shell istismar ediliyor mu? Amazon 17 Ekim'den itibaren girişimler gördü ve artık yaygın olarak istismar edildiğini söylüyor; Cloudflare ve watchTowr da saldırılar bildiriyor. CISA, 22 Ekim itibarıyla istismarı doğrulamamıştı.

Çerçevem beni koruyor mu? Hayır. CVE-2026-109618, PHP gövdeyi ayrıştırırken, Laravel, Symfony veya WordPress yüklenmeden önce tetikleniyor.

Paylaşımlı barındırma kullanıyorum. Ne yapmalıyım? Sağlayıcınızın durum sayfasına bakın. SiteGround ve diğerleri yamayı uyguladıklarını söylüyor. Sizinki hiçbir şey söylemediyse sorun.

session.upload_progress.enabled=0 yeterli mi? Hayır. Tek bir CVE'nin tek bir yolunu kapatıyor. Yamayı uygulayın.

Sırları döndürmem gerekiyor mu? CVE-2026-109619 bellek ifşasına izin veriyor. Günlükler 17 Ekim'den beri ele geçirilme işaretleri gösteriyorsa, PHP sürecinin okuyabildiği veritabanı parolalarını, API anahtarlarını ve oturum sırlarını döndürün.

Özetle

8.5.12, 8.4.27, 8.3.36 veya 8.2.35 sürümüne yükseltin. Her worker'ı yeniden başlatın. Unuttuğunuz PHP'yi bulun. Günlükleri 17 Ekim'e kadar geriye doğru kontrol edin. Ardından düzeltmenin bir sonraki kesintiye dönüşmemesi için API testlerinizi çalıştırın. PHP'niz 8.1 veya daha eskisindeyse, artık ondan kurtulmak için tam zamanı.