Kritik PHP Güvenlik Açıkları: Web Siteniz Risk Altında mı? Nasıl Korunabilirsiniz?

PHP Security Team, 21 Ekim 2026'da kimlik doğrulaması gerektirmeden uzaktan kod çalıştırmaya (RCE) imkân verebilen iki kritik güvenlik açığını kapatan güncellemeler yayımladı. CVE-2026-109618 ve CVE-2026-109619 kodlu açıkların her ikisi de CVSS v4.0 ölçeğinde 9,2 puan aldı. Düzeltmeler PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerinde yer alıyor.

Bu, her PHP sitesinin ele geçirildiği anlamına gelmiyor. Ancak web isteği işleyen her PHP kurulumu risk değerlendirmesine giriyor. Yapmanız gereken ilk şey basit: sitenizin hangi PHP sürümüyle çalıştığını öğrenin ve bu sürümün güvenlik düzeltmesini içerip içermediğini hosting sağlayıcınızdan teyit edin.

Ayrıntılara geçmeden önce şu beş soruyu yanıtlayın:

Bu sorulardan birine “bilmiyorum” diyorsanız, aşağıdaki bölümler tam olarak o boşluğu doldurmak için hazırlandı.

PHP'de Hangi Güvenlik Açıkları Tespit Edildi?

PHP çekirdeğinde, istek işleme sırasında belleğin yönetilme biçimiyle ilgili iki ayrı açık tespit edildi. İkisi de belirli koşullarda saldırganın sunucuda kendi kodunu çalıştırmasına zemin hazırlayabiliyor. PHP Security Team açıkları 20 Ekim'de önceden duyurdu, düzeltmeleri ise 21 Ekim 2026'da, saat 14:00 UTC (Türkiye saatiyle 17:00) için planlanan güvenlik sürümüyle yayımladı.

Birkaç kavramı netleştirelim. CVE (Common Vulnerabilities and Exposures), bir güvenlik açığına verilen evrensel kimlik numarasıdır. CVSS, açığın ciddiyetini 0–10 arasında puanlayan uluslararası sistemdir; 9,0 ve üzeri “kritik” kabul edilir. RCE (Remote Code Execution) ise saldırganın sunucuya fiziksel ya da yetkili erişimi olmadan, uzaktan kod çalıştırabilmesi demektir.

Bu Güvenlik Açıkları Web Siteleri İçin Ne Anlama Geliyor?

En kötü senaryoda, yamasız bir sunucuya gönderilen özel hazırlanmış bir istek, saldırganın o sunucuda kod çalıştırmasına yol açabilir. PHP Security Team'e göre risk, web isteklerini işleyen tüm PHP kurulumlarını kapsıyor: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed. Ekip, riski en yüksek ortam olarak mod_php'yi işaret ediyor; bu ortamda kimlik doğrulaması olmayan bir isteğin, uygulama kodu daha çalışmadan saldırıyı tetikleyebildiği gösterilmiş.

Başarılı bir istismarın olası sonuçları şunlar olabilir:

• Sunucuda yetkisiz kod çalıştırılması
• Web sitesi dosyalarının değiştirilmesi veya sayfalara zararlı içerik eklenmesi
• Arka kapı (backdoor) ya da zararlı yazılım yerleştirilmesi
• Veritabanındaki müşteri, sipariş veya iletişim verilerinin tehlikeye girmesi
• Sitenin yavaşlaması, erişilemez hâle gelmesi veya arama motorlarınca işaretlenmesi

Bunlar olası sonuçlardır; gerçekleştiklerine dair genel bir tespit yoktur. Bir saldırının işe yarayıp yaramayacağı PHP sürümüne, çalışma ortamına, sunucu yapılandırmasına ve yamanın uygulanıp uygulanmadığına bağlıdır. Bazı güvenlik firmaları açıkların laboratuvar ortamında yeniden üretildiğini bildirdi; 23 Ekim itibarıyla PHP'nin resmî duyurularında yaygın aktif istismara ilişkin bir doğrulama bulunmuyor. Bu tablo hızla değişebileceği için beklemek yerine güncellemeyi öne almak en güvenli tutumdur.

Hangi PHP Sürümleri Etkileniyor?

Resmî olarak desteklenen dört PHP dalının tamamı etkileniyor ve her biri için düzeltilmiş sürüm yayımlandı. Sitenizin bu sürümlerden birinde ya da sağlayıcınızın aynı düzeltmeleri içeren paketinde çalışması gerekiyor.

PHP 8.1 ve daha eski sürümler için durum farklı. PHP projesi bu dallara artık güncelleme yayımlamıyor. Açıkların ciddiyeti nedeniyle PHP Security Team, kaynak koddan derleme yapanlar için PHP 7.4, 8.0 ve 8.1'e yönelik asgari kaynak kodu yamaları (backport) paylaştı. Bazı Linux dağıtımları ve uzun süreli destek (LTS) sağlayıcıları da kendi yamalı paketlerini sunuyor. Ancak bu yamalar yalnızca bu iki açığı hedefliyor; eski sürümü yeniden “desteklenen” hâle getirmiyor.

Önemli: Linux dağıtımları yamayı kendi paketlerine uyguladığında sürüm numarası değişmeyebilir. Örneğin sunucunuz “8.3.x” gösterirken yamayı içeriyor olabilir ya da tam tersi. Bu yüzden yalnızca numaraya bakmak yerine paket değişiklik kaydını veya sağlayıcınızın duyurusunu kontrol edin.

23 Ekim güncellemesi: Session upload progress uyarısı

PHP Security Team, 23 Ekim 2026'da bilgilendirme amaçlı ek bir duyuru yayımladı. Bir sonraki düzenli hata düzeltme sürümüne kadar session.upload_progress.enabled=0 ayarının kullanılmasını öneriyor. Ayar, CVE-2026-109619 duyurusunda zaten geçici önlem olarak listelenmişti; o tarihte uyguladıysanız yerinde tutmanız yeterli. Ekip, yeni sorunun (CVE-2026-115560) yalnızca alışılmadık bir yapılandırma ile uygulama kodu birleştiğinde ortaya çıktığını, bu nedenle düzenli sürüm döngüsünde ele alınacağını belirtiyor.

WordPress Kullananlar Risk Altında mı?

WordPress'in kendisinde bir açık yok; ancak WordPress PHP üzerinde çalıştığı için sunucudaki PHP yamasızsa WordPress siteniz de risk kapsamındadır. Çekirdeği, temayı ve eklentileri güncel tutmak bu açığı kapatmaz.

Bunu bir binaya benzetebiliriz: WordPress, tema ve eklentiler dairenin içindeki eşyalardır; PHP ise binanın taşıyıcı sistemidir. Eşyaları yenilemek, taşıyıcı sistemdeki bir çatlağı onarmaz. Dolayısıyla iki ayrı iş listesi vardır:

PHP'yi daha yeni bir dala taşıyacaksanız, eski veya bakımı bırakılmış eklentiler uyumsuzluk çıkarabilir. Bu da güncellemeyi ertelemek için değil, kısa ve planlı bir test yapmak için bir nedendir.

Web Sitenizin PHP Sürümünü Nasıl Kontrol Edebilirsiniz?

Sürümü öğrenmenin en kolay yolu hosting kontrol panelinize veya WordPress yönetim panelinize bakmaktır. Aşağıdaki menü adları panel sürümüne ve sağlayıcının yapılandırmasına göre farklılık gösterebilir.

• cPanel: “Yazılım” bölümündeki MultiPHP Manager veya Select PHP Version ekranı, alan adınıza atanmış PHP dalını gösterir.
• Plesk: Web Siteleri ve Alan Adları altında ilgili alan adının PHP (PHP Ayarları) bölümü, kullanılan sürümü ve PHP işleyicisini (FPM, CGI vb.) gösterir.
• WordPress: Araçlar → Site Sağlığı → Bilgi → Sunucu sekmesinde PHP sürümü yer alır. Site Sağlığı ayrıca eski bir PHP sürümü kullanıyorsanız uyarı verebilir.
• Sunucu erişimi olanlar: Komut satırında php -v; FPM için php-fpm -v (dağıtıma göre php-fpm8.3 -v gibi). Komut satırı ile web tarafı farklı PHP ikilileri kullanabilir, ikisini de kontrol edin.

PHP Sürümü Nasıl Yükseltilir? Görsellerle Adım Adım

Paylaşımlı hostingde PHP sürümünü çoğunlukla kontrol panelinden birkaç tıklamayla değiştirebilirsiniz: cPanel'de MultiPHP Manager, Plesk'te ise alan adının PHP ayarları üzerinden. Başlamadan önce birbirine karıştırılan iki işlemi ayırmak gerekir:

• Aynı dal içinde güvenlik güncellemesi (ör. 8.3.35 → 8.3.36): Bu açıkları kapatan işlem budur. Paylaşımlı ve yönetilen hostingde sağlayıcı sunucu tarafında yapar; panelde sizin seçeceğiniz bir ayar genellikle bulunmaz.
• Dal yükseltmesi (ör. 8.1 → 8.3): Desteği bitmiş bir sürümden çıkmak için yapılır. Paneldeki sürüm listesinden siz seçersiniz ve kısa bir uyumluluk testi gerekir.

Hangi dalı seçmelisiniz? Panelinizde sunulan ve resmî destek kapsamındaki en güncel dalı tercih edin; 23 Ekim 2026 itibarıyla desteklenen dallar 8.2, 8.3, 8.4 ve 8.5'tir. PHP 8.2'nin desteği 31 Aralık 2026'da sona ereceği için yeni bir geçişte 8.3 ve üzeri size daha uzun bir süre kazandırır. PHP 8.1 veya daha eskisinden geliyorsanız ara dallara tek tek uğramanız gerekmez; önemli olan eklenti ve temanızın hedef sürümü desteklemesidir.

Hazırlık: Yükseltmeden önce üç kontrol

1. Yedek alın. Dosyaları ve veritabanını birlikte yedekleyin. Panelin yedekleme aracını veya bir yedekleme eklentisini kullanabilirsiniz.
2. Uyumluluğu kontrol edin. WordPress eklenti sayfalarında yer alan asgari PHP sürümü bilgisine ve eklentinin son güncellenme tarihine bakın. Uzun süredir güncellenmeyen eklentiler en sık sorun çıkaran bileşenlerdir.
3. Önce WordPress'i güncelleyin. Çekirdek, tema ve eklentileri güncel hâle getirdikten sonra PHP dalını değiştirmek, uyumsuzluk ihtimalini azaltır. İmkânınız varsa denemeyi hazırlık (staging) kopyasında yapın.

cPanel'de PHP sürümünü değiştirme

1. cPanel'e giriş yapın ve Yazılım bölümünden MultiPHP Manager'ı açın.
2. Sürümünü değiştirmek istediğiniz alan adının yanındaki kutuyu işaretleyin (1).
3. Üstteki açılır listeden hedef sürümü seçin, örneğin PHP 8.3 (2).
4. Uygula düğmesine tıklayın (3). Değişiklik genellikle birkaç saniye içinde etkin olur.

Bazı sunucularda bu ekran yerine Select PHP Version (PHP Seçici) bulunur. Mantık aynıdır: sürümü seçip kaydedersiniz. Bu ekranda PHP eklentileri (extensions) sürüm başına ayrı tutulduğu için, geçişten sonra sitenizin ihtiyaç duyduğu eklentilerin (ör. intl, imagick, zip) yeni sürümde de açık olduğunu kontrol edin.

Plesk'te PHP sürümünü değiştirme

1. Web Siteleri ve Alan Adları sayfasında ilgili alan adını bulun ve PHP (bazı sürümlerde PHP Ayarları) kutucuğuna tıklayın (1).
2. PHP sürümü listesinden hedef sürümü seçin (2). PHP işleyicisini (FPM, CGI vb.) özel bir nedeniniz yoksa değiştirmeyin.
3. Uygula veya Tamam ile kaydedin (3).

WordPress'te yeni sürümü doğrulama

Panelde yaptığınız değişikliğin siteye yansıdığını WordPress içinden kontrol edin. Önbellek eklentisi kullanıyorsanız önce önbelleği temizleyin.

1. Yönetim panelinde Araçlar → Site Sağlığı sayfasını açın (1).
2. Bilgi sekmesine geçin (2).
3. Sunucu bölümünü genişletin ve PHP sürümü satırını okuyun (3). 8.3 dalında 8.3.36 ve üzeri, 21 Ekim güvenlik düzeltmesini içerir.

VPS veya kendi sunucusunu yönetenler için

Kendi sunucunuzu yönetiyorsanız güncellemeyi işletim sisteminin paket yöneticisiyle yaparsınız. Aşağıdaki komutlar örnektir; paket adları dağıtıma ve kullandığınız PHP deposuna göre değişir.

# Mevcut sürümü görün (CLI)
php -v

# Debian / Ubuntu örneği – aynı dal içinde güvenlik güncellemesi
sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
sudo systemctl restart php8.3-fpm

# RHEL / AlmaLinux / Rocky örneği
sudo dnf upgrade "php*"
sudo systemctl restart php-fpm

# Apache mod_php kullanıyorsanız web sunucusunu yeniden başlatın
sudo systemctl restart apache2   # RHEL tabanlı sistemlerde: httpd

Yeniden başlatma adımını atlamayın: eski PHP işçileri bellekte çalışmaya devam ederse yama devreye girmez. Deponuzun 21 Ekim düzeltmelerini gerçekten içerdiğini paket değişiklik kaydından (Debian/Ubuntu'da apt changelog php8.3-fpm gibi) teyit edin. Dal değiştirecekseniz yeni dalı ayrıca kurmanız ve web sunucusunu veya FPM havuzunu yeni sürüme yönlendirmeniz gerekir; bu adımlar dağıtıma göre farklılık gösterir.

Sorun çıkarsa: güvenli toparlanma planı

Yükseltmeden sonra beyaz ekran veya “500 Internal Server Error” görürseniz ilk refleksiniz eski PHP sürümüne dönmek olmamalı. Önceki sürüm bu açıklara karşı yamalı değilse, siteyi yeniden aynı riske açmış olursunuz. Bunun yerine şu sırayı izleyin:

1. Hatanın kaynağını bulun. PHP hata günlüğü veya WordPress debug.log dosyası, sorunun hangi eklenti ya da temadan geldiğini genellikle ilk satırlarda gösterir.
2. Sorunlu bileşeni devre dışı bırakın. Yönetim paneline giremiyorsanız dosya yöneticisinden ilgili eklentinin klasör adını değiştirmeniz (ör. eklenti-adi → eklenti-adi-kapali) WordPress'in onu yüklememesi için yeterlidir.
3. Bileşeni güncelleyin veya değiştirin. Geliştiricinin yeni sürümünü kurun ya da yeni PHP sürümünü destekleyen bir alternatife geçin; ardından eklentiyi yeniden etkinleştirin.
4. Site tamamen bozulduysa yedekten dönün. Yükseltme öncesinde aldığınız yedeği geri yükleyin; ancak yeni PHP sürümünü koruyun ve sorunu hazırlık (staging) kopyasında çözün.

PHP Güvenlik Açıklarından Korunmak İçin Ne Yapmalısınız?

Tek tam çözüm, PHP'yi düzeltilmiş sürüme güncellemektir. PHP Security Team, geçici önlemlerin kurulumu güvenli hâle getirmediğini açıkça vurguluyor. Aşağıdaki sıra, riski hızla düşürürken sitenizi bozma ihtimalini de azaltır:

1. PHP sürümünüzü belirleyin. Panelden veya Site Sağlığı'ndan dalı ve mümkünse tam sürümü not edin.
2. Sağlayıcınızın duyurusunu kontrol edin. Hosting firmanızın durum sayfasını, e-postalarını veya destek kanalını inceleyin.
3. Düzeltmenin uygulandığını doğrulayın. Tam sürüm 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 veya üzeri mi? Değilse sağlayıcınızdan yazılı teyit isteyin.
4. Güncel bir yedek alın ve geri yüklenebildiğini kontrol edin. Dosyalar ve veritabanı birlikte yedeklenmeli; yedeğin açılabildiğini bir kez test edin.
5. Uyumluluğu kısa bir testle kontrol edin. Aynı PHP dalı içinde güvenlik güncellemesi genellikle uyumluluk sorunu çıkarmaz. Dal değiştiriyorsanız önce hazırlık (staging) ortamında deneyin.
6. Güncellemeyi kontrollü uygulayın. Düşük trafikli bir saat seçin, PHP-FPM veya web sunucusunu yeniden başlatarak eski işçilerin kapandığından emin olun.
7. Site işlevlerini test edin. Aşağıdaki “güncelleme sonrası test listesi”ni uygulayın.
8. Şüpheli değişiklikleri inceleyin. Son günlerde değişen dosyaları, yeni yönetici hesaplarını ve erişim kayıtlarındaki olağan dışı istekleri kontrol edin.

Aynı dal içindeki bir güvenlik güncellemesi için haftalar süren test döngüleri gerekmez. Uyumluluk testi, kritik bir yamayı günlerce bekletmenin gerekçesi olmamalıdır.

Hemen güncelleyemeyen sunucu yöneticileri için geçici önlemler

Kendi sunucusunu yöneten ve güncellemeyi birkaç saat ertelemek zorunda kalanlar için PHP Security Team bazı önlemler sıraladı. Bunlar yalnızca belirli saldırı yollarını daraltır; kurulumu güvenli hâle getirmez ve güncellemenin yerini tutmaz:

• CVE-2026-109619 için: session.upload_progress.enabled=0 ayarını uygulamaların değiştiremeyeceği bir düzeyde (php.ini, FPM havuzu veya sunucu yapılandırması) tanımlayın ve tüm işçileri yeniden başlatın. ini_set() veya .user.ini ile yapılan ayara güvenmeyin. PHP 8.5'te fatal_error_backtraces=0 ayarı da bilinen bir yolu kapatır.
• CVE-2026-109618 için: post_max_size değerini düşürün (dosya yükleme yoksa 8M, varsa 32M önerisi) ve upload_max_filesize değerini bunun altında tutun. İstek boyutu, alan sayısı ve başlık sayısı için web sunucusu veya proxy düzeyinde sınırlar koyun.
• Hataları display_errors veya @ ile gizlemek koruma sağlamaz. Saldırganın tetikleyebileceği ölümcül hataları ve zaman aşımlarını düzeltmek gerekir.

Tüm geçici önlemlerin teknik ayrıntıları PHP'nin resmî güvenlik duyurusunda yer alıyor. Bu ayarları üretim ortamına uygulamadan önce uygulamanızla birlikte test edin.

Güncelleme sonrası test listesi

PHP güncellemesinin ardından şu işlevleri bu sırayla kontrol etmek, sorunları ziyaretçileriniz fark etmeden yakalamanızı sağlar:

Hosting Sağlayıcısı ile Site Sahibinin Güvenlik Sorumlulukları Nelerdir?

Kısa cevap: Paylaşımlı ve yönetilen hostingde PHP yamasını genellikle sağlayıcı uygular; yönetilmeyen VPS veya dedicated sunucuda ise bu iş sizindir. WordPress, tema, eklenti ve site içeriği her modelde büyük ölçüde site sahibinin sorumluluğundadır.

Bu tablo genel bir varsayımdır; kesin kapsamı hizmet sözleşmeniz ve paket içeriğiniz belirler. Emin değilseniz sağlayıcınıza şu soruları yöneltin:

• Sunucumdaki PHP, 21 Ekim 2026 güvenlik düzeltmelerini içeriyor mu? Hangi tarihte uygulandı?
• Kullandığım PHP dalı resmî destek kapsamında mı? Değilse ne zaman ve nasıl geçiş yapmalıyım?
• PHP işçi süreçleri güncelleme sonrası yeniden başlatıldı mı?
• Yedekler ne sıklıkla alınıyor, kaç gün saklanıyor ve geri yükleme nasıl talep ediliyor?

Eski PHP Sürümlerini Kullanmak Neden Riskli?

Desteği sona ermiş (end-of-life) bir PHP sürümü, yeni bulunan açıklar için resmî düzeltme almaz. Bugün tek bir açık için yama uygulanmış olsa bile, yarın çıkacak bir sonraki açık kapanmadan kalabilir.

PHP'nin destek modeli nettir: her dal iki yıl aktif destek, ardından iki yıl yalnızca kritik güvenlik düzeltmesi alır. Dört yılın sonunda dal kullanım ömrünü tamamlar. PHP 8.2'nin güvenlik desteği 31 Aralık 2026'da sona erecek; yani 8.2.35 kullanıyorsanız bu açıklara karşı korunuyorsunuz, ancak yaklaşık iki ay içinde 8.3 veya üzerine geçiş planlamanız gerekiyor.

Bazı sağlayıcıların veya dağıtımların eski sürümlere özel yama (backport) uygulaması değerli bir ara çözümdür. Yine de bu yamalar yalnızca belirli açıkları kapatır; eski sürümdeki diğer bilinen sorunları, performans eksiklerini ve modern eklentilerle uyumsuzluğu gidermez. Kalıcı çözüm, desteklenen bir dala geçmektir.

Güvenli Bir Hosting Hizmeti Seçerken Nelere Dikkat Edilmeli?

Bu tür olaylar, hosting seçiminde fiyat ve disk alanı kadar güvenlik süreçlerinin de önemli olduğunu gösteriyor. Bir sağlayıcıyı değerlendirirken şu kriterlere bakabilirsiniz:

Bu kriterler Atak Domain hosting paketlerinde nasıl karşılanıyor?

Yukarıdaki kriterleri Atak Domain'in web hosting paketleri üzerinden de değerlendirebilirsiniz. Aşağıdaki bilgiler, ürün sayfasında paketler için listelenen özelliklerden derlenmiştir; bu PHP olayına özel bir müdahale beyanı değildir.

Sık Sorulan Sorular

PHP güvenlik açığı web sitemi etkiler mi?

Siteniz PHP ile çalışıyorsa (WordPress, Joomla, OpenCart, Laravel vb.) ve sunucudaki PHP henüz 21 Ekim 2026 düzeltmelerini içermiyorsa risk kapsamındasınız. PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 veya sağlayıcınızın yamalı paketi kullanılıyorsa bu iki açık kapatılmıştır. Açığın varlığı, sitenizin ele geçirildiği anlamına gelmez.

PHP sürümümü hemen güncellemeli miyim?

Evet. PHP Security Team tüm kullanıcılara derhâl güncelleme yapmalarını öneriyor. Aynı dal içindeki güvenlik güncellemesi (örneğin 8.3.35'ten 8.3.36'ya) genellikle uyumluluk sorunu çıkarmaz. Paylaşımlı hostingdeyseniz bu işlemi sağlayıcınız yapar; sizin göreviniz uygulandığını teyit etmektir.

WordPress güncelse PHP de güvenli midir?

Hayır. WordPress çekirdeği, tema ve eklenti güncellemeleri PHP çalışma zamanındaki açığı kapatmaz. PHP sunucu düzeyinde ayrıca güncellenmelidir. İkisi farklı katmanlardır ve her biri ayrı takip edilmelidir.

Hosting sağlayıcım PHP yamalarını otomatik uygular mı?

Paylaşımlı ve yönetilen hosting hizmetlerinde genellikle evet; ancak zamanlama ve kapsam sağlayıcıdan sağlayıcıya değişir. Yönetilmeyen VPS veya dedicated sunucuda bu iş sizindir. En doğrusu, sağlayıcınızdan yamanın uygulandığına dair yazılı teyit almaktır.

PHP sürümünü değiştirmek web sitemi bozar mı?

Aynı dal içinde güvenlik güncellemesi nadiren sorun çıkarır. Dal değişikliği (örneğin 8.1'den 8.3'e) ise eski eklenti veya temalarda hata yaratabilir. Önce yedek alın, mümkünse hazırlık ortamında deneyin ve güncelleme sonrası test listesini uygulayın.

PHP 8.2 hâlâ güvenli mi?

PHP 8.2.35 bu iki açığa karşı düzeltme içeriyor. Ancak PHP 8.2'nin resmî güvenlik desteği 31 Aralık 2026'da sona erecek; bu tarihten sonra yeni açıklar için düzeltme yayımlanmayacak. Önümüzdeki haftalarda 8.3 veya üzerine geçişi planlamanız önerilir.

SSL sertifikası bu güvenlik açığını engeller mi?

Hayır. SSL, tarayıcı ile sunucu arasındaki trafiği şifreler; sunucuda çalışan PHP'deki bir açığı kapatmaz. Şifreli bir bağlantı üzerinden de zararlı istek gönderilebilir. WAF ve zararlı yazılım tarayıcıları riski azaltabilir, ama güncellemenin yerini tutmaz.

Güvenlik açığı nedeniyle sitemi kapatmalı mıyım?

Genellikle gerekmez. Öncelik, PHP'nin güncellenmesi ve bunun teyit edilmesidir. Kendi yönettiğiniz, yamalanamayan ve özellikle mod_php kullanan kritik bir sunucunuz varsa, güncelleme tamamlanana kadar erişimi sınırlamak değerlendirilebilir. Bu karar sizin risk değerlendirmenize bağlıdır.

VPS kullanıyorsam ne yapmalıyım?

Dağıtımınızın güvenlik deposundan PHP paketlerini güncelleyin (veya kaynak koddan 21 Ekim sürümünü derleyin), PHP-FPM ve web sunucusunu yeniden başlatın, php -v ile CLI'yi, phpinfo veya paket kaydıyla web tarafını doğrulayın. Birden fazla PHP sürümü kuruluysa her birini ayrı kontrol edin.

Sonuç: Önce Güncelleyin, Sonra Doğrulayın

CVE-2026-109618 ve CVE-2026-109619, PHP'nin kendisini etkileyen ve uzaktan kod çalıştırmaya varabilen nadir açıklardan. İyi haber şu ki düzeltmeler hazır ve desteklenen tüm dallar için yayımlanmış durumda.

Bugün yapmanız gereken üç şey var: PHP sürümünüzü öğrenin, düzeltmenin uygulandığını teyit edin ve güncel bir yedeğiniz olduğundan emin olun. PHP 8.1 veya daha eski bir sürüm kullanıyorsanız, bu olay desteklenen bir dala geçişi planlamak için de iyi bir fırsat.

Güvenliği tek seferlik bir müdahale değil, düzenli bir bakım işi olarak ele almak uzun vadede en az zahmetli yoldur: desteklenen PHP sürümü, düzenli yedek ve ulaşılabilir teknik destek bu bakımın üç temel parçasıdır.

Kaynaklar

• PHP News Archive 2026 – Security advisory: Critical remote code execution vulnerabilities (21.10.2026)
• PHP – Informational advisory: Session upload progress (23.10.2026)
• PHP – Supported Versions
• GitHub Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub Security Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)