PHP güvenlik açığı (PHP2Shell): Ne oldu, ne yapmalı? Adım adım rehber

Yazar:

22 Ekim 2026

İnternet sitelerinin yaklaşık yüzde 70’inin arka planında çalışan programlama dilinde ortaya çıkan PHP güvenlik açığı, iki gündür dünyanın gündeminde. “PHP2Shell” adı verilen iki kritik zafiyet, saldırganın hiçbir kullanıcı adı ya da parola girmeden sunucuda kendi kodunu çalıştırmasına imkan tanıyabiliyor. PHP ekibi 21 Ekim akşamı acil güncellemeleri yayımladı, Cumhurbaşkanlığı Siber Güvenlik Başkanlığı ise Türkiye genelinde tarama başlattı. Avrupa’da bazı devlet siteleri önlem olarak geçici süreyle kapatıldı.

Bir bakışta PHP2Shell:

Ne oldu? PHP’nin çekirdeğinde, bellek hatalarını yönetme biçiminden kaynaklanan iki açık bulundu: CVE-2026-109618 ve CVE-2026-109619. İkisi de CVSS v4.0 ölçeğinde 10 üzerinden 9,2 puanla “kritik” sınıfında.
Kimler risk altında? Web isteklerine yanıt veren tüm PHP kurulumları. WordPress, Drupal, Joomla, Magento ve özel yazılımla çalışan siteler de buna dahil.
Çözüm ne? PHP’yi 8.5.12, 8.4.27, 8.3.36 ya da 8.2.35 sürümüne yükseltmek ve PHP servislerini yeniden başlatmak. WordPress ya da eklenti güncellemesi tek başına yetmiyor.
Hemen güncellenemiyorsa? Geçici ayarlar riski azaltıyor ama ortadan kaldırmıyor. ABD’nin siber güvenlik ajansı CISA, güncellenemeyen sistemlerin çevrim dışı bırakılmasını öneriyor.

PHP güvenlik açığı nedir? PHP2Shell’i anlamak için kısa bir özet

PHP, sunucu tarafında çalışan ve web sayfalarını üreten bir programlama dili. WordPress, Drupal, Joomla ve Wikipedia’nın altyapısı MediaWiki gibi yaygın sistemler PHP ile çalışıyor. Bu yüzden dildeki bir hata, üzerinde çalışan milyonlarca siteyi aynı anda ilgilendiriyor.

Bu seferki PHP güvenlik açığı, sitelerin kendi kodunda ya da eklentilerinde değil, doğrudan PHP’nin çekirdeğinde. PHP ekibinin güvenlik duyurusuna göre birinci açık (CVE-2026-109618), bellek yetersizliği hatası bir isteği yarıda kestiğinde ortaya çıkıyor. İstek verisi yarım kalıyor, temizlik aşaması ise bu bozuk veriyi geçerli sanıyor. İkinci açık (CVE-2026-109619) ise bir isteğe ait iç verinin, belleği boşaltıldıktan sonra da sistemde kalmasıyla ilgili. Aynı işçi süreç bir sonraki isteği işlerken bu “bayat” veriyi kullanabiliyor.

Açıkları bulan ekiplerden Wiz Research’e göre sonuç iki türlü olabiliyor: Saldırgan ya sunucuda kod çalıştırıyor ya da PHP sürecinin belleğindeki parola, oturum anahtarı ve API anahtarı gibi bilgileri okuyabiliyor. Wiz, sorunun uygulamadan bağımsız olduğunun altını çiziyor. Yani açık bir PHP sürümünde çalışan, yalnızca “Merhaba Dünya” yazan basit bir sayfa bile risk altında.

20 Ekim’den bugüne: Sızıntıdan acil yamaya neler oldu?

Açıkların koordineli biçimde 22 Ekim Perşembe günü duyurulması planlanıyordu. Ancak bilgiler önceden sızdı ve takvim tamamen değişti. Süreç kısaca şöyle gelişti:

11 Ağustos: Güvenlik şirketi Calif’in CEO’su Thai Duong, şirket araştırmacısı Ryan Austin’in OpenAI’ın GPT-5.6 Sol modeli yardımıyla bulduğu sorunu PHP güvenlik mühendisi Volker Dusch’a bildirdi. Bilgiyi The Wall Street Journal’dan Bloomberg HT aktardı.
19-24 Ağustos: Wiz Research da Wiz Atlas, Gemini 4 Argon ve GPT-5.6 Sol ile yürüttüğü çalışmada ilk açığı buldu. WordPress ve Drupal’da giriş gerektirmeden kod çalıştırabildiğini doğruladıktan sonra 24 Ağustos’ta PHP ekibine raporladı.
21 Eylül: PHP ekibi raporları kabul edip ortak düzeltme çalışmasını başlattı.
20 Ekim, öğleden sonra: Hacker News forumunda yayımlanan bir gönderi, iki CVE numarasını ve planlanan duyuru tarihini ortaya döktü. Güvenlik şirketi watchTowr açıkların gerçek olduğunu doğruladı, Avrupa Birliği’nin siber olaylara müdahale ekibi CERT-EU da uyarı yayımladı.
20 Ekim, gece: PHP ekibi php.net üzerinden ön duyuru yaptı ve güncellemeyi bir gün öne alarak 21 Ekim TSİ 17.00’ye çekti.
21 Ekim, sabah: Cloudflare, yamalar çıkmadan saatler önce ilk saldırı girişimlerini gördüğünü duyurdu ve müşterileri için geçici güvenlik duvarı kuralları devreye aldı.
21 Ekim, 17.00 civarı: PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 yayımlandı. Teknik ayrıntılar da aynı saatlerde kamuya açıldı.
21 Ekim, akşam: FBI, NSA ve CISA’nın uyarıları peş peşe geldi. Siber Güvenlik Başkanlığı TR-26-1372 numaralı güvenlik bildirimini yayımladı.
21-22 Ekim: Türkiye’deki bazı hosting şirketleri müşterilerini bilgilendirmeye ve sunucularında geçici yapılandırma değişiklikleri yapmaya başladı.

Avrupa’da devlet siteleri neden kapatıldı?

PHP güvenlik açığı, birçok ülkeyi “önce kapat, sonra güncelle” yaklaşımına itti. Anadolu Ajansı’nın derlediği bilgilere göre ülkelerin attığı adımlar şöyle:

Hollanda: Başbakan Rob Jetten, vatandaşların devlet hizmetlerine girişte kullandığı DigiD ve MijnOverheid sitelerinin geçici olarak erişime kapatıldığını açıkladı.
Norveç: Ulusal Güvenlik Kurumu, açıkların parola ya da giriş gerektirmeden sistemlerin kontrolünün ele geçirilmesine yol açabileceğini duyurdu. NRK’ya göre Dijitalleşme Müdürlüğü’nün sitesi ve eğitim sektörünün ortak giriş sistemi Feide devre dışı kaldı.
Finlandiya: Ulusal Siber Güvenlik Merkezi, bazı kamu sitelerinin öncelikli tedbir olarak kapatıldığını bildirdi. Helsinki Kitap Fuarı ve Finlandiya Film Vakfı’nın sitelerinde de kesinti yaşandı.
Danimarka: Siber Güvenlik ve Dayanıklılık Kurumu, güncelleme yapamayan sistem sahiplerinden sistemlerini geçici olarak çevrim dışı bırakmalarını istedi.
Belçika: Siber Güvenlik Merkezi (CCB), doğrulanmış bir saldırı olmadığını ama risk yüksek olduğu için sitelerin kapatılmasını önerdi. Kurum kendi sitesini de kapattı.
Japonya: Sağlık, Çalışma ve Refah Bakanlığı bir bilgi paylaşım sitesini askıya aldı. Başbakan Takaiçi Sanae, PHP kullanan sitelere güncelleme çağrısı yaptı.
ABD: FBI, hemen güncelleme yapamayanlara sitelerini çevrim dışı almalarını tavsiye etti. CISA da PHP 8.1 ve daha eski sürümleri kullananlar için aynı öneride bulundu.

Ölçeği anlamak için bir veri: Reuters’ın Censys verilerine dayanan haberine göre taranan 2,6 milyon sunucudan yaklaşık 1,5 milyonu, resmi düzeltmesi bulunmayan bir PHP sürümü çalıştırıyor. Habertürk’ün aktardığı bu rakam, paylaşımlı sunucularda birden fazla site barındığı düşünüldüğünde etkilenen site sayısının çok daha yüksek olabileceğini gösteriyor.

Siber Güvenlik Başkanlığı ne dedi? TR-26-1372 bildirimindeki önlemler

Türkiye’de PHP güvenlik açığı ile ilgili süreci Cumhurbaşkanlığı Siber Güvenlik Başkanlığı yürütüyor. Başkanlık, “Kritik Siber Güvenlik Uyarısı” başlıklı açıklamasında ulusal ölçekte güvenlik taramalarını başlattığını ve ilgili kurumlara acil bildirimler gönderdiğini duyurdu. Bildirimler, Siber Olaylara Müdahale Ekipleri (SOME) İletişim Platformu üzerinden kamu kurumlarına ve kritik altyapı işletmecilerine iletildi.

Başkanlığın yayımladığı TR-26-1372 numaralı “PHP Programlama Dili Güvenlik Bildirimi” üç temel önlem sıralıyor:

Etkilenen sistemlerin belirlenmesi ve üreticinin yayımladığı güvenli sürümlere gecikmeden geçilmesi,
Yönetim panellerine ve kritik PHP servislerine dışarıdan erişimin güvenlik duvarı (Firewall/ACL) kurallarıyla yalnızca güvenilir IP adreslerine açık bırakılması,
Yurt dışından erişim ihtiyacı olmayan sistemlerin uluslararası trafiğe kapatılması.

Yeni Şafak’ın aktardığına göre açıklamada genel bir internet kesintisinden ya da bankacılık hizmetlerinde doğrulanmış bir aksamadan söz edilmedi. Belirli bir bankanın etkilendiğine dair bilgi de paylaşılmadı.

TRT Haber, Başkanlığın uyarısını şu gönderiyle duyurdu:

#SONDAKİKA
Siber Güvenlik Başkanlığı'ndan 'PHP güvenlik açığı' uyarısı.

▪️PHP altyapısındaki güvenlik açıkları nedeniyle ulusal ölçekte taramalar başlatıldı.

▪️Kurum ve kuruluşlara güvenlik güncellemelerini ivedilikle uygulama çağrısı yapıldı.https://t.co/faXb2FluOM https://t.co/7vrrMdi0Yu pic.twitter.com/j7ezt8eBc9

— TRT HABER (@trthaber) October 21, 2026

PHP güvenlik açığı hangi sürümleri etkiliyor?

Wiz’e göre son on yılda yayımlanan her PHP sürümü en az bir açıktan etkileniyor ve etkilenen sürümler PHP 5.4’e kadar uzanıyor. PHP ekibinin yayımladığı güvenli sürümler şunlar:

PHP sürüm dalı	Güvenli sürüm	Not
PHP 8.5	8.5.12	Aktif destekte
PHP 8.4	8.4.27	Aktif destekte
PHP 8.3	8.3.36	Yalnızca güvenlik desteği alıyor
PHP 8.2	8.2.35	Desteği 31 Aralık 2026’da bitiyor
PHP 8.1 ve öncesi	Resmi sürüm yok	Dağıtımın ya da LTS sağlayıcısının yamasına bakılmalı

PHP 8.1 ve daha eski sürümler artık PHP projesinden güncelleme almıyor. Bazı Linux dağıtımları ve uzun süreli destek (LTS) sağlayıcıları bu sürümler için kendi düzeltmelerini yayımlıyor. Açığın ciddiyeti nedeniyle PHP ekibi, kaynak koddan derleme yapanlar için PHP 7.4, 8.0 ve 8.1’e yönelik asgari düzeltme paketleri de paylaştı.

PHP’nin uyarısına göre risk; PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed dahil web isteklerine yanıt veren tüm kurulumlarda bulunuyor. En yüksek risk Apache’nin mod_php yapılandırmasında. Bu yapıda kimlik doğrulamasız tek bir isteğin, uygulama kodu daha çalışmadan saldırıyı tetikleyebildiği gösterildi.

Bir not daha: PHP ekibi, özellikle AlmaLinux ve Rocky Linux kullanıcılarının tercih ettiği gönüllü Remi deposunun 21 Ekim’de güncelleme almayacağını duyurdu. Bu depoyu kullananlara dağıtımın kendi paketlerine geçmelerini ya da kaynaktan derlemelerini önerdi.

PHP güvenlik açığı istismar ediliyor mu? Saldırılarda son durum

Bu konuda kaynaklar farklı tablolar çiziyor. Cloudflare’in teknoloji direktörü Dane Knecht, yamalardan önce ilk saldırıların görülmeye başladığını ve yeni saldırı yolları çıktıkça korumaların güncellendiğini açıkladı. watchTowr her iki açığa yönelik aktif istismar girişimleri gözlemlediğini söyledi. Hadrian ise saldırıların çoğunun PHP’nin oturum yükleme ilerlemesi (session upload progress) özelliğini kullandığını bildirdi. WordPress güvenlik şirketi Patchstack de hosting ortaklarından aktif istismar bildirimleri aldığını duyurdu.

Öte yandan CISA, uyarısını yayımladığı sırada istismar tespit etmediğini belirtti. 21 Ekim itibarıyla iki açık da CISA’nın “istismar edildiği bilinen açıklar” listesine girmemişti. Belirli bir sunucunun bu yolla ele geçirildiğini gösteren, kamuya açık ve doğrulanmış bir vaka da henüz paylaşılmadı.

Yine de güvenlik dünyasında genel kanı net: Yama yayımlandıktan sonra saldırganlar, kodda neyin değiştiğine bakarak istismar yöntemi geliştirebiliyor. Calif CEO’su Thai Duong, yamaların yapay zeka araçlarıyla hızla analiz edilip istismar kodlarının sosyal medyada paylaşılabileceğini söyledi ve olası sonucu “Bütün cehennem kapıları açılır” diye özetledi. PHP Vakfı’nın güvenlik mühendisi Volker Dusch ise sorunu PHP’nin son on yılı aşkın süredeki en ciddi güvenlik problemlerinden biri olarak niteledi ve 2014’teki Heartbleed açığına benzetti. Her iki değerlendirmeyi de CNBC-e aktardı.

Adım adım rehber: PHP güvenlik açığı nasıl kapatılır?

Aşağıdaki adımlar kendi sitesini yöneten kişiler ve sistem yöneticileri için hazırlandı. Paylaşımlı hosting kullananların işi daha kısa, çünkü adımların çoğunu hosting firması üstleniyor.

1. Sitenizin kullandığı PHP sürümünü öğrenin. cPanel kullanıyorsanız “MultiPHP Yöneticisi” ya da “PHP Sürümünü Seç” ekranında her alan adının sürümünü görebilirsiniz. WordPress’te Araçlar > Site Sağlığı > Bilgi > Sunucu sekmesi de sürümü gösteriyor. Komut satırında php -v yazmak yalnızca komut satırının kullandığı sürümü verir; web sitesinin kullandığı sürüm farklı olabilir.

2. Paylaşımlı hosting kullanıyorsanız firmanıza sorun. Bu PHP güvenlik açığı sunucudaki PHP’de olduğu için WordPress çekirdeğini ya da eklentileri güncellemek sorunu çözmüyor. Wordfence ve Cloudflare de bu konuda uyardı. Hosting firmanıza “21 Ekim tarihli PHP güvenlik güncellemeleri sunucuya uygulandı mı?” diye yazılı olarak sorun. Bazı firmalar şimdilik yalnızca geçici ayar değişikliği yaptı ve bu, güncellemenin yerini tutmuyor.

3. Kendi sunucunuz varsa güncelleyin. PHP ekibine göre Linux dağıtımları ve LTS sağlayıcıları düzeltmeleri önceden aldı, bu nedenle çoğu durumda dağıtımın paket yöneticisiyle güncelleme yapmak yeterli. cPanel/WHM sunucularında EasyApache 4 (ea-php) paketleri, CloudLinux’ta alt-php paketleri sistem güncellemesiyle yenileniyor; güncel paketin yayımlandığını sağlayıcının duyurusundan teyit edin. Docker kullananların, güncel resmi PHP imajıyla kendi imajlarını yeniden oluşturması gerekiyor.

4. PHP servislerini yeniden başlatın. Güncelleme, çalışan PHP işçileri yeniden başlatılmadan devreye girmiyor. PHP-FPM’i ve Apache’yi yeniden başlatmayı unutmayın. Sunucuda birden fazla PHP sürümü kuruluysa her birinin ayrı ayrı güncellendiğinden emin olun.

5. Hemen güncelleyemiyorsanız geçici önlemleri alın. PHP ekibinin önerdiği ayarlar aşağıda. Bunlar belirli saldırı yollarını kapatıyor ama siteyi güvenli hale getirmiyor:

php.ini ya da PHP-FPM havuz ayarlarında session.upload_progress.enabled = 0 yapın ve tüm işçileri yeniden başlatın. Bu ayarı ini_set() ya da .user.ini ile vermek işe yaramıyor. Ayar, ikinci açığın doğrulanmış oturum yolunu kapatıyor, diğer varyantları değil.
Dosya yükleme gerekmeyen sitelerde post_max_size = 8M, yükleme gereken sitelerde 32M sınırı koyun. upload_max_filesize değeri post_max_size’ın altında kalmalı.
Birinci açık için memory_limit = -1 ayarı, uygulamaların değiştiremeyeceği şekilde (örneğin php_admin_value ile) öneriliyor. Bu ayar belleğin sınırsız kullanılmasına yol açabileceği için PHP ekibi, sunucu kaynaklarını konteyner ya da cgroup sınırıyla korumayı tavsiye ediyor.
PHP 8.5 kullanıyorsanız fatal_error_backtraces = 0 ayarını yapın.
Cloudflare gibi bir web uygulama güvenlik duvarının (WAF) arkasındaysanız ilgili kuralların açık olduğundan emin olun. CISA da WAF’ın güncellemeye kadar kısmi koruma sağlayabileceğini belirtiyor.
Siber Güvenlik Başkanlığı’nın önerdiği gibi yönetim panellerini (wp-admin, phpMyAdmin, cPanel) yalnızca güvendiğiniz IP adreslerine açın. Bu, saldırı yüzeyini daraltıyor ama tek başına yeterli değil. Erişimi daraltma fikri, “asla güvenme, her zaman doğrula” ilkesine dayanan sıfır güven yaklaşımının da temel adımlarından biri.
Bunların hiçbiri mümkün değilse siteyi güncelleme yapılana kadar bakım moduna ya da çevrim dışına alın.

6. PHP 8.1 ve öncesini kullanıyorsanız geçiş planı yapın. Bu sürümlere PHP projesinden resmi güncelleme gelmeyecek. Önce bir test ortamında siteyi PHP 8.3 ya da 8.4 ile deneyin, tema ve eklenti uyumunu kontrol edin, ardından canlı siteye geçin. Kısa vadede bu mümkün değilse CISA’nın tavsiyesi, sistemin güncellenene kadar çevrim dışı bırakılması.

7. Saldırı izlerini kontrol edin. Wiz’e göre saldırı uygulama katmanının altında gerçekleştiği için uygulama kayıtlarında az iz kalabiliyor. Sunucu kayıtlarında şunlara bakın:

Bellek sınırı (memory limit) hatalarıyla biten olağan dışı çok parçalı (multipart) istekler,
Art arda gelen HTTP 500 hataları,
Anormal derecede büyük ya da bozuk görünen PHPSESSID çerezleri,
Sebepsiz yere sürekli yeniden başlayan PHP işçi süreçleri,
CISA’nın uyardığı gibi PHP süreçlerinin komut satırı açması ya da dışarıdan araç indirmesi.

8. Şüphe varsa şifreleri ve anahtarları yenileyin. Açık, bellekteki parola ve anahtarların sızmasına da yol açabildiği için güncelleme öncesinde uzun süre açıkta kalan sitelerde veritabanı şifresini, API anahtarlarını ve yönetici parolalarını değiştirmek yerinde olur. WordPress’te wp-config.php dosyasındaki güvenlik anahtarlarını (salt) yenilemek, açık oturumları da sonlandırır. Tanımadığınız yönetici hesapları ve son günlerde eklenmiş şüpheli dosyalar için de kontrol yapın.

Sitesi olmayan internet kullanıcıları PHP güvenlik açığı için ne yapmalı?

Telefonunuza ya da bilgisayarınıza yüklemeniz gereken bir güncelleme yok, çünkü PHP güvenlik açığı sunucu tarafında. Ancak ele geçirilen siteler zararlı yazılım dağıtmak ya da sahte giriş sayfaları göstermek için kullanılabiliyor. Bu nedenle:

Önemli hesaplarınızda iki aşamalı doğrulamayı açın.
Her site için farklı ve güçlü şifre kullanın. Bir parola yöneticisi bu işi kolaylaştırır.
“PHP güncellemesi”, “hesabınız risk altında” gibi başlıklarla gelen e-posta ve SMS’lerdeki bağlantılara tıklamayın. Bu tür gündemler oltalama saldırılarında sıkça kullanılıyor.
Hizmet aldığınız bir firmadan uyarı gelirse bağlantıya tıklamak yerine firmanın sitesine kendiniz girerek bilgiyi doğrulayın.

Yapay zeka faktörü: Bu açık neden bir dönüm noktası sayılıyor?

Bu PHP güvenlik açığı ile benzerleri arasındaki en önemli fark, keşfinde yapay zekanın oynadığı rol. Hatalı kod on yılı aşkın süredir PHP’nin içindeydi. Calif CEO’su Duong’a göre bu hata grubunun riskleri geçmişte de konuşulmuştu, ancak istismarı çok zor görüldüğü için konu gündemden düşmüştü.

Wiz’e göre işi değiştiren, gelişmiş yapay zeka modellerinin birden fazla hatayı zincirleme kullanan karmaşık bir saldırıyı pratikte uygulanabilir hale getirmesi oldu. Şirket, eskiden dünya çapında bir ekibin aylarını alacak işi tek bir araştırmacının bir haftada tamamladığını söylüyor. OpenAI de son iki ayda açıkların giderilmesi için araştırmacılardan oluşan bir gruba öncülük ettiğini açıkladı. Gelişme, yapay zekanın yazılımlardaki açıkları hızla bulabilmesinin yaratabileceği “Bugmageddon” endişesini yeniden gündeme taşıdı.

Madalyonun öbür yüzü de var: Aynı araçlar saldırganların da elinde. Yapay zeka, bir yamanın yayımlanmasıyla saldırıların başlaması arasındaki süreyi kısaltabiliyor. Bu da güncellemeyi “yarın yaparım” denebilecek bir iş olmaktan çıkarıyor.

PHP güvenlik açığı hakkında sık sorulan sorular

PHP2Shell nedir, adı nereden geliyor?

PHP2Shell, PHP’nin çekirdeğindeki CVE-2026-109618 ve CVE-2026-109619 numaralı iki kritik açığa verilen ortak isim. Ad, bu açıkları birleştirerek sunucuda komut satırı (shell) erişimi sağlayan istismar betiğinden geliyor.

WordPress sitemi güncellemem yeterli mi?

Hayır. PHP güvenlik açığı WordPress’te değil, sitenin üzerinde çalıştığı PHP’de. WordPress’in ve eklentilerin güncel olması iyi bir alışkanlık ama bu sorunu çözmüyor. Sunucudaki PHP’nin güvenli sürüme yükseltilmesi gerekiyor.

Sitemin PHP sürümünü nasıl öğrenirim?

Hosting panelinizdeki PHP ayarları ekranından ya da WordPress’te Araçlar > Site Sağlığı > Bilgi > Sunucu bölümünden öğrenebilirsiniz. Güvenli sürümler 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 ile bunların üzerindeki sürümler. Ubuntu ve Debian gibi dağıtımlar düzeltmeyi eski sürüm numarasının üzerine ekleyebildiği için bu sistemlerde paketin güncelleme notlarına da bakmak gerekiyor.

PHP 7.4 ya da 8.1 kullanıyorum, ne yapmalıyım?

Bu sürümler PHP projesinden resmi güncelleme almıyor. Hosting firmanızın ya da Linux dağıtımınızın düzeltme yayımlayıp yayımlamadığını öğrenin. Kalıcı çözüm, desteklenen bir sürüme (8.3 ya da 8.4) geçmek. CISA, güncellenemeyen eski sürümlerin çevrim dışı bırakılmasını öneriyor.

PHP güvenlik açığı bankaları ve e-Devlet’i etkiledi mi?

Siber Güvenlik Başkanlığı’nın açıklamasında genel bir internet kesintisinden ya da bankacılık hizmetlerinde doğrulanmış bir aksamadan söz edilmedi. Belirli bir kurumun ya da bankanın etkilendiğine dair bilgi de paylaşılmadı. Başkanlık, kamu kurumları ve kritik altyapılar için tarama ve koordinasyon çalışmalarının sürdüğünü açıkladı.

session.upload_progress ayarını kapatmak yeterli mi?

Hayır. Bu ayar ikinci açığın doğrulanmış saldırı yolunu kapatıyor ama birinci açığa etkisi yok. PHP ekibi, tam çözümün yalnızca güncelleme olduğunu açıkça belirtiyor.

Sitemin saldırıya uğradığını nasıl anlarım?

Sunucu kayıtlarında art arda HTTP 500 hataları, bellek sınırı hatalarıyla biten çok parçalı istekler, olağan dışı PHPSESSID çerezleri ve PHP süreçlerinin beklenmedik komutlar çalıştırması şüphe işaretleri arasında. Böyle bir durumda hosting firmanızla ya da bir güvenlik uzmanıyla iletişime geçin, şifrelerinizi ve anahtarlarınızı yenileyin.

Kaynaklar:

PHP, Security advisory: Critical remote code execution vulnerabilities (21 Ekim 2026)
Cumhurbaşkanlığı Siber Güvenlik Başkanlığı, TR-26-1372 PHP Programlama Dili Güvenlik Bildirimi (21 Ekim 2026)
Wiz Research, PHP2Shell araştırması (21 Ekim 2026)
CISA, Critical Vulnerabilities in PHP Require Immediate Patching (21 Ekim 2026)