PHP2Shell: Yama Gelmeyen Sunucuya Yangın Kapısı

Bugün, 21 Ekim 2026'da saat 14:00 UTC'de (İstanbul'da 17:00) PHP ekibi dört sürümü aynı anda yayımladı: 8.5.12, 8.4.27, 8.3.36 ve 8.2.35. Hepsi iki kritik açığı kapatıyor: CVE-2026-109618 ve CVE-2026-109619. Sızıntıyla birlikte adı PHP2Shell oldu. İkisi de CVSS v4 ölçeğinde 9.2 ve ikisi de kimlik doğrulaması olmadan uzaktan kod çalıştırmaya (RCE) kapı açıyor.

Güncelleyebilen için iş basit: güncelle, servisleri yeniden başlat, bitti. Bu yazı öbür sunucular için. PHP 7.4'te unutulmuş müşteri sitesi, panelin kendi derlediği 8.1, "bu hafta dokunamayız" denen e-ticaret sunucusu. Onlara yama bugün gelmiyor, bazılarına hiç gelmeyecek. Aşağıda bu sunucuları nasıl koruma altına alacağınızı, hangi önlemin neyi kapatıp neyi kapatmadığını ve işi bir AI ajanına verecekseniz kullanabileceğiniz hazır görev metinlerini bulacaksınız.

Önce şunu baştan söyleyeyim, çünkü yazının geri kalanı bunun üstüne kurulu: geçici önlemler yangın kapısıdır. Yangını söndürmez, zaman kazandırır. PHP'nin kendi danışma metni de aynı şeyi söylüyor: bu önlemler belirli saldırı yollarını daraltır, "kurulumu güvenli hâle getirmez".

PHP2Shell nedir, ne zaman ortaya çıktı?#

Kronoloji kısa ve hızlı:

• 20 Ekim 2026, 19:33 UTC: PHP güvenlik ekibi adına Jakub Zelenka ön duyuruyu yayımladı: ertesi gün 14:00 UTC'de iki kritik açık için güvenlik sürümü, ayrıntılar sızarsa daha erken.
• 20 Ekim: Ayrıntılar koordineli açıklamadan önce sızdı. Huntress'in aktarımına göre watchTowr açıkların gerçek olduğunu doğruladı ve birini yeniden üretti.
• 21 Ekim, 14:00 UTC: Dört sürüm ve resmi güvenlik duyurusu yayında.

İki açık, resmi danışma kayıtlarındaki tanımlarıyla:

• CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w). PHP bellek bittiğinde isteği longjmp() ile keserek durduruyor. Bu kesinti, isteğe ait iç veri yarım kurulmuşken gelirse istek kapanışı o yarım veriyi geçerli sanıyor. Danışmaya göre birkaç multipart ayrıştırma sorunu, PHP'nin kendi sınırları içinde görünen bir isteği bellek tükenmesine itebiliyor.
• CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp). Bir isteğe ait iç durum, belleği serbest bırakıldıktan sonra worker'da kalabiliyor; aynı worker'ın bir sonraki isteği, normal başlatma onu sıfırlamadan bu bayat durumu kullanabiliyor (CWE-416, use after free). Doğrulanmış iki yol var: istek başlamadan uygulanan INI ayarlarının ürettiği uyarılar ve oturum yükleme ilerlemesi (session upload progress).

Kim risk altında? Resmi duyuru tek cümleyle söylüyor: web isteği karşılayan bütün PHP kurulumları. PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed. Riskin en yüksek olduğu yer mod_php: orada kimlik doğrulamasız bir isteğin, uygulama kodunuz daha hiç çalışmadan saldırıyı tetiklediği gösterilmiş. Bu cümlenin pratik anlamı şu: WordPress'in, Laravel'in ya da kendi yazdığınız çerçevenin bakım modu sizi korumaz. İstek uygulamaya ulaşmadan PHP tarafından ayrıştırılıyor.

İstismar durumu: Kaynaklar burada ayrışıyor, ben de ayrışık yazıyorum. Patchstack 21 Ekim 07:34 UTC güncellemesinde birden fazla aktif istismar vakasını doğruladığını yazdı. Huntress yayın anında kendi müşteri ortamlarında istismar görmemişti; CERT-EU'nun 2026-018 danışması da ilk sürümünde teknik ayrıntıların kamuya açık olmadığını söylüyordu. Sürümler artık yayında, düzeltme commit'leri herkesin önünde. Sızıntı ile yama arasındaki sessizlik bitti; saldırganın elinde artık hem iddia hem fark var.

Açıkları bildirenler danışma kayıtlarında GitHub hesaplarıyla anılıyor: lcfr-hax, sagitzadik-wiz, tomash-areion ve amyb-oai. Düzeltmeyi geliştirenler arnaud-lb, iluuu1994, bukka ve ndossche. Bir gecede dört dala ve üç emekli dala yama çıkarmak gönüllü emeğin ağır ucu; teşekkürü baştan hak ediyorlar.

Hangi PHP'desiniz? Sürüm numarası yalan söyleyebilir#

PHP sürüm yükseltme yazısında yazmıştım: sürüm numarası tek başına yalan söyleyebilir. Bugün bunun iki yönü de önemli.

Debian, Ubuntu, RHEL ve türevlerinin depo paketlerinde dağıtım yamayı eski numaranın üstüne geri taşır. Ubuntu'daki 8.3.6 yamalı olabilir; belirleyici olan numara değil, paketin değişiklik kaydı. Duyuruya göre dağıtımlar ve LTS sağlayıcıları yamaları önceden aldı. Öbür yönde, panelin (CWP, cPanel'in EasyApache'i ve benzerleri) kendi derlediği PHP'de geri taşıma yoktur; o binary derlendiği günün kodudur ve ancak yeniden derlenince yamalanır.

Bir uyarı daha resmi duyurudan: gönüllülerce sürdürülen rpms.remirepo.net deposu bugün güncelleme almayacak. O depoya bağlıysanız ya dağıtımın paketine geçin ya da kaynaktan derleyin.

# Hangi PHP? Kimin derlemesi?
php -v
which -a php php-fpm php-fpm8.3 2>/dev/null
dpkg -l | grep -E '^ii +(php|libapache2-mod-php)'   # Debian/Ubuntu
rpm -qa | grep -i '^php'                             # RHEL/AlmaLinux
​
# Dağıtım paketiyse: CVE değişiklik kaydında var mı?
apt changelog php8.3-fpm 2>/dev/null | grep -m1 CVE-2026-109618
rpm -q --changelog php-fpm | grep -m1 CVE-2026-109618

Değişiklik kaydında CVE yoksa ya da paket yöneticisi o PHP'yi hiç tanımıyorsa, o sunucuyu yamasız kabul edin.

Bir tuzak daha var ve onu bu yazı için kurduğum test ortamında birebir gördüm. CLI'nin söylediği, web'in yaşadığı değil. Aynı makinede, aynı PHP 8.3.6 ile aşağıdaki betik CLI'de oturum yükleme ilerlemesini açık gösterdi; Apache mod_php üzerinden çalışan sayfa kapalı. Çünkü CLI ile web SAPI ayrı php.ini okuyor. Ayarı terminalden kontrol edip "kapattım" demek, yanlış kapıya kilit takmak demek. Kontrolü web üzerinden yapın:

<?php
declare(strict_types=1);
​
/**
 * CVE-2026-109618 / CVE-2026-109619 (PHP2Shell) hızlı durum raporu.
 * Web SAPI'nin gerçek ayarlarını görmek için web üzerinden çalıştırın;
 * CLI'nin php.ini'si FPM/mod_php'ninkiyle aynı olmayabilir.
 * İş bitince dosyayı silin: sürüm bilgisini dışarıya açık bırakmayın.
 */
function php2shellDurumu(): array
{
    $yamali = ['8.2' => '8.2.35', '8.3' => '8.3.36', '8.4' => '8.4.27', '8.5' => '8.5.12'];
    $dal = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;
​
    if (isset($yamali[$dal])) {
        $surum = version_compare(PHP_VERSION, $yamali[$dal], '>=')
            ? 'YAMALI'
            : 'YAMASIZ GÖRÜNÜYOR: ' . $yamali[$dal] . ' gerekli (dağıtım paketiyse değişiklik kaydına bakın)';
    } elseif (version_compare(PHP_VERSION, '8.2.0', '<')) {
        $surum = 'DESTEK DIŞI: dağıtım/LTS backport\'u yoksa yamasız kabul edin';
    } else {
        $surum = 'BİLİNMEYEN DAL: elle kontrol edin';
    }
​
    $uyari = [];
    if (ini_get('session.upload_progress.enabled')) {
        $uyari[] = 'session.upload_progress.enabled açık';
    }
    if (ini_get('memory_limit') !== '-1') {
        $uyari[] = 'memory_limit sınırlı (' . ini_get('memory_limit') . ')';
    }
    if (PHP_VERSION_ID >= 80500 && ini_get('fatal_error_backtraces')) {
        $uyari[] = 'fatal_error_backtraces açık';
    }
​
    return [
        'surum'    => PHP_VERSION,
        'sapi'     => PHP_SAPI,
        'durum'    => $surum,
        'post_max' => ini_get('post_max_size'),
        'uyarilar' => $uyari,
    ];
}
​
header('Content-Type: text/plain; charset=utf-8');
echo json_encode(php2shellDurumu(), JSON_PRETTY_PRINT | JSON_UNESCAPED_UNICODE), "\n";

Bu betik php -l'den geçti; CLI'de, Apache mod_php'de ve FPM'de çalıştırdım. Rastgele bir adla koyun, sonucu okuyun, silin.

Yamalı dallar ve emekliler#

Son iki satır bugünün asıl haberi. Ciddiyet yüzünden güvenlik ekibi emekli dallar için de kaynak yaması yayımladı: PHP-7.4, PHP-8.0 ve PHP-8.1 dalları depoda duruyor; bugün git ls-remote ile üçünün de varlığını kontrol ettim. Bunlar yeni sürüm değil, kaynaktan derleyenlere ve LTS sağlayıcısı olmayanlara uzatılmış bir el. Panelin derlediği 8.1'i kullanıyorsanız, panelin bu dalı ne zaman derleyeceğini sağlayıcınıza sorun; sormadan beklemeyin.

7.3, 7.2 ve PHP 5 için ne resmi sürüm ne kaynak yaması var. O sunucular için aşağıdaki kapıların hepsi geçici değil, kalıcı yaşam desteği.

Yama gelmeyen sunucu: dört yangın kapısı#

Kapıları dıştan içe sıraladım. Dıştaki, isteği PHP'ye hiç ulaştırmadığı için en güçlüsü; içteki, en az şeyi kapatanı. Her kapının altına neyi kapatmadığını da yazdım.

1. Web sunucusunda multipart'ı kesmek#

Danışmalara göre OOM açığında belleği tüketen yol multipart ayrıştırma, bayat durum açığında doğrulanmış yollardan biri oturum yükleme ilerlemesi; o da yalnızca multipart/form-data isteklerde devreye giriyor. OOM danışması da, uygulamanız multipart kullanmıyorsa bu istekleri ön tarafta engellemeyi öneriyor. Bu, isteği PHP'ye hiç göstermemek demek.

Apache 2.4 (vhost'a ya da conf-available/ altına):

# PHP2Shell (CVE-2026-109618 / CVE-2026-109619) geçici kalkan.
# multipart/form-data POST'u PHP'ye ulaşmadan reddeder.
# Yönetim IP bloğunuzu istisnaya yazın; dosya yüklemesi o IP'den çalışır.
<If "%{REQUEST_METHOD} == 'POST' && req('Content-Type') =~ m#multipart/form-data#i && ! -R '203.0.113.0/24'">
    Require all denied
</If>
LimitRequestBody 8388608
LimitRequestFields 50

nginx (server bloğuna):

# PHP2Shell geçici kalkan: PHP'ye multipart gitmesin.
client_max_body_size 8m;
set $p2s_block 0;
if ($content_type ~* "multipart/form-data") { set $p2s_block 1; }
if ($remote_addr = "203.0.113.10") { set $p2s_block 0; }
if ($p2s_block) { return 403; }

İkisini de test ortamında beş istekle denedim. Normal GET ve form POST'u (urlencoded) 200; -F ile gönderilen multipart, büyük harfle yazılmış MULTIPART/FORM-DATA başlığı ve Content-Length taşımayan chunked multipart, üçü de 403. Apache'de 9 MB'lık gövde 413 döndü, istisna IP'den gelen multipart 200. Danışma, ön taraf sınırlarının Content-Length taşımayan istekleri de kapsaması gerektiğini özellikle yazıyor; chunked denemesini bu yüzden ekledim.

Bedeli: Dosya yükleme, multipart gönderen formlar ve varsa multipart gövdeyle gelen üçüncü taraf geri çağrıları (webhook) kırılır. WordPress medya yüklemesi, WooCommerce ürün görseli, "CV'nizi ekleyin" formu durur. İstisnayı yol üzerinden değil, IP üzerinden verin; yol istisnası saldırgana hangi kapının açık olduğunu söyler.

Kapatmadığı: Danışmalar başka varyantların da olabileceğini açıkça söylüyor; multipart dışı bir yol bulunursa bu kapı onu görmez. İmza tabanlı WAF kuralları için de aynısı geçerli: WAF multipart gövdesini PHP'den farklı ayrıştırabilir ve bir imza ancak bilinen yolu yakalar. Bu kapının gücü imzada değil, multipart'ı topyekûn kesmesinde.

2. PHP ayarları: uygulamanın ezemeyeceği yerde#

Resmi duyurudaki ayarlar şunlar. Kritik ayrıntı yerleri: istek ayrıştırılmadan önce uygulanmalı ve uygulama tarafından geri alınamamalı. ini_set() ve FPM'in .user.ini dosyası yetmez, duyuru ikisini de adıyla dışlıyor.

PHP-FPM havuzu (pool.d/www.conf ya da sitenin havuzu):

; PHP2Shell geçici kalkan (havuz başına)
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
; Danışmanın "performans izin veriyorsa" önerisi: her istekte yeni worker
pm.max_requests = 1

Apache mod_php:

<IfModule mod_php.c>
    php_admin_flag  session.upload_progress.enabled off
    php_admin_value memory_limit -1
    php_admin_value post_max_size 8M
    php_admin_value upload_max_filesize 4M
</IfModule>

PHP 8.5 kullanıyorsanız buna fatal_error_backtraces=0 ekleyin; danışmaya göre 8.5'te mod_php'ye karşı doğrulanmış RCE yolu bu özellik üzerinden geçiyor. Dosya yüklemesi gerekiyorsa post_max_size için duyurunun üst sınırı 32M; upload_max_filesize her zaman ondan küçük kalmalı.

FPM havuzunu php-fpm8.3 -t ile doğruladım ve FastCGI üzerinden gönderdiğim istekte üç ayar da beklendiği gibi okundu (0 -1 8M). mod_php'de aynı ayarları .htaccess içinde php_flag ... on ve php_value memory_limit 64M ile ezmeyi denedim; php_admin_* yerinde kaldı. Kapı bunun için admin.

Ayarı yazdıktan sonra bütün worker'ları yeniden başlatın. Bayat durum worker'da yaşıyor; eski worker ayakta kaldıkça yeni ayar onu temizlemez.

Neden memory_limit=-1? Saldırganın kontrol edebildiği "bellek sınırına çarptım" anını ortadan kaldırmak için. Ama bedava değil: artık tek bir istek sunucunun bütün belleğini isteyebilir. Danışma bu yüzden sınırı PHP'den alıp işletim sistemine vermeyi öneriyor: container ya da cgroup sınırı, tercihen yalnızca o worker'ı öldüren bir politikayla. RLIMIT_AS ve RLIMIT_DATA kullanmayın; danışmaya göre tam da açığın beslendiği bellek tahsisi hatasını üretiyorlar. Danışma ayrıca şunu da ekliyor: bu ayar kontrol edilebilen hatayı kaldırıyor, ama alttaki gerçek bir bellek tahsisi hatası yine savunmasız yola ulaşabilir.

Kapatmadığı: session.upload_progress.enabled=0 doğrulanmış oturum yollarını kapatıyor, öbür varyantları değil. Duyurunun cümlesi: hataları error_reporting, display_errors ya da @ ile gizlemek işe yaramaz. İstek başına uygulanan geçersiz ya da kullanımdan kalkmış INI ayarlarını temizleyin, saldırganın tetikleyebileceği fatal error ve zaman aşımlarını düzeltin.

3. Ağdan çekmek#

7.3 ve öncesi için, yamasını derleyemediğiniz her 7.4/8.0/8.1 için ve bugün yukarıdaki iki kapıyı test edemeyecekseniz: sunucuyu internetten çekin. CERT-EU'nun önerisi de bu: hemen yamalanamayan, internete açık uygulamaları kamu ağlarından izole etmek.

Pratikte üç seçenek var. Yönetim paneli, iç araç ya da müşteri portalı gibi herkesin girmesi gerekmeyen siteleri VPN ya da IP izin listesinin arkasına alın. Halka açık kalması gereken site için önce kısa bakım sayfası, sonra yalnızca okuma: ters vekil (reverse proxy) yalnızca GET ve HEAD geçirsin. Hiçbiri olmuyorsa siteyi bugün kapatıp yarın 8.x'e taşımak, yarın sunucuyu sıfırdan kurmaktan ucuzdur.

4. İz sürmek: kapıdan biri geçti mi?#

PHP2Shell için henüz yayımlanmış bir IOC (ele geçirilme göstergesi) listesi yok. Huntress'in önerisi davranışa bakmak: PHP worker'ının altında kabuk (sh, bash), yorumlayıcı (python, perl), indirme aracı (curl, wget, nc) ya da whoami, id, uname -a gibi keşif komutları belirmesi.

# PHP/web worker'larının doğrudan çocukları arasında yabancı süreç var mı?
P=$(pgrep -d, -x 'php-fpm.*|apache2|httpd|php-cgi.*|lsphp.*')
[ -n "$P" ] && ps --ppid "$P" -o pid,ppid,user,etime,cmd --no-headers \
  | grep -vE 'php-fpm|apache2|httpd|php-cgi|lsphp'
​
# Son iki günde web kökünde değişen PHP dosyaları
find /var/www -name '*.php' -mtime -2 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
​
# Web kullanıcısının cron'u
crontab -l -u www-data 2>/dev/null

İlk komutun ilk sürümü test ortamında ilgisiz süreçleri de topluyordu; --forest çıktısını grep -A ile kesmek ağacın komşu dallarını da getiriyor. Yukarıdaki hâli yalnızca worker'ların doğrudan çocuklarına bakıyor: temiz sunucuda boş döndü, apache2 adlı bir sürecin altında sh başlattığımda o satırı yakaladı. Torunları görmez; şüphe varsa ps -ef --forest ile ağacın tamamını gözle okuyun. Dolu dönerse sunucuyu ağdan ayırın, web sunucusu ve PHP günlüklerini koruyun, web kökündeki yeni dosyalara, cron'lara ve yeni kullanıcılara bakın. Temizlemeye kalkmadan önce kanıtı saklayın.

AI ajanları için hazır görev metinleri#

Yüz sunuculu bir müşteri listesinde bu işi elle yapmak bir gün sürer; bir ajana yaptırmak bir saat. Ama Kentsel Dönüşüm #1'de yazdığım kural burada iki kat geçerli: ajana önce okutun, yazdırmayın. "Salt okuma" her araçta başka bir şey; Claude Code'un plan modu, Codex'in --sandbox read-only kipi, OpenCode'un Plan ajanı ve Cursor'un Ask modu aynı sınırı çizmiyor. Canlı sunucuya bağlı bir ajanı hangisiyle çalıştırırsanız çalıştırın, yeniden başlatma ve yapılandırma yazma yetkisini görev metniyle değil, aracın izin ayarıyla kapatın. Metin niyeti söyler, izin sınırı çizer.

Aşağıdaki üç metin araç bağımsız. Sırayla kullanın: önce envanter, sonra kalkan, en son güncelleme.

Görev 1: Envanter (salt okuma)#

Görev: PHP2Shell (CVE-2026-109618 / CVE-2026-109619) envanter raporu.
Bu sunucuda HİÇBİR dosyayı değiştirme, paket kurma veya kaldırma, servis
yeniden başlatma. Yalnızca okuma komutları çalıştır. Raporu bu sohbete yaz.
​
Yamalı sürümler: 8.5.12, 8.4.27, 8.3.36, 8.2.35. 8.1 ve öncesi resmi
sürüm almıyor.
​
Her PHP kurulumu için tabloya yaz:
- Yol ve sürüm (php -v, which -a, panelin PHP dizinleri)
- Kaynak: dağıtım paketi mi, panel derlemesi mi, elle derleme mi
- Dağıtım paketiyse: değişiklik kaydında CVE-2026-109618 geçiyor mu
- SAPI: FPM havuzları, mod_php, php-cgi; hangi site hangisini kullanıyor
- Web SAPI'nin gördüğü değerler (CLI'yi ölçü alma):
  session.upload_progress.enabled, memory_limit, post_max_size,
  (8.5 ise) fatal_error_backtraces
- Bu değerler nerede tanımlı: php.ini, havuz, vhost, .htaccess, .user.ini
- Sitenin multipart/form-data kullanıp kullanmadığı (dosya yükleme, form)
​
Son bölüm: Okuyarak doğrulayamadığın şeyler. Şifre, anahtar ve .env
değerlerini rapora yazma; maskele.

Görev 2: Geçici kalkan (onay kapılı)#

Görev: Görev 1 raporundaki YAMASIZ sunucular için PHP2Shell geçici kalkanı
hazırla. Kalkan yamanın yerine geçmez; bunu raporda açıkça yaz.
​
Kurallar:
1. Değiştireceğin her dosyanın önce yedeğini al (dosya.bak-YYYYMMDD-HHMM).
2. Önerdiğin değişikliği diff olarak göster ve ONAYIMI BEKLE. Onay
   vermeden hiçbir yapılandırma dosyasına yazma.
3. Onaydan sonra önce sözdizimini doğrula (apachectl configtest,
   nginx -t, php-fpmX.Y -t). Hata varsa yedeği geri koy ve dur.
4. Servis yeniden başlatma komutunu ÇALIŞTIRMA; bana göster, ben çalıştırırım.
​
Kalkanın parçaları:
- Web sunucusunda multipart/form-data POST'u 403 ile reddet; şu yönetim
  IP'lerini istisna tut: <IP listesi>. Dosya yüklemesi kullanan siteleri
  listele ve bu siteler için kararı bana bırak.
- Gövde sınırı: post_max_size 8M (yükleme gerekiyorsa 32M),
  upload_max_filesize bundan küçük; web sunucusunda da aynı sınır.
- FPM havuzu ya da Apache yapılandırmasında php_admin_* ile:
  session.upload_progress.enabled=off, memory_limit=-1;
  PHP 8.5 ise fatal_error_backtraces=0. ini_set() ve .user.ini kullanma.
- memory_limit=-1 için servis düzeyinde bellek sınırı öner (cgroup /
  systemd MemoryMax). RLIMIT_AS ve RLIMIT_DATA önerme.
​
Yeniden başlatmadan sonra doğrulama komutlarını ver: GET 200, urlencoded
POST 200, multipart POST 403, chunked multipart POST 403 ve web üzerinden
ayar kontrolü.

Görev 3: Güncelleme (bakım penceresinde)#

Görev: Desteklenen dallardaki PHP kurulumlarını yamalı sürüme taşıma planı
çıkar: 8.5 -> 8.5.12, 8.4 -> 8.4.27, 8.3 -> 8.3.36, 8.2 -> 8.2.35.
​
Önce plan, sonra iş. Her sunucu için:
- Kaynağa göre yöntem: dağıtım paketi (apt/dnf güncellemesi), panel
  derlemesi (panelin yeniden derleme adımı), kaynak derleme.
  rpms.remirepo.net kullanan sunucuları ayrıca işaretle; o depo bugün
  güncelleme almıyor.
- 8.1, 8.0, 7.4: LTS sağlayıcısı var mı; yoksa php-src'deki
  PHP-X.Y-CVE-2026-109618-109619 kaynak yaması dalı ya da 8.2+'ya geçiş.
- 7.3 ve öncesi: güncelleme yolu yok, izolasyon ve geçiş planı yaz.
​
Kurallar: Canlı sunucuda paket kurma veya derleme komutunu ONAYIM olmadan
çalıştırma. Önce yedek ve geri dönüş adımını yaz. Güncellemeden sonra
bütün PHP worker'larının yeniden başladığını (eski süreç kalmadığını)
kontrol et ve web üzerinden sürümü doğrula. Geçici kalkanı kaldırmayı
ayrı bir adım olarak öner; session.upload_progress kullanılmıyorsa
danışmanın önerisiyle kapalı kalsın.

Üç metinde de ortak olan şey "onayımı bekle" cümlesinin varlığı değil, nerede durduğu: yazmadan önce, yeniden başlatmadan önce, kurmadan önce. Ajan hızlıdır; canlı sunucuda hız, yanlış komutun da hızlı çalışması demektir.

Ne zaman yetmez?#

Bu kapılar zaman kazandırır, sunucuyu güvenli yapmaz. Danışmalarda geçen cümleler net: güncelleme "tek eksiksiz çözüm", yapılandırmayla tam bir azaltma "yok". Multipart engeli sitenizin bir kısmını kırar ve sonsuza kadar açık tutulacak bir şey değildir. memory_limit=-1 cgroup sınırı olmadan başka bir kapıyı, tek isteğin sunucuyu düşürmesini açar. pm.max_requests=1 yoğun sitede yükü belirgin artırır. Temiz günlük de kanıt değildir; danışma bunu da yazıyor.

Kapıları bugün kurun, takvime de bugün yazın: hangi sunucu hangi gün yamalı dala geçecek, hangisi hangi gün kapanacak.

Yangın kapısı yangını söndürmez#

Ön duyurudan yamaya on dokuz saat bile geçmedi. Yamalı sürümler ortada, emekli dallar için bile kaynak yaması var. Bu yazıdaki her ayarın, her kuralın tek amacı o yamaya kadar dayanmak.

Kapıyı kapatın, merdiveni boşaltın, itfaiyeyi çağırın. Sırası bu. Kapıyı kapatıp binada oturmaya devam etmek, yangını kabullenmektir.

Teknolojiyle kalın, sürümlerinizi taze tutun.