PHP2Shell (CVE-2026-109618 ve CVE-2026-109619): PHP Kullanan Şirketler Şimdi Ne Yapmalı

Bir sunucu kabininde dizüstü bilgisayarla çalışan bir teknisyen

PHP projesi 21 Ekim 2026'da, “kimlik doğrulaması olmadan uzaktan kod çalıştırılmasına olanak tanıyabilen” iki güvenlik açığını düzeltmek için PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerini yayımladı. Daha açık söylemek gerekirse: web sitenize HTTP isteği gönderebilen herkes, sunucunuzda kendi kodunu çalıştırma imkânı bulabilir. Bunun için parolaya ihtiyaç yok ve bazı kurulumlarda saldırı, uygulamanız tek bir satır bile çalıştırmadan işe yarıyor. Bu ikiliye PHP2Shell adı verildi ve PHP her ikisini de 9,2 olarak derecelendiriyor (CVSS 4.0, 10 üzerinden).

Bu rehber, harekete geçmesi gereken kişiler için: PHP web sitelerinin ve online mağazaların sahipleri, BT yöneticileri ve PHP'yi kendisi adına bir tedarikçinin çalıştırdığı herkes. Sürümlerin ertesi günü, 22 Ekim 2026'da; PHP projesinin kendi güvenlik duyurularına, ulusal siber güvenlik kurumlarının yönergelerine ve firmaların yayımladığı rakamlara dayanarak yazıldı. Kaynakların birbirinden ayrıldığı yerlerde bunu belirtiyoruz.

Kısa Özet

PHP'nin kendisini güncelleyin, ardından yeniden başlatın. WordPress, Drupal, Laravel ya da bir eklentiyi güncellemek bu sorunu çözmez. Açık, uygulamanızın altındaki PHP'de.
Web isteklerine yanıt veren her PHP kurulumu kapsamda. PHP'ye göre bunlar PHP-FPM, mod_php ile Apache, php-cgi, FrankenPHP ve LiteSpeed. PHP, en yüksek riski mod_php ile çalışan Apache'de görüyor.
PHP web sitelerinin neredeyse yarısı, PHP projesinin artık sürüm yayımlamadığı bir dalda çalışıyor (W3Techs verilerine ilişkin kendi yorumumuz; ayrıntılar aşağıda). Bunlar için kurulabilecek resmi bir paket yok.
Ayarlar ve güvenlik duvarları güvenlik değil, zaman kazandırır. PHP geçici önlemleri sıralıyor ve bunlar için “bir kurulumu güvenli hale getirmez” diyor.
Bugün yama uygulayamıyorsanız, ABD, Birleşik Krallık ve AB kurumları aynı tavsiyeyi veriyor: yama uygulayabilene kadar sistemi internetten çekin.

Olaylar Nasıl Gelişti?

19 Ağustos 2026. Wiz araştırmacıları, kendi açıklamalarına göre açıkların ilkini buluyor ve açıkları 24 Ağustos'ta PHP güvenlik ekibine bildiriyor. PHP'nin güvenlik duyurularında başka birkaç firmanın araştırmacıları da katkı sahibi olarak anılıyor.
20 Ekim. CVE numaraları, planlanan açıklamadan iki gün önce internete sızıyor. PHP sürümü bir gün öne çekip 21 Ekim saat 14:00 UTC'ye alıyor ve herkesi hazırlanmaya çağırıyor.
21 Ekim, 03:02 UTC. Cloudflare, ücretsiz plan dahil WAF'ını kullanan her müşterisi için güvenlik duvarı kurallarını devreye alıyor. Daha sonra “müşterilerimizi hedef alan saldırı trafiği gözlemlediğini” ve saldırganların “korumalarımızı atlatmaya çalışmak için saldırı yükünü değiştirdiğini” gördüğünü bildiriyor.
21 Ekim, 14:00 UTC civarı. PHP düzeltmeleri ve güvenlik duyurusunu yayımlıyor. Aynı gün ABD'de CISA, Birleşik Krallık'ın NCSC'si, CERT-EU ve Avrupa Komisyonu, ENISA, CERT-EU, Europol ile AB'nin ulusal CSIRT'lerinin yayımladığı bir ortak açıklama, kuruluşlara derhal yama uygulamalarını söylüyor.

Ne Kadar Ciddi?

Bu durumu her ayki olağan yamadan ayıran üç şey var.

Saldırganın bir istekten başka hiçbir şeye ihtiyacı yok. Oturum açması gerekmiyor, kimsenin bir bağlantıya tıklaması da gerekmiyor. PHP'nin güvenlik duyurusu, mod_php ile Apache'ye karşı gösterilmiş bir istismarı anlatıyor; bu senaryoda “kimliği doğrulanmamış bir istek, herhangi bir uygulama kodu çalışmadan önce saldırıyı tetikleyebiliyor”. Wiz, güncel WordPress, Drupal ve Joomla'ya karşı saldırılar gösterdi ve “etkilenen bir PHP sürümünde çalışan basit bir ‘Hello World’ uygulamasının bile savunmasız olabileceğini” belirtiyor. Bu yolla çalıştırılan kod, web sunucusu hesabının yetkilerine sahip olur ve bu hesap çoğu sitede uygulamanın yapılandırmasını okuyabilir: veritabanı parolası, API anahtarları, e-posta ve ödeme kimlik bilgileri. PHP, ikinci açık olan CVE-2026-109619 için bellek ifşasını da doğruluyor: tam kod çalıştırma olmasa bile sunucunun belleğindeki verilerin dışarı sızması.

Kurulu taban çok büyük. W3Techs verilerine göre PHP, sunucu tarafı dili bilinen web sitelerinin %69,3'ünde çalışıyor (22 Ekim 2026 rakamları). Palo Alto Networks'ün Unit 42 ekibi, kendi internet taramalarına dayanarak potansiyel olarak savunmasız, internete açık 22,6 milyondan fazla kurulum sayıyor ve en az bir Avrupa hükümetinin önlem olarak web sitesini erişime kapattığını bildiriyor.

İstismar çalışmaları hızla ilerliyor. CERT-EU, ilk kavram kanıtı (proof of concept) kodlarının “dolaşmaya başladığını” bildiriyor. Güvenlik firması watchTowr, honeypot'larının 21 Ekim'den beri istismar faaliyeti kaydettiğini söylüyor. Cloudflare saldırı trafiği bildiriyor. Wiz ise araştırmacılarının çalışma boyunca yapay zeka modelleri kullandığını ve böylece tek bir araştırmacının bir haftada “dünya çapında bir ekibin aylarını alacak” işi yaptığını söylüyor. Bir istismarı sizin PHP sürümünüze uyarlayan saldırganlar da aynı araçlara sahip.

Madalyonun öbür yüzünü de belirtelim: CISA 21 Ekim'de uyarısını yayımladığında henüz bir istismar gözlemlememişti ve iki açıktan hiçbiri Known Exploited Vulnerabilities (bilinen istismar edilmiş güvenlik açıkları) kataloğunda yer almıyordu. Red Hat sorunu kritik değil, “Important” (önemli) olarak derecelendiriyor; çünkü standart bir Red Hat Enterprise Linux sunucusu PHP-FPM kullanıyor ve orada istismar daha zor. Daha zor, imkânsız demek değil: PHP, ikinci açık için bir saldırı yolunun PHP-FPM'de de çalıştığını doğruluyor. Bunların hiçbiri yapmanız gerekenleri değiştirmiyor. Yalnızca ne kadar önceden uyarı alacağınızı değiştiriyor.

Hangi Sürümdesiniz? Rakamlar

W3Techs, sürümünü gösteren siteleri sayarak web sitelerinin hangi PHP sürümlerini çalıştırdığını da yayımlıyor. 22 Ekim 2026 tarihli iki tablosunu birleştirdiğimizde şu tablo çıkıyor:

PHP dalı	PHP web sitelerindeki payı	PHP projesinden düzeltme
8.3, 8.4, 8.5	yaklaşık %34	Evet: 8.3.36, 8.4.27, 8.5.12
8.2	yaklaşık %18	Evet: 8.2.35. Ancak 8.2'nin kendisi 31 Aralık 2026'da kullanım ömrünün sonuna ulaşıyor
8.0, 8.1	yaklaşık %14	Sürüm yok. 8.0 ve 8.1: yalnızca kaynak kodu backport'u
7.x	%26,9	Sürüm yok. 7.4: yalnızca kaynak kodu backport'u; 7.3 ve öncesi: hiçbir şey
5.x ve öncesi	%7,8	Hiçbir şey

Yani PHP web sitelerinin yaklaşık %48'i, PHP projesinin düzeltilmiş sürüm yayımlamadığı bir dalda çalışıyor; bir %18'lik kısım ise düzeltmesini şimdi alıyor ve on hafta sonra desteğini kaybediyor.

İki çekince var. W3Techs yalnızca sürümünü gösteren siteleri görebiliyor. Ayrıca bir Linux dağıtımı eski bir dalı kendisi yamalamış olabilir: aşağıda göreceğiniz gibi Ubuntu bunu yaptı. Sürüm numarası tek başına korunup korunmadığınızı söylemez. Bunu sağlayıcınızın paketinin sürümü söyler.

1. Adım: Çalıştırdığınız Her PHP'yi Bulun

Listelemediğiniz bir şeye yama uygulayamazsınız ve PHP iyi saklanır. Birleşik Krallık'taki NCSC, kuruluşlardan önce internete açık olanlar olmak üzere her PHP sistemini bulmalarını istiyor ve ekliyor: “keşfi eski PHP sürümleriyle sınırlamayın”. AB'nin ortak açıklaması, bazı ürünlerin “doğrudan PHP kullanıyor gibi görünmeseler bile bu güvenlik açıklarından etkilenebileceği” konusunda uyarıyor.

Nerelere bakmalı:

Web siteleri ve mağazalar: WordPress ve WooCommerce, Drupal, Joomla, Magento ve Adobe Commerce, Shopware, PrestaShop, TYPO3 ve Laravel ya da Symfony üzerine kurulmuş her şey.
Unutulanlar: kampanya mikro siteleri, eski bir dil sürümü, internetten erişilebilen staging ve test sunucuları, birinin yıllar önce kurduğu webmail ya da yardım masası.
Container'lar: php temel imajından oluşturulan her imaj kendi PHP'sini taşır. Ana makineyi güncellemek ona hiçbir şey kazandırmaz.
Barındırma kontrol panelleri: cPanel, Plesk ve benzeri paneller, sistemin PHP'sinin yanında kendi PHP derlemelerini getirir. Panelde etkinleştirilmiş her sürüm, ayrıca güncellenmesi gereken ayrı bir parçadır.
İçinde PHP olan ürünler: hazır cihazlar (appliance), izleme araçları, CRM'ler, yardım masaları ve üreticilerin yönetim arayüzleri. Hollanda'nın NCSC'si bu tür ürünlerin durumunu tedarikçi tedarikçi gösteren herkese açık bir liste tutuyor.
Tedarikçiler: barındırma firmanız, ajansınız, altında PHP olduğunu bildiğiniz her hizmet. Sistemlerinizde hangi PHP sürümlerinin çalıştığını ve ne zaman yama uygulanacağını onlara yazılı olarak sorun.

Her biri için PHP sürümünü, PHP'nin nasıl çalıştığını (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, container), internetten erişilebilir olup olmadığını ve kimin yama uygulayabileceğini not edin.

2. Adım: Doğru Sırayla Yama Uygulayın

İnternetten erişilebilen her şeyle başlayın; bunların içinde de önce Apache mod_php kurulumlarıyla.

Desteklenen bir daldaysanız (8.2 ile 8.5 arası). 8.5.12, 8.4.27, 8.3.36 ya da 8.2.35'e veya dağıtımınızın düzeltmeyi içeren paketine güncelleyin. PHP, Linux dağıtımlarının yamaları önceden aldığını söylüyor. Şu ana kadar doğrulananlar:

Ubuntu: 14.04'ten 26.10'a kadar her sürüm için düzeltilmiş paketler. 22.04 ve sonrasında normal güncellemelerle geliyor; 20.04 ve öncesinde ise beş makineye kadar ücretsiz olan bir Ubuntu Pro aboneliği gerekiyor (Canonical'ın duyurusu).
Debian: Debian 13 için php8.4 8.4.27 (DSA-6574-1) ve Debian 12 için php8.2 8.2.35 (DLA-4848-1).
Red Hat Enterprise Linux: Red Hat'in güvenlik bülteni RHSB-2026-013, paketleri sürüm bazında listeliyor.
Remi deposu (Red Hat ailesi sistemlerde daha yeni PHP sürümleri için yaygın olarak kullanılır): CERT-EU 21 Ekim'de deponun sürüm günü için paketi olmadığını belirtti ve dağıtım paketlerine geçmeyi ya da kaynaktan derlemeyi önerdi. Ona güvenmeden önce yetişip yetişmediğini kontrol edin.

PHP 7.4, 8.0 ya da 8.1'deyseniz. PHP projesi bunlar için sürüm yayımlamıyor. Güvenlik ekibi bu üç dal için asgari düzeyde kaynak kodu backport'ları hazırladı; bunlar PHP'yi kendiniz derliyorsanız işe yarar. Aksi halde düzeltmenin sağlayıcınızdan (örneğin Ubuntu Pro, Ubuntu 20.04'teki PHP 7.4'ü kapsıyor) ya da PHP'yi yükseltmekten gelmesi gerekir. CISA'nın 8.1 ya da daha eski bir sürümü kullanan ve güncelleyemeyenlere tavsiyesi net: sistemi yama uygulanana ya da yükseltilene kadar çevrimdışına alın.

PHP 7.3 ya da daha eski bir sürümdeyseniz. PHP projesinden hiçbir şey gelmiyor. Bir sağlayıcı sizin derlemenize hâlâ yama yapmıyorsa seçenekler ya yükseltme ya da sistemi çevrimdışına almak.

Güncellemeden sonra yeniden başlatın. Bir paketi kurmak, zaten çalışmakta olan PHP'nin yerini almaz. Ubuntu'nun duyurusu bunu açıkça söylüyor: uygulamanın “muhtemelen yeniden başlatılması gerekecektir”. Her sunucuda PHP-FPM'i, Apache'yi, LiteSpeed'i ya da container'ı yeniden başlatın. Ardından web sunucusunun gerçekte çalıştırdığı sürümü kontrol edin; yalnızca komut satırındaki php -v çıktısına bakmayın, çünkü o farklı bir derleme olabilir.

Container'lar: imajlarınızı yamalı bir temel imajdan yeniden oluşturun ve yeniden devreye alın. Eski bir imajı çalıştıran yamalı bir ana makine hâlâ risk altındadır.

Yönetilen barındırma: barındırma firmanıza tarihi ve sürümü sorun, ardından kendiniz kontrol edin.

3. Adım: Bugün Yama Uygulayamıyorsanız

PHP'nin güvenlik duyurusu geçici önlemleri sıralıyor ve bunları bir uyarıyla sunuyor: bu önlemler “belirli saldırı yollarına maruziyeti azaltır, ancak bir kurulumu güvenli hale getirmez”. Sunucularınızı yöneten kişi için kısaca:

CVE-2026-109618 için: uygulamanın geçersiz kılamayacağı şekilde memory_limit=-1 ayarlayın (örneğin PHP-FPM havuzunda ya da Apache yapılandırmasında php_admin_value ile); düşük bir post_max_size belirleyin (PHP, dosya yükleme yoksa 8M, varsa 32M öneriyor); istek boyutunu, alan sayısını ve multipart parça sayısını web sunucusunda ya da proxy'de sınırlayın; bir container ya da cgroup bellek sınırı kullanın, asla RLIMIT_AS ya da RLIMIT_DATA kullanmayın.
CVE-2026-109619 için: session.upload_progress.enabled=0 ayarını php.ini'de ya da sunucu yapılandırmasında yapın (ini_set() ile ya da bir .user.ini dosyasıyla değil) ve her worker'ı yeniden başlatın. PHP 8.5'te ayrıca fatal_error_backtraces=0 ayarlayın.

İki uyarı. 20 Ekim'de geniş çapta yayılan oturum ayarı, PHP güvenlik ekibinden bir üyenin belirttiği gibi yalnızca ikinci açığın saldırı yollarını kapatıyor; birincisine karşı hiçbir işe yaramıyor. Ayrıca memory_limit=-1, PHP'nin kendi bellek sınırını kaldırır; böylece tek bir ağır istek artık sunucunun belleğini tüketebilir. Bunu container ya da cgroup sınırıyla birlikte kullanın.

Bir web uygulaması güvenlik duvarı (WAF) biraz işe yarar. Cloudflare'in kuralları, WAF içeren her planda (ücretsiz plan dahil) varsayılan olarak açık; Palo Alto Networks ve diğer firmalar da kendi korumalarını yayımladı. Cloudflare yine de müşterilerine “WAF korumaları olsa bile” PHP'yi yamalamalarını söylüyor ve saldırganların kurallarını atlatmak için saldırı yüklerini değiştirdiğini gözlemledi. Ayrıca bir WAF yalnızca kendi üzerinden geçen trafiği korur. Sunucunuz kendi IP adresinden de yanıt veriyorsa, bir saldırgan WAF'a hiç uğramadan doğrudan sunucuya ulaşabilir.

Bunların hiçbiri hızlıca yapılamıyorsa, CISA, CERT-EU, NCSC ve AB ortak açıklaması aynı yönü gösteriyor: sistemi düzeltilene kadar herkese açık internetten çekin. Bir günlük bakım sayfası, yeniden kurulan bir sunucudan daha ucuza gelir.

4. Adım: Saldırıya Uğrayıp Uğramadığınızı Kontrol Edin

Risk penceresi, sızıntının başladığı 20 Ekim'de açıldı ve saldırı trafiği ertesi sabah bildirildi. Bir sistem bu süre içinde erişilebilir ve yamasız durumdaysa, yama kapıyı kapatır ama birinin önceden içeri girip girmediğini söylemez. NCSC, hemen yama uygulayamayan herkesten ele geçirilme belirtilerini ve arka kapıları kontrol etmesini istiyor.

Yayımlanan yönergelere ve olağan olay müdahalesi pratiğine göre nelere bakmalı:

PHP'nin asla yapmadığı şeyleri yapan PHP süreçleri, örneğin bir shell başlatmak ya da araç indirmek (CISA).
Ardından bellek sınırı hataları ya da tekrarlanan HTTP 500 yanıtları gelen olağandışı multipart istekler, belirgin bir neden olmadan yeniden başlayan PHP worker'ları ve yanıtlarda olağandışı büyüklükte ya da bozuk PHPSESSID çerezleri (Wiz).
Yeni ya da değiştirilmiş PHP dosyaları: yükleme klasörlerinde, önbellek klasörlerinde ya da web kök dizininde; ayrıca CMS'nizde yeni yönetici hesapları ve kimsenin oluşturmadığı zamanlanmış görevler.

Temiz loglar kanıt değildir. PHP'nin ikinci açığa ilişkin güvenlik duyurusu tam olarak bu konuda uyarıyor; Wiz de uygulama loglarının çok az bağlam içerebileceğini belirtiyor.

Bir şey bulursanız, bunu bir yama işi olarak değil, bir olay olarak ele alın. Sunucuyu izole edin, kanıtları koruyun, bir olay müdahale firmasını devreye alın ve web sunucusunun okuyabildiği her gizli bilgiyi değiştirin: veritabanı parolaları, API anahtarları, ödeme ve e-posta kimlik bilgileri, imzalama anahtarları. İkinci açık bellek ifşasına yol açabildiği için, izinsiz giriş belirtisi olmasa bile günlerce internete açık ve yamasız kalmış her sunucuda bu gizli bilgilerin en hassas olanlarını yenilemeyi düşünün.

5. Adım: Neleri Bildirmeniz Gerekebilir?

Bir güvenlik açığı tek başına bildirilmesi gereken bir olay değildir. İstismar edilmiş bir açık ise olabilir.

NIS2: kuruluşunuz kapsamdaysa ve bir ele geçirilme önemli bir olay niteliğindeyse, ulusal CSIRT'inize erken uyarı 24 saat içinde yapılmalıdır. NIS2 rehberimize bakın.
GDPR: kişisel verilere erişildiyse, ihlalden haberdar olmanızdan itibaren 72 saat içinde denetim otoritesine bildirimde bulunmanız gerekir; ihlalin kişiler için risk oluşturmasının muhtemel olmadığı durumlar bunun dışındadır. GDPR rehberimize bakın.
Cyber Resilience Act: içinde PHP bulunan bir yazılım ya da cihaz satıyorsanız, CRA kapsamında onun üreticisi sizsiniz. AB ortak açıklamasının da hatırlattığı gibi, 11 Eylül 2026'dan beri üreticiler ürünlerindeki aktif olarak istismar edilen güvenlik açıklarını CRA Single Reporting Platform üzerinden bildirmek zorunda. CRA rehberimize bakın.
Müşterileriniz: PHP'yi müşterileriniz için barındırıyor ya da çalıştırıyorsanız, size soracaklar. Kısa bir yazılı not (ne çalıştırdığınız, ne zaman yama uygulandığı, neyi kontrol ettiğiniz) çoğunun sorusunu yanıtlar ve bu, bir denetçinin ya da siber sigortacının görmek isteyeceği notun aynısıdır.

Acil Durumdan Sonra: Neyi Değiştirmeli?

İyi yönetilen sunucuların çoğunda PHP2Shell birkaç gün içinde yamalanmış olacak. Bu olayın kurulumunuz hakkında ortaya çıkardıkları ise sonrasında da geçerliliğini koruyacak.

Bir yamanın sizde ne kadar sürdüğünü bilin. Güvenlik duyurusundan her sunucunun yeniden başlatılmasına kadar: saatler mi, günler mi, haftalar mı? Dürüst cevap “ajansa sormamız gerekir” ise, bunu bir sonrakinden önce düzeltin. Araştırmacılar yapay zeka sayesinde istismar çalışmalarının aylardan bir haftaya indiğini söylüyorsa, saldırganların da bu hızda hareket edebileceğini varsayın.
Az önce oluşturduğunuz envanteri koruyun. Müdahalenin en zor kısmıydı ve kimse sahip çıkmadığı anda güncelliğini yitirir.
Ömrünü tamamlamış PHP'den kurtulun. 7.4 ya da 8.1'deki bir site bu kez bir sağlayıcıya ya da kaynak kodu backport'una ihtiyaç duydu; bir dahaki sefere ikisi de olmayabilir. PHP 8.2'nin kullanım ömrü 31 Aralık 2026'da sona eriyor; bu nedenle 8.1'den ayrılan bir site doğrudan 8.3 ya da daha yeni bir sürüme geçmeli. PHP sürümünü değiştirmek çoğu zaman uygulamayı da güncellemek anlamına gelir: Drupal, Umbraco ve Kentico'nun destek sonu hakkındaki yazımız bunun bir CMS için neleri kapsadığını gösteriyor.
Mümkün olan yerlerde mod_php yerine PHP-FPM'i tercih edin. Bu kez daha düşük riskli kurulum oydu.
Kullanmıyorsanız yükleme ilerlemesi (upload progress) özelliğini kapalı tutun. PHP'nin güvenlik duyurusu, uygulamanın ihtiyacı yoksa yama uygulandıktan sonra bile session.upload_progress.enabled ayarının kapalı tutulmasını öneriyor.
Yama sürelerini sözleşmelerinize yazın. Barındırma firmanıza ve ajansınıza kritik PHP düzeltmelerini ne kadar hızlı uyguladıklarını sorun ve cevabı yazılı olarak alın.

Bu Hafta İçin Kontrol Listesi

Container'lar, kontrol panelleri, üçüncü taraf ürünler ve staging sunucuları dahil her PHP kurulumunu listeleyin.
Önce internete açık sistemlere yama uygulayın; Apache mod_php ile başlayın.
Her PHP sürecini yeniden başlatın ve web sunucusunun bildirdiği sürümü kontrol edin.
Container imajlarını yeniden oluşturup yeniden devreye alın.
Bugün yama uygulayamadığınız yerlerde PHP'nin geçici ayarlarını uygulayın, trafiği bir WAF üzerinden geçirin ya da sistemi çevrimdışına alın.
Tedarikçilerinize ve barındırma firmalarınıza PHP sürümlerini ve yama tarihlerini yazılı olarak sorun.
20 Ekim'den bu yana internete açık ve yamasız kalan her şeyde logları ve dosya değişikliklerini inceleyin.
Bir bildirim yükümlülüğünün (NIS2, GDPR, CRA) geçerli olup olmadığına karar verin.
PHP 8.1 ve öncesinden, 31 Aralık'tan önce de 8.2'den çıkışı planlayın.

Size Nasıl Yardımcı Olabiliriz?

Çoğu şirkette eksik olan yama yapma isteği değil. Eksik olan, neyin çalıştığına dair net bir tablo ya da işi bu hafta yapacak insanlar. Bizim üstlendiğimiz kısım bu:

Günler içinde envanter ve yama. Sunucular, container'lar, barındırma panelleri ve tedarikçiler genelinde PHP kurulumlarınızı buluyor, yamalıyor, yeniden başlatıp doğruluyor ve size neyin ne zaman yapıldığını gösteren yazılı bir kayıt bırakıyoruz. Bu kayıt aynı zamanda müşterilerinize ve denetçilerinize vereceğiniz cevaptır.
Eski PHP'den kurtulmak. Kod daha yeni bir sürümde çalışmadığı için PHP 7.x, 8.0 ya da 8.1'de takılıp kalmış uygulamaları, eski sistem bakım hizmetimiz kapsamında desteklenen bir sürüme taşıyoruz.
Sıkılaştırma ve bir yama rutini, böylece bir sonraki güvenlik duyurusu bir acil durum değil, planlanmış bir iş olur.

Bir izinsiz giriş belirtisi bulursanız önce bir olay müdahale firmasını arayın. Yeniden kurulumu ve yükseltmeyi onlarla birlikte biz üstlenebiliriz.

Ne çalıştırdığınızı office@c9group.dev adresine yazın; ilk olarak ne yapacağımızı yanıt olarak bildirelim.

Kaynaklar

22 Ekim 2026'da kontrol edildi. Durum hâlâ değişiyor: özellikle istismar durumu ve sağlayıcı paketleri o tarihten bu yana değişmiş olabilir.

PHP projesi

Kurumlar

Araştırmacılar, firmalar ve veriler