PHP2Shell Nedir? CVE-2026-109618 ve CVE-2026-109619 PHP Güvenlik Açığı: Dünya Genelinde Etki, Nasıl Kapatılır, Saldırı Kontrol Listesi

Ne oldu? Zaman çizelgesi (PHP2Shell timeline)

PHP, sunucu tarafında çalışan dili bilinen web sitelerinin yaklaşık üçte ikisinde kullanılıyor (W3Techs: %69,3). Bu yüzden PHP motorunun kendisindeki bir açık, tek bir yazılımı değil internetin büyük bölümünü ilgilendiriyor. PHP2Shell'i farklı kılan da bu: açık bir eklentide, bir temada ya da bir çerçevede değil, PHP'nin istek işleme mantığında.

Açıkların keşfi birkaç aya yayılıyor. Yayın ise planlanandan bir gün önce, sızıntılar nedeniyle aceleyle yapıldı. Saatler UTC, parantez içinde Türkiye saati (TSİ = UTC+3):

Puan konusunda da karışıklık oldu. İlk sızan bilgilerde 10.0 yazıyordu; PHP Foundation bunun yanlış olduğunu açıkladı. Resmi puan CVSS 4.0: 9.2. NVD'de CVSS 3.1 ile 9.8, Red Hat'te 8.1 görülüyor. Hangi puana bakarsanız bakın, sonuç aynı: kritik.

İki açık sade dille (CVE-2026-109618 ve CVE-2026-109619)

PHP her isteği işlerken belli bir bellek sınırı içinde çalışır (memory_limit). Sınıra çarpan istek "acil çıkış" ile kesilir. Sorun, bu kesintinin yanlış anda olması. O zaman PHP'nin iç kayıtları ya yarım kalıyor ya da silinmiş belleği hâlâ geçerli sanıyor. Aynı PHP işçisine (worker) gelen bir sonraki istek bu bozuk belleği kullanıyor.

Saldırgan bunu tetiklemek için siteye özel hazırlanmış bir dosya yükleme isteği (multipart/form-data) gönderiyor. Sitede yükleme formu olması gerekmiyor; PHP bu tür istekleri, sitenin kodu çalışmadan önce kendisi ayrıştırıyor. Giriş yapmak da gerekmiyor.

CVE-2026-109618: Bellek tükenmesi sonrası bozulma (OOM corruption)

PHP bellek tükenince isteği longjmp() ile terk ediyor. Bu, istek belleği yalnızca kısmen hazırlanmışken olursa, istek kapanışı geçersiz bir durumu işliyor. Dosya yükleme ayrıştırıcısındaki bazı eksikler (parça başına sınırsız başlık, iç içe alan adları gibi) isteği post_max_size sınırının içinde kalarak belleği tüketmeye zorlayabiliyor. Resmi bildirime göre Apache mod_php kurulumlarında varsayılan ayarlarla tam uzaktan kod çalıştırma doğrulandı. PHP-FPM, LiteSpeed (lsphp) ve FrankenPHP de etkilenebilir. Düzeltmede longjmp() kaldırıldı, yerine güvenli noktada devreye giren "yumuşak" ve daha yüksek eşikte süreci kapatan "sert" bellek sınırı getirildi.

CVE-2026-109619: İstekten artakalan durum (stale global state)

Bir isteğe ait bazı bilgiler (hata, oturum, eklenti durumu) istek bittikten sonra da bellekte kalabiliyor. Sonraki istek, normal hazırlık bitmeden bu eski bilgiyi okuyor. Sonuç: serbest bırakılmış belleğin kullanılması (use-after-free), bellek içeriğinin sızması ve web işçisinin yetkileriyle kod çalıştırma. Resmi olarak doğrulanan iki yol var: session.upload_progress (yükleme ilerlemesi) mekanizması ve PHP 8.5'te fatal_error_backtraces ayarı. Resmi bildirimde "eksiksiz, genel bir yapılandırma önlemi yok" deniyor.

Neden "Heartbleed benzeri" deniyor?

Araştırmacıların gösterdiği zincirde, bozulan bellek içeriği yanıttaki PHPSESSID çerezinin içinde saldırgana geri gönderiliyor. Uygulama hiç oturum başlatmasa bile bu oluyor. Sızan parçada aynı sunucuya gelen başka ziyaretçilerin şifreleri, oturum anahtarları, API anahtarları, hatta TLS özel anahtarları bulunabiliyor. Bu yüzden yalnız güncellemek değil, şüphe varsa sırları değiştirmek de gerekiyor (aşağıda anlatıyoruz).

Etkilenen ve yamalı sürümler (affected versions)

Önemli bir ayrıntı: Linux dağıtımlarının paketlerinde sürüm numarası eski görünebilir. Örneğin Ubuntu 24.04'te yamalı paket 8.3.6-0ubuntu0.24.04.13; "8.3.36" yazmıyor ama yamalı. Bu sistemlerde kontrolü PHP'nin gösterdiği sürüme göre değil, paket revizyonuna göre yapın.

Çalışma biçimine göre risk de değişiyor. Apache mod_php en yüksek riskte; PHP-FPM'de oturum yükleme ilerlemesi yolu doğrulandı; LiteSpeed lsphp ve FrankenPHP kaynak analizine göre etkilenebilir; yalnız komut satırında (CLI) çalışan, web isteği almayan PHP için kaynaklarda risk tanımlanmıyor.

Dünya genelinde etki ve resmi uyarılar

PHP2Shell, son yıllarda en çok sayıda devlet kurumunun aynı gün uyarı yayımladığı açıklardan biri oldu. The Record'a göre "yüzlerce site" önlem olarak kapatıldı, "onlarca devlet kurumu" uyarı yaptı.

Önlem olarak kapatılan siteler

Kapatmaların hemen hepsi önlem amaçlıydı. 21 Ekim akşamı itibarıyla bu kurumların hiçbirinde doğrulanmış bir ihlal anlatılmıyor.

• Hollanda: Ulusal siber güvenlik merkezi NCSC-NL kendi sitesini kapattı. Ardından Overheid.nl, DigiD ve MijnOverheid, Temsilciler Meclisi, Rotterdam Limanı, futbol federasyonu KNVB, veri koruma kurumu ve bazı hastaneler geçici olarak çevrimdışı kaldı.
• Finlandiya: Devletin BT sağlayıcısı Valtori kamu ağ hizmetlerini kapattı; istismar girişimi tespit edilmediğini açıkladı.
• Danimarka: Belediyelerin BT şirketi Kombit, ulusal okul iletişim platformu dahil birkaç hizmeti durdurdu.
• Fransa: İçişleri Bakanlığı valilik ve yerel idare sitelerini geçici kapattı.
• Almanya: Federal BT hizmet sağlayıcısı ITZBund bazı siteleri kapattı; Berlin'deki Charité hastanesi ve bazı üniversiteler de önlem aldı.
• Belçika: Dışişleri Bakanlığı sitelerini geçici olarak kapattı.
• İsviçre: Bir barındırma firması müşteri paneli, webmail ve tüm web barındırmayı birkaç saatliğine kapattı; Basel Üniversitesi de önlem aldı.
• Wikimedia: Wikipedia'nın arkasındaki vakıf, Phabricator dahil bazı destek sistemlerini çevrimdışı aldı.
• Diğer: Nintendo müşteri destek hizmetleri, bazı Japon oyun ve içerik servisleri, 4chan, Something Awful, Pinboard ve disclose.tv gibi siteler de kapanan ya da bakıma alınanlar arasında geçti.

Bulut ve güvenlik tarafında da açıklamalar geldi. Google Cloud, platformun kendisinin etkilenmediğini, ancak üzerinde PHP çalıştıran müşterilerin etkilenebileceğini bildirdi. Akamai müşterilerinin korunduğunu açıkladı. Cloudflare koruma kurallarını ücretsiz plan dahil herkese açtı.

Türkiye: Siber Güvenlik Başkanlığı TR-26-1372

Türkiye'de Siber Güvenlik Başkanlığı, TR-26-1372 numaralı güvenlik bildirimini yayımladı ve ulusal ölçekte bir güvenlik taraması başlattı. Kamu kurumları, kritik altyapı işletmecileri ve özel sektöre acil uyarı gönderildi. Başkanlığın öne çıkan önerileri:

• Etkilenen sistemleri belirleyin ve yamalı sürüme hemen yükseltin.
• Yönetim arayüzlerini yalnız güvenilir IP adreslerine açın.
• Yurt dışından erişim gerekmeyen sistemlerde uluslararası trafiği kapatın.

Kamuya hizmet veren kurumların, belediyelerin, derneklerin ve sendikaların sitelerinde çoğu zaman üye ve kişisel veri tutulduğunu düşünürsek bu uyarı yalnız büyük kurumları değil, küçük ölçekli siteleri de doğrudan ilgilendiriyor.

Saldırılar başladı mı? (PHP2Shell exploitation status)

Bu noktada kaynaklar farklı şeyler söylüyor; ikisini de aktarıyoruz:

• Deneme ve tarama var: Cloudflare erken saldırı denemeleri gördüğünü ve saldırganların kuralları aşmak için yükleri değiştirdiğini yazdı. watchTowr tuzak (honeypot) ağında denemeler gördü. Bazı barındırma firmaları birden çok olay bildirdi; ancak aynı firmanın kendi telemetrisi o saatte yalnız yoklama gösteriyordu.
• Doğrulanmış ihlal yok: CISA yayın anında istismar gözlemlemedi; açıklar 21 Ekim akşamı itibarıyla bilinen istismar edilen açıklar (KEV) listesinde değildi. BSI, Huntress, Avustralya ACSC ve Hollanda NCSC de doğrulanmış istismar görmediğini bildirdi. PHP güvenlik ekibi, yayın anında çalışan genel bir saldırı kodu bulmadı.

Yama farkı (diff) ve teknik ayrıntılar artık herkese açık. Bu tür açıklarda yamadan saldırı kodu çıkarmak genelde günler, bazen saatler sürüyor. "Şimdilik ihlal yok" bilgisi, güncellemeyi ertelemek için bir sebep değil.

Nasıl kapatılır? Sistem sistem PHP güncelleme (how to patch)

Her sistemde üç adım aynı: 1) paketi güncelleyin, 2) bütün PHP işçilerini yeniden başlatın, 3) web üzerinden çalışan sürümü doğrulayın. Paketi kurmak tek başına yeterli değil; eski PHP süreçleri bellekte çalışmaya devam edebiliyor. Hosting panellerinin kendi PHP'leri ise işletim sisteminin apt/dnf güncellemesiyle güncellenmez, panelin kendi aracıyla güncellenir.

sudo apt update
sudo apt install --only-upgrade 'php8.3*'      # kullandığınız dal: php8.1 / php8.3 / php8.5
sudo systemctl restart php8.3-fpm              # FPM kullanıyorsanız
sudo systemctl restart apache2                 # mod_php: reload değil, TAM restart

# Yamalı paket revizyonları (USN-8948-1):
# 22.04: 8.1.2-1ubuntu2.28 · 24.04: 8.3.6-0ubuntu0.24.04.13 · 26.04: 8.5.4-0ubuntu1.5
# 18.04 / 20.04: Ubuntu Pro ESM ile (USN-8948-2)
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz

sudo apt-get update
sudo apt-get install --only-upgrade 'php8.2*' libapache2-mod-php8.2
dpkg -l | grep php      # Debian 12: 8.2.35-1~deb12u1 · Debian 13: 8.4.27-1~deb13u1 (DSA-6574-1)

sudo dnf clean metadata
sudo dnf upgrade 'php*'
rpm -q php-common
dnf updateinfo list --security | grep php
sudo systemctl restart php-fpm httpd

dnf upgrade 'ea-php*'       # eski sistemlerde: yum update 'ea-php*'
systemctl restart httpd
/scripts/restartsrv_apache_php_fpm

plesk installer update

da build update
da build php
# eski kurulumlarda:
cd /usr/local/directadmin/custombuild && ./build update && ./build php

# Ubuntu / Debian
apt update && apt install --only-upgrade 'lsphp8*'
apt-cache policy lsphp83          # aday sürüm gerçekten yeni mi?
# RHEL / AlmaLinux
dnf upgrade 'lsphp*'

# LiteSpeed'i yeniden başlatmak PHP süreçlerini her zaman yenilemez:
sudo pkill lsphp

docker pull php:8.3-fpm          # kullandığınız etiket
docker build --pull -t uygulamam .
docker compose up -d --force-recreate

# Windows: windows.php.net'ten yamalı derlemeyi kurun, sonra
iisreset                          # IIS FastCGI
# veya Apache hizmetini / php-cgi süreçlerini yeniden başlatın

# macOS (Homebrew)
brew upgrade php
brew services restart php

Laravel Octane veya FrankenPHP gibi uzun ömürlü süreç kullanan kurulumlarda işletim sistemi paketi gömülü PHP'yi güncellemez. FrankenPHP için yeni sürüm ya da imaj gerekir; kuyruk işçileri (queue:restart) ve Octane sunucusu yeniden başlatılmalıdır.

Güncellemeyi doğrulama (php -v yetmez)

php -v yalnız komut satırındaki PHP'yi gösterir. Web sitesine hizmet veren PHP farklı bir dal ya da farklı bir ikili olabilir. Doğrulama için:

# Silinmiş (eski) kütüphaneyi hâlâ kullanan süreç var mı? Boş çıktı = yok
sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps

# Debian / Ubuntu
sudo needrestart -b -r l

# Geçici bir dosya oluşturun, tarayıcıdan veya curl ile çağırın, HEMEN silin:
echo '<?php echo PHP_VERSION;' > /yol/site/surum-kontrol-gecici.php
curl -s https://siteniz.com/surum-kontrol-gecici.php
rm /yol/site/surum-kontrol-gecici.php

Geçici önlemler ve sınırları (PHP2Shell mitigation)

Güncellemeyi hemen yapamayanlar için geçici önlemler var. Ama PHP'nin kendi ifadesiyle eksiksiz tek çözüm güncellemek. Aşağıdakilerin hepsi riski azaltır, kapatmaz.

; php.ini
session.upload_progress.enabled = 0
; yalnız PHP 8.5:
fatal_error_backtraces = 0

; PHP-FPM havuzu (uygulama değiştiremesin diye php_admin_*)
php_admin_flag[session.upload_progress.enabled] = off

# nginx
if ($http_content_type ~* "multipart/form-data") { return 403; }

# Apache (.htaccess veya sanal sunucu)
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

İnternette dolaşan resmi olmayan "tek satırlık fix" betiklerinden ve eklentilerinden uzak durun. Hiçbiri PHP tarafından değerlendirilmedi; bir kısmı sizin sunucunuza kod çalıştırmanızı istiyor.

PHP 8.1 ve eskisi için yol haritası (end-of-life PHP)

Desteği bitmiş PHP kullanan siteler bu olayın en zor tarafında. Önerilen sıra:

1. Bugün: Envanter çıkarın. Hangi site hangi PHP sürümünde çalışıyor, test/staging sunucuları, konteynerler, panelin kendi PHP'si, cihazlara gömülü PHP dahil listeleyin.
2. Saatler içinde: Sağlayıcınızın geri taşınmış yamasını uygulayın. Ubuntu 22.04 (8.1), Ubuntu Pro ESM (18.04/20.04), cPanel ea-php74/80/81, DirectAdmin CustomBuild 7.4/8.0/8.1 ve bazı üçüncü taraf depolar bu yamaları sunuyor.
3. Yama yoksa: CISA, NSA, NCSC ve BSI'nin çizgisi açık: yamalanana ya da yükseltilene kadar çevrimdışı alın veya yalnız VPN üzerinden erişilebilir yapın. Bu da mümkün değilse en azından upload progress'i kapatın, multipart'ı engelleyin ve WAF arkasına alın; bunun kısmi koruma olduğunu bilin.
4. Günler içinde: Uygulamayı desteklenen bir dala (tercihen 8.3 veya 8.4) taşıyın. Önce test ortamında deneyin: kaldırılmış fonksiyonlar, eklenti/tema uyumu, kod şifreleyicilerin yeni dal desteği.
5. Taşınamayan eski yazılım: Statik arşiv sürümüne çevirin ya da yalnız iç ağdan erişilebilir yapın.
6. Uzun vade: PHP her dala iki yıl aktif, iki yıl güvenlik desteği veriyor. Destek takvimini izleyen bir yükseltme politikası, otomatik güvenlik güncellemesi ve işçi yeniden başlatmayı da kapsayan bir yama prosedürü kurun.

Saldırıya uğradım mı? Kontrol listesi (indicators of compromise)

Resmi bir ihlal göstergesi listesi (dosya özeti, IP listesi) henüz yayımlanmadı. Aşağıdakiler davranış göstergeleridir. Bir şey bulamamanız ihlal olmadığını kanıtlamaz. İşe başlamadan önce logların kopyasını alın; hiçbir şeyi temizlemeyin.

1. Loglar

• 20 Ekim'den bu yana olağandışı POST + multipart/form-data istekleri, özellikle yükleme formu olmayan adreslere.
• Bu istekleri izleyen "Allowed memory size exhausted" hataları ve art arda HTTP 500 yanıtları.
• Yanıtlarda olağandışı uzun ya da bozuk PHPSESSID çerezleri (bellek sızıntısının tek belgelenmiş izi).
• Açıklanamayan PHP işçi çökmeleri ("child exited on signal 11", segfault).

2. Süreçler (en güçlü sinyal)

• php-fpm, php-cgi, lsphp, httpd/apache2 altında başlayan sh, bash, python, perl, curl, wget, nc süreçleri. Windows'ta cmd.exe, powershell.exe, certutil.exe.
• Web sürecinden çalıştırılan whoami, id, uname -a; komut satırında /dev/tcp/ veya mkfifo.

3. Dosya sistemi

# Web kökünüzde 20 Ekim'den sonra oluşan/değişen PHP dosyaları
find /web/kok/dizini -name '*.php' -newermt '2026-10-20' -type f

# Yükleme dizinlerinde PHP dosyası olmamalı
find /web/kok/dizini -path '*upload*' -name '*.ph*'

# Kısa, karartılmış web shell imzaları
grep -rlE 'eval\(|base64_decode\(|gzinflate\(|assert\(|shell_exec\(|passthru\(' /web/kok/dizini --include='*.php'

• /tmp ve /dev/shm altında çalıştırılabilir dosya veya PHP dosyası.
• Yeni cron işleri, yeni yönetici hesapları, authorized_keys değişiklikleri.
• .htaccess, .user.ini veya auto_prepend_file eklemeleri.

4. Şüphe varsa

• Sunucuyu izole edin, web ve PHP loglarını saklayın.
• Sırları değiştirin: veritabanı şifreleri, .env içindeki API anahtarları, ödeme sağlayıcı anahtarları, SMTP şifreleri, uygulama gizli anahtarları, OAuth token'ları; gerekirse TLS sertifikasını yeniden alıp eskisini iptal edin.
• Tüm kullanıcı oturumlarını geçersiz kılın, yönetici şifrelerini değiştirin, iki aşamalı doğrulamayı zorunlu yapın.
• Gerekirse temiz bir yedekten yeniden kurun. Kurum içinde kapasite yoksa bir olay müdahale ekibiyle çalışın.

KVKK: 72 saatlik bildirim yükümlülüğü

Saldırı sonucunda kişisel verilere yetkisiz erişildiğini öğrenirseniz, 6698 sayılı Kişisel Verilerin Korunması Kanunu'na göre veri sorumlusu olarak durumu öğrendiğiniz andan itibaren 72 saat içinde Kişisel Verileri Koruma Kurulu'na bildirmeniz gerekir. Etkilenen kişilere de makul en kısa sürede bilgi verilmelidir. Kurulun internet sitesinde veri ihlali bildirim formu bulunuyor.

Dernek, vakıf ve sendika üyeliği KVKK'da özel nitelikli kişisel veri sayılıyor. Dernekler VERBİS kaydından muaf olsa da veri güvenliği ve ihlal bildirimi yükümlülükleri devam ediyor. Üye listesi tutan bir dernek veya sendika sitesinde PHP2Shell kaynaklı bir şüphe, sıradan bir site arızası gibi ele alınmamalı.

Sahte $PHP2SHELL kripto ve sahte PoC uyarısı

Her büyük güvenlik olayında olduğu gibi dolandırıcılar da işe koyuldu:

• Sahte "$PHP2SHELL" token'ı: X'te (Twitter) açığın adını taşıyan sahte bir kripto para (memecoin) tanıtılıyor. Bu tür paylaşımlar çoğu zaman ele geçirilmiş hesaplardan yapılıyor. PHP projesinin, PHP Foundation'ın ya da açığı bulan araştırmacıların böyle bir token'ı yok. Cüzdan bağlamayın, para göndermeyin.
• Sahte saldırı kodları (PoC): GitHub ve benzeri sitelerde "PHP2Shell exploit" adlı çok sayıda depo var. Hiçbirinin çalıştığı doğrulanmadı. Bu tür depolar meraklı yöneticileri ve araştırmacıları hedefleyen zararlı yazılım taşıyabiliyor. Sunucunuzda veya kişisel bilgisayarınızda çalıştırmayın; incelemeniz gerekiyorsa yalnız izole bir test ortamında yapın.
• "Sitenizde açık bulduk" e-postaları: Olay gündemdeyken site sahiplerine ücretli "acil yama" veya "tarama" teklif eden istenmeyen e-postalar artar. Göndereni doğrulamadan link tıklamayın, sunucu erişimi vermeyin.

Site sahipleri için kısa yapılacaklar listesi

1. Sitenizin PHP ile çalışıp çalışmadığını ve hangi sürümü kullandığını öğrenin (barındırma firmanıza sorun).
2. Barındırma firmanızdan PHP'nin 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 veya dağıtımın yamalı paketine güncellendiğinin ve işçilerin yeniden başlatıldığının yazılı teyidini alın.
3. Kendi sunucunuz varsa yukarıdaki adımlarla güncelleyin ve web tarafında doğrulayın.
4. PHP 8.1 veya daha eskisini kullanıyorsanız ya yamalı pakete geçin ya da siteyi geçici olarak kapatıp yükseltmeyi planlayın.
5. Güncelleme gecikiyorsa session.upload_progress.enabled=0, yükleme kullanmıyorsanız multipart engelleme ve WAF uygulayın.
6. 20 Ekim sonrası logları ve yeni oluşan PHP dosyalarını kontrol edin.
7. Şüphe varsa veritabanı ve API şifrelerini değiştirin, oturumları sıfırlayın.
8. Kişisel veri etkilendiyse 72 saat içinde KVKK'ya bildirin.
9. Sahte kripto ve sahte exploit paylaşımlarına itibar etmeyin.

Alesta WEB'in barındırdığı sistemlerde durum

Alesta WEB'in barındırdığı ve yönettiği sistemlerde PHP, yamaların yayımlandığı gün yamalı sürümlere güncellendi ve PHP işçileri yeniden başlatıldı. Geçici önlemler kullanılan tüm PHP sürümlerinde açıldı. Saldırı izi taraması (loglar, yeni dosyalar, şüpheli süreçler) temiz çıktı. Müşterilerimizin bu konuda ayrıca bir işlem yapması gerekmiyor.

Sitesi başka bir yerde barındırılan ve PHP2Shell için destek almak isteyenler admin@alestaweb.com adresinden ya da 0505 532 36 38 numarasından Alesta WEB'e ulaşabilir. İletişim sayfası üzerinden de yazabilirsiniz.

Sık sorulan sorular

Sitemde WordPress gibi bir CMS var, eklentileri güncelledim. Yeterli mi?

Hayır. Açık PHP'nin içinde. CMS, eklenti veya tema güncellemesi bu açığı kapatmaz; sunucudaki PHP'nin güncellenmesi gerekir. Araştırmacılar WordPress gibi PHP tabanlı yaygın sistemlerde ve hatta tek satırlık bir "Hello World" uygulamasında bile kimlik doğrulamasız kod çalıştırmayı gösterdi.

Paylaşımlı hosting kullanıyorum. Ne yapmalıyım?

PHP'yi siz değil barındırma firması günceller. Firmanıza yazın ve güncellemenin yapıldığını, işçilerin yeniden başlatıldığını teyit edin. Panelinizde PHP sürümü seçme imkânı varsa desteklenen bir dal (8.3 veya 8.4) seçin.

PHP-FPM kullanıyorum, risk daha mı düşük?

Apache mod_php'ye göre saldırı daha zor olabilir ama FPM'de de yükleme ilerlemesi yolu doğrulandı. Risk düşük değil; güncelleme şart.

Cloudflare arkasındayım, güvende miyim?

Cloudflare kuralları bilinen kalıpları engelliyor, ama yalnız Cloudflare'den geçen trafiği koruyor. Sunucunuzun IP adresi biliniyorsa saldırgan doğrudan bağlanabilir. Ayrıca saldırganlar yükleri değiştiriyor. WAF ek katmandır, güncellemenin yerini tutmaz.

php -v yeni sürümü gösteriyor, iş bitti mi?

Bitmeyebilir. php -v komut satırı PHP'sini gösterir. Web'e hizmet veren PHP başka bir ikili olabilir ve eski süreçler bellekte çalışmaya devam edebilir. İşçileri yeniden başlatıp web üzerinden geçici bir sürüm sayfasıyla kontrol edin, sonra o sayfayı silin.

PHP 7.4 kullanıyorum, ne olacak?

PHP projesi 7.4 için resmi sürüm çıkarmadı. Sağlayıcınızın geri taşınmış yaması varsa uygulayın; yoksa siteyi geçici olarak kapatıp desteklenen bir dala geçin. Resmi kurumların önerisi bu yönde.

Saldırıya uğradığımı nasıl anlarım?

Yukarıdaki kontrol listesindeki log, süreç ve dosya kontrollerini yapın. Bir iz bulursanız sunucuyu izole edin, sırları değiştirin ve kişisel veri söz konusuysa 72 saatlik KVKK bildirim süresini unutmayın.

İlgili yazılar: PHP 8.6 yenilikleri · nginx güvenlik güncellemesi · Web hosting · Web yazılım hizmetleri · İletişim

Kapak fotoğrafı: Christina @ wocintechchat.com M / Unsplash