Mənbələr 22 oktyabr 2026-cı il tarixinə yoxlanılıb. Audience: PHP proqram operatorları, təhlükəsizlik cavabdehləri və fərdi PHP quruluşlarına qulluq edən mühəndislər.

Bu məqalə PHP2Shell zəifliyinin səbəbini, təsir dairəsini, rəsmi təmir prosesini, müvəqqəti azaldıcı tədbirləri və rəsmi yamağın tətbiqini ümumiləşdirir. Əsas mətn S1 kimi nömrələrdən istifadə etməklə istinad edilir; bütün mənbə bağlantıları mətnin sonundakı əlavədə verilmişdir. Konfiqurasiya fraqmenti yerləşdirmə şablonudur və onu faktiki versiyaya, iş gücünə və konfiqurasiya irsi əlaqəsinə əsasən tənzimləmək lazımdır.

TL;DR: Təmir addımları və təkliflər

  1. PHP iş vaxtını təkmilləşdirin: müvafiq filialı ən azı 8.2.35, 8.3.36, 8.4.27 və ya qədər təkmilləşdirin 8.5.12. Dağıtım paketləri üçün satıcının hər iki CVE-nin düzəldilməsini təsdiq etdiyi tam paket versiyasından istifadə edin. S1S10
  2. Bütün köhnə prosesləri dəyişdirin: təkmilləşdirildikdən sonra hər PHP worker, hosting xidməti və konteyneri yenidən başladın və ya üzərinə yuvarlayın və köhnə instansiyaların çıxdığını təsdiqləyin.
  3. Faktiki Web sorğu yolu ilə doğrulayın: Web SAPI, tam paket versiyasını və işləyən nümunəni yoxlayın. Təkcə php -v-nin yoxlanılması canlı xidmətin sabit olduğunu müəyyən etmir.
  4. Biznes reqressiyasını yoxlayın və normal resurs büdcələrini bərpa edin: test girişi, sessiyanın idarə edilməsi, yükləmələr, idxal və xətaların idarə edilməsi. PHP yaddaş limiti müvəqqəti olaraq silinibsə, yamaqdan sonra müvafiq sonlu büdcəni bərpa edin.
  5. Əgər dərhal təkmilləşdirmə mümkün deyilsə: PHP-ə çatmamış etibarsız trafiki məhdudlaşdırın. Bölmə 5-də təsvir olunduğu kimi yükləmə tərəqqisinin və PHP 8.5 ölümcül geri izlərin söndürülməsini qiymətləndirin. Konfiqurasiyanın azaldılması və WAF qaydaları məhdud əhatə dairəsinə malikdir və təkmilləşdirməni əvəz edə bilməz. S1S2S3

1. Zəifliyə İcmal və Risk Mühakiməsi

Bu məqalədə PHP2Shell 21 oktyabr 2026-cı il tarixində PHP tərəfindən rəsmi olaraq açıqlanmış iki Critical səviyyəli zəifliyə istinad edir. Hər ikisi PHP mühərrikinin yaddaş və sorğu ömrünün idarə edilməsi ilə əlaqədardır və kodun silinməsi riskini yaradır. S1S2S3

LayihəCVE-2026-109618CVE-2026-109619
rəsmi adıRCE via OOM corruptionRCE via stale global state
əsas məsələlərQeyri-kafi yaddaş anormal bir sıçrayışa səbəb olur və hələ başlanğıclaşdırmanı tamamlamamış bir vəziyyəti tərk edir.İşçidə qalan qlobal vəziyyət buraxılmış sorğu yaddaşına işarə edir.
Tipik baş vermə vaxtıCari sorğunun işə salınması, icrası və ya təmizlənməsi prosesiƏvvəlki sorğu statusu tərk edir və sonrakı sorğular onu əvvəlcədən istehlak edir.
OOM zəruri şərtdirmi?Zəifliyin əsas tetikleyici mexanizminə aiddirXeyr; digər ölümcül səhvlər və diaqnozdan sonrakı təmizləmə də iştirak edə bilər
Əsaslı təmir istiqamətiAyrılma Uğursuzluqlarını Təhlükəsiz İdarə Edin və Xitam tələb edinDövlət mülkiyyətini, təmizləmə vaxtını və erkən işə salmağı düzəldin
Utilizasiya tələbləritəmir edilməlidireyni zamanda təmir edilməlidir

Əsas: İki rəsmi təhlükəsizlik bülleteni və düzəliş təqdimatları. S2S3S4

1.1 Təsirə məruz qalan yerləşdirmələri başa düşmək

PHP rəsmi hesab edir hamısı PHP yerləşdirmələrin idarə edilməsi Web sorğular risk altında, o cümlədən PHP-FPM , Apache mod_php , php-cgi , FrankenPHP , və LiteSpeed . Nümayiş etdi mod_php hücum proqram kodu işə düşməzdən əvvəl baş verə bilər, ona görə də giriş yoxlamaları, çərçivə ara proqramı və proqram yükləmə yoxlaması bu yolu əhatə edə bilməz. S1

“Yerləşdirməni düzəltmək lazımdır” və “müəyyən bir hücum zənciri tamamilə sübut edilmişdir” arasındakı fərqi ayırmaq lazımdır. CVE-2026-109618 elanı: FPM sorğunun işə salınması uğursuz olduqdan sonra uşaq prosesindən çıxacaq, başlanğıc uğursuzluğundan sonra mod_php-nin müvafiq təmizləmə yolunu bloklayacaq; lakin, uğurlu başlanğıcdan sonra OOM yolu hələ də risk altındadır. Elanda həmçinin qeyd olunur ki, bu CVE üçün tam FPM istismarı hələ nümayiş olunmayıb. Bu məhdudiyyət FPM-nin təhlükəsiz olduğu qənaətinə gəlmək üçün istifadə edilə bilməz, xüsusən də CVE-2026-109619-ə məhəl qoymamaq olmaz. S2S3

Uğurlu istismar üçün dərhal icazə sərhədləri PHP-ə sahib olan prosesin kimliyindən və onun çıxışı olan resurslardan asılıdır. Ümumiyyətlə, veb-sayt koduna, yükləmə kataloquna, verilənlər bazası etimadnaməsinə, xidmət nişanlarına və daxili şəbəkəyə giriş imkanlarına diqqət yetirilməlidir; “Uzaqdan kodun icrası” təbii olaraq kök icazələrinin alınması demək deyil. Buradakı nəticə mühakiməsi proses icazəsi modelinə əsaslanır və faktiki təsir yerləşdirmə icazələri ilə birlikdə qiymətləndirilməlidir.

Adi birdəfəlik CLI skriptlərində eyni HTTP girişi yoxdur; lakin CLI və ya daxil edilmiş rejimdə uzun müddət xarici tapşırıqları idarə edən proseslər hələ də icra müddəti və həyat dövrü inventarına daxil edilməlidir. Yalnız CMS, çərçivə və ya Composer asılılıqları yenilənir və əsas PHP mühərriki avtomatik olaraq dəyişdirilmir.

2. Səbəb təhlili

2.1 Əvvəlcə iki həyat dövrünü anlayın

PHP worker çox vaxt ardıcıl olaraq çoxsaylı sorğuları idarə edir. Sorğu zamanı ayrılan yaddaş sorğunun sonunda vahid şəkildə buraxıla bilər, işçinin özü və onun bəzi qlobal sahələri mövcud olmağa davam edir.

Beləliklə, mühərrik iki məhdudiyyəti qorumalıdır:

  • İnsiallaşdırma məhdudiyyəti: Digər kodlara görünən məlumatlar təhlükəsiz oxuna bilən, keçilən və məhv edilə bilən vəziyyətdə olmalıdır.
  • Lifecycle məhdudiyyəti: sorğu yaddaşı boşaldıqdan sonra, daha uzun ömürlü sahələr həmin yaddaşdakı ünvanları etibarlı vəziyyət kimi qəbul etməyə davam etməməlidir.

Bu iki məhdudiyyət iki zəiflik qrupunun əsas uğursuzluq rejimlərinə uyğundur. Aşağıdakı proses elanları və yamaq tərtibini birləşdirən mexanizm təsviridir. Bu o demək deyil ki, hər bir yerləşdirmənin eyni əlçatan yolu var. S2S3S5

2.2 CVE-2026-109618: OOM tamamlanmamış status yeniləməsini dayandırdı

Köhnə tətbiq OOM-ni idarə etmək üçün longjmp() tipli qeyri-lokal keçiddən istifadə edir və əlaqəli yol zend_bailout() vasitəsilə cari icra kontekstindən çıxır. Təhlükə ondan ibarətdir ki, C kodunun bir parçası yeni obyekt, massiv və ya sorğu statusunu digər koda dərc etmiş ola bilər, lakin bütün sahənin işə salınmasını hələ tamamlamamışdır; bu zaman, müvafiq vaxtda hər hansı ayırma uğursuzluğu normal bağlanma addımlarının atlanmasına səbəb ola bilər. S2

Uğursuzluq prosesi dörd mərhələyə bölünə bilər:

  1. Sorğunun daxili strukturunu yaradın və ya yeniləyin və onu əlçatan edin.
  2. Sonrakı yaddaş bölgüsü uğursuz olur və OOM işə salınır.
  3. İcra axını cari funksiyadan sıçrayır və başlanğıcı tamamlamaq və ya vəziyyəti bərpa etmək üçün istifadə edilən kod icra olunmur.
  4. Təmizləmə sorğusu bu strukturları emal etməyə davam edir və etibarsız məzmunları etibarlı sahələr və ya ünvanlar kimi qəbul edir.

Məsələ onda deyil ki, yaddaşın tükənməsi həmişə RCE-yə səbəb olur. Əksinə, yaddaşın tükənməsi idarəetmə axını dəyişir və mühərrikin etibarlı strukturlar haqqında fərziyyələrini pozur.. Uğursuz ayırma, nəticədə səhv oxunan strukturu birbaşa əhatə etməməlidir. S2

Niyə daha kiçik sorğular da yaddaşdan çıxa bilər?

Sorğu gövdəsindəki baytların sayı və təhlildən sonra yığın istifadəsi eyni şey deyil. A sahəsi PHP daxilində çoxsaylı sətirlərə, massiv elementlərinə və metadata obyektlərinə uyğun ola bilər; giriş strukturunun mürəkkəbliyi yaddaşın gücləndirilməsi dərəcəsinə təsir edəcək.

Rəsmi elanda sadalanan çoxhissəli problemlərə aşağıdakılar daxildir: mövcud bəyannamə uzunluğu olmadığı zaman ilkin ölçüdə yoxlama boşluğu, bir hissə üçün başlıqların sayı kifayət qədər məhdud deyil və boş fayl nəzarətləri hələ də metadata istehsal edir, iç içə adlar massiv iş yükünü daha da artırır. Tətbiqin özünün açılması, şifrəsinin açılması və ya girişin yenidən təyin edilməsi də OOM mənbəyi ola bilər. S2

Bundan iki qoruyucu nəticə çıxarmaq olar:

  • Sorğu orqanının məhdudiyyətləri PHP daxil etməzdən əvvəl mümkün qədər həyata keçirilməli və faktiki oxunuş uzunluğu və struktur mürəkkəbliyi nəzərə alınmalıdır.
  • Fayl ölçüsünü, faylların sayını fərdi olaraq məhdudlaşdırmaq və ya yalnız bir yükləmə portalını bağlamaq bütün OOM mənbələrini əhatə edə bilməz.

Niyə tətbiqin autentifikasiyası çox gec ola bilər

mod_php-də sorğunun başlanğıc mərhələsi zamanı sorğu orqanı avtomatik təhlil edilə bilər; başlanğıc uğursuz olsa belə, müvafiq sorğunun təmizlənməsi hələ də həyata keçiriləcək. Buna görə də təsdiqlənmiş hücum yolları tətbiq kodundan əvvəl baş verə bilər. Bu mərhələdə məruz qalmağı azaltmaq üçün məhdudiyyətlər əks proksidə, Web serverində və ya PHP sorğunun emalından əvvəl olan digər sərhəddə yerləşdirilməlidir. S1S2

2.3 CVE-2026-109619: Sorğu yaddaşı buraxıldı, qlobal istinad hələ də canlıdır

Bu problem xəta, sessiya, obyekt və ya genişləndirmə statusunu əhatə edir: sahə işçinin uzunmüddətli giriş yerində saxlanılır, lakin sahənin istinad etdiyi məlumatlar bir sorğuya aiddir. Nə qədər ki, sorğu yığını buraxılmamışdan əvvəl arayış lazımi qaydada təmizlənməyib, sonrakı sorğular istifadədən sonra istifadəni formalaşdırmaqla sallanan vəziyyətlə qarşılaşa bilər. S3

Rəsmi təhlil istismar şərtlərini “istehsalçılar” və “istehlakçılar”a bölür:

rol və ya vəziyyətmənaQoruma üçün təsirlər
dövlət istehsalçısıBu sorğuya məxsus dövləti daha sonra daxil olmaq mümkün olan yerə qoyunQeyri-normal çıxışdan sonra müvafiq təmizləmənin tamamlandığını yoxlamaq
Vəziyyəti qalırTəmizlənmədi və ya gec əməliyyatla təmizləndi və sonra yenidən dolduruldu.Əvvəlki bağlanma mərhələsində bir dəfə təmizləmə kifayət olmaya bilər
işçinin təkrar istifadəsiEyni işçi sonrakı sorğuları emal etməyə davam edirÇox işçi yaddaş təhlükəsizliyi zəmanəti deyil, sadəcə planlaşdırma fərqidir
qabaqcadan istehlakçıMüvafiq vəziyyət normal işə salınmazdan əvvəl qalıq dəyəri oxuyun, buraxın və ya müəyyən edin.Başlamadan əvvəl INI, sessiya və digər yolları yoxlamaq lazımdır

Bu şərtlər birləşərək yerinə yetirilməlidir; hər hansı bir səhv jurnalı öz-özünə zəifliyin uğurla istifadə edildiyini sübut etmir. S3

Zəruri ilkin şərt kimi OOM tələb etmir

Ölümcül səhvlər qoşalaşmış dövlət nəşrini və bərpasını dayandıra bilər. Kompilyasiya və ya təhlil uğursuzluqları, tutulmamış xətalar, require uğursuzluqları və icra müddətləri müəyyən vəziyyətləri geridə qoya bilər. Təmizləmə zamanı ölümcül olmayan diaqnostika da artıq təmizlənmiş xəta məlumatını yenidən doldura bilər. S3

Buna görə də, memory_limit-nin limitsiz olaraq dəyişdirilməsi bu zəifliklər dəstini əhatə etmir.

”İnsiallaşdırmadan əvvəl” ayrıca müalicə edilməlidir

İki növ təsdiqlənmiş istehlakçının vaxtı fərqlidir:

  • Early INI diagnostics: Sorğuda tətbiq edilən bəzi konfiqurasiyalar normal icraçının işə salınmasından və diaqnostik emaldan əvvəl xəbərdarlıq, bildiriş və ya köhnəlmə ilə bağlı problem yaradır və köhnə xəta vəziyyətinə daxil ola bilər.
  • sessiyanın yüklənməsinin gedişi: sorğunun əsas təhlili prosesi zamanı sessiya əvvəlcədən işlənə bilər, lakin RINIT adi modulu hələ tamamlanmayıb; proqram açıq şəkildə session_start() çağırmadığı üçün yolun mövcud olmadığı qənaətinə gəlmək olmaz. S3

Hamısı deyil INI konfiqurasiyalar eyni risk vaxtına malikdir. Kataloq səviyyəli konfiqurasiya mod_php və PHP_VALUE / PHP_ADMIN_VALUE tərəfindən keçdi FPM ön tərəfi adidən fərqləndirmək lazımdır php.ini , FPM pool başlanğıc konfiqurasiyası və FPM .user.ini . Sonuncuların fərqli konfiqurasiya vaxtı var və onları birlikdə eyni ilk istehlakçılar adlandırmaq olmaz. S3

display_errors, log_errors-ni söndürmək, error_reporting-ni azaltmaq və ya @-dən istifadə etmək yalnız diaqnozun görünməsinə təsir edir; jurnalın buraxılıb-çıxılmaması barədə qərar qəbul etməzdən əvvəl müvafiq daxili vəziyyətə daxil olmuş ola bilər. S3

3. Təmir versiyası və yamaq seçimi

3.1 Rəsmi yuxarı axın düzəltmə bazası

Cari PHP filialıBu rəsmi düzəlişi ehtiva edən ilk versiyaTəkliflər
8.28.2.35Bu versiyaya və ya eyni düzəlişləri ehtiva edən sonrakı versiyaya təkmilləşdirin
8.38.3.36Yuxarıdakı kimi
8.48.4.27Yuxarıdakı kimi
8.58.5.12Yuxarıdakı kimi
8.1 və əvvəlki versiyalarUpstream ümumi dəstəyi başa çatdıDəstəklənən filiallara miqrasiyaya üstünlük verin; qısamüddətli çek buraxılışı və ya LTS istehsalçının arxa portu

Versiya və dəstək statusu PHP-nin rəsmi elanına əsaslanır və əsas vaxt 22 oktyabr 2026-cı ildir. S1

Bunlar filiala xas düzəliş hədləri. Onları 8.5.12-dən aşağı olan hər bir versiyanın həssas olduğu ifadəsi ilə əvəz etmək olmaz: digər filiallardakı 8.2.35 və 8.4.27 kimi versiyalar artıq düzəlişləri ehtiva edir.

3.2 Tam paylama paketi versiyasını yoxlayın

Distros tez-tez köhnə yuxarı versiyalar əsasında təhlükəsizlik düzəlişləri əlavə edir. Qəbul həmçinin buraxılış versiyasını, repozitor mənbəyini, tam paket versiyasını və təhlükəsizlik bülletenini yoxlamalıdır.

Məsələn, Ubuntu USN-8948-1 üçün sadalanan Ubuntu 24.04 LTS düzeltme paketi versiyası:

8.3.6-0ubuntu0.24.04.13

Onun yuxarı hissəsi hələ də 8.3.6-dir, lakin bu paylamanın tam paket versiyası bu düzəliş elanına daxil edilmişdir. Bu nəticə yalnız müvafiq paylama və paket mənbəyinə aiddir və 8.3.6-ni də göstərən hər hansı quruluşa ümumiləşdirilə bilməz. S10

3.3 Düzgün yamağın seçilməsi

səhnəPrioritet planıQəbul üçün əsas məqamlar
Dağıtım PHP paketindən istifadə etməkləİstehsalçı tərəfindən buraxılmış təhlükəsizlik yeniləmələrini quraşdırınElanda həm CVE; tam paket versiyası düzgündür
Rəsmi PHP konteynerindən və ya öz-özünə qurulmuş təsvirdən istifadə edinƏsas iş vaxtını yeniləyin, yenidən qurun və yerləşdirinÇalışan nümunə yeni təsvirdən istifadə edir; bütün köhnə nüsxələr çıxarılır
Öz-özünə tərtib edilən dəstəklənən filiallarBu filialın rəsmi təhlükəsizlik versiyasından və ya tam rəsmi yamaq dəstindən istifadə edinFilial uyğunluğu, asılılığın tamamlanması, genişləndirmə uyğunluğu və reqressiya keçməsi
7.4, 8.0, 8.1 şərtlərinə əsasənTəchizatçı backportuna üstünlük verin; zəruri hallarda rəsmi fövqəladə mənbə kodu filialını qiymətləndirinDavranış dəyişikliklərini müəyyənləşdirin və dəstəklənən versiyalara miqrasiyanı planlaşdırın

Rəsmi yamalar buraxılıb və faktiki düzəlişlər bu yamaqlardan başlamalıdır. Bölmə 6-dakı kod fraqmentləri dizayn və nəzərdən keçirmə məqamlarını təsvir etmək üçün nəzərdə tutulub və müstəqil şəkildə tətbiq oluna bilən tam yamaq təşkil etmir. S1S4S6

4. Formal təmir prosesi

4.1 Sorğuları həqiqətən idarə edən iş vaxtının inventarizasiyası

Ən azı aşağıdakıları qeyd etmək üçün qısa bir kitab tərtib etmək tövsiyə olunur:

  • Giriş domen adı və ya xidməti, əks proxy backend, PHP SAPI.
  • PHP filialı, tam paket versiyası və ya şəkil həzm, quruluş mənbəyi.
  • FPM pool, faktiki xidmət vahidi, konteyner və ya Pod, replikaların sayı.
  • Genişləndirmələr, əsas konfiqurasiya və əlavə konfiqurasiya faylları yükləndi.
  • Birbaşa daxil olmaq mümkün olan digər PHP versiyaları, köhnə yerləşdirmə nüsxələri və ya mənşə portalları varmı?

Bunlar icra təklifləridir ki, “təkmilləşdirilmiş” hər bir faktiki trafik girişinə uyğun gəlsin. Xüsusilə PHP və Web PHP əmr sətirlərinin fərqli versiyalardan istifadə edib-etmədiyini, təsvirin qurulduğunu, lakin köhnə konteynerin hələ də işlədiyini, hovuzun bir hissəsinin və ya surətin dəyişdirilmədiyini və s.

4.2 Düzgün yeniləməni seçin və yerləşdirin

Mövcud etibarlı paket mənbəyi və ya idarə olunan qurma zəncirindən istifadə etməklə, Bölmə 3-ə uyğun olaraq düzəliş versiyasını təsdiq edin. Yeniləmə əhatəsinə FPM paketi, Apache PHP modulu, CGI ikili və ya PHP-nin daxil edildiyi xidmət quruluşu kimi sorğuya faktiki ev sahibliyi edən komponent daxil edilməlidir.

Təkmilləşdirmədən əvvəl konfiqurasiya və paket siyahısını saxlayın və istehsala bənzər mühitdə başlanğıc və əsas xidmətləri yoxlayın. Öz-özünə saxlanılan genişləndirmələr üçün PHP versiyasına uyğun qurulma və işə salınma uyğunluğunu yoxlayın. Sadəcə başqa bir filialdan müvafiq görünən öhdəlik seçmək bütün düzəlişlər dəstinin həyata keçirildiyinə zəmanət vermir.

4.3 Çalışan nümunələri yenidən başladın və ya yuvarlayın

Faylın quraşdırılması və prosesə yeni kodun yüklənməsi iki fərqli şeydir. Müvafiq xidmət yenidən işə salınmalı və ya yuvarlanan dəyişdirmə tamamlanmalı və köhnə işçinin və köhnə konteynerin çıxdığı təsdiqlənməlidir.

mod_php üçün modulu yerləşdirən Apache prosesini yenidən başladın. PHP yerləşdirən xidmətlər hostinq prosesini dəyişdirməlidir. FPM üçün OPcache-nin təmizlənməsi iş vaxtının yenilənməsini və köhnə işçilərin təqaüdə çıxmasını əvəz etmir.

Zərif keçiddən istifadə edərkən, köhnə nəsil prosesinin hələ də uzun əlaqələri və ya gözlənilməz sorğuları idarə edib-etmədiyini yoxlamaq lazımdır. Qəbul qeydinə faktiki xidmət, yerləşdirmə versiyası, dəyişikliyin tamamlanma vaxtı və köhnə nümunənin çıxış nəticələri daxil edilməlidir.

4.4 Real Web sorğuları vasitəsilə yoxlayın

Yalnız bir versiya əmrinə güvənməkdənsə, aşağıdakı sübut hissələrini birləşdirmək tövsiyə olunur:

sübutNəyi sübut etmək olarTək başına heç nə sübut edə bilməz
Paket meneceri və ya şəkil metadatasıQuraşdırma mənbələri və tam quruluşlarTrafik bu instansiyaya dəyişdirilib
Proses və yerləşdirmə vəziyyətiişçi və ya konteyner dəyişdirilməsini tamamlayırXarici giriş ona yönəldilməlidir
Həqiqi portal vasitəsilə əldə edilən məhdud diaqnostik nəticələrFaktiki Web SAPI və çalışan konfiqurasiyaBuraxılış arxa portunun iki CVE-ni əhatə edib-etməməsi
Satıcı elanı və ya tam yamaq qeydiBu səhv düzəlişi bu quruluşa daxildirBütün replikalar yerləşdirilib

PHP_VERSION, PHP_SAPI, yüklənmiş konfiqurasiya faylları və fövqəladə konfiqurasiyalar mövcud daxili diaqnostika imkanları və ya müvəqqəti və girişlə idarə olunan diaqnostika portalları vasitəsilə yoxlana bilər. Sorğunun birbaşa CDN və ya səhifə keşi tərəfindən qaytarılmadığından əmin olun; tamamlandıqda müvəqqəti diaqnostik girişi çıxarın.

php -v adətən yalnız hazırda shell tərəfindən seçilmiş CLI binarını göstərir; php-fpm -i kimi əmrlər trafik qəbul edən mövcud işçinin yoxlanmasına bərabər deyil. Tam phpinfo() səhifəsini uzun müddət ictimai şəbəkəyə göstərməyin.

4.5 Biznes reqressiyasını yoxlayır və fövqəladə vəziyyət parametrlərinin çıxarılması

Bu dəyişikliyin təsirinə məruz qalan funksiyalar ətrafında normal giriş, sessiyanın oxunması və yazılması, forma və yükləmə, idxal, xətaların idarə edilməsi və işçi sabitliyini yoxlayın. Səhv dərəcəsi, cavab gecikməsi, yaddaş zirvəsi, prosesdən çıxış və yenidən qurma tezliyinin anormal olub olmadığını yoxlayın.

memory_limit=-1 müvəqqəti olaraq təyin edilərsə, rəsmi yamaq qüvvəyə mindikdən sonra biznes imkanlarına uyğun məhdud büdcə bərpa olunacaq; pm.max_requests=1 təyin edilərsə, təmir təsdiq edildikdən sonra tutumla qiymətləndirilmiş həyat dövrü konfiqurasiyası bərpa olunacaq. Daxiletmə ölçüsü məhdudiyyətləri və mənbəyə giriş nəzarətləri biznes ehtiyaclarının diktə etdiyi kimi saxlanıla bilər.

Təkmilləşdirmə zamanı uyğunluq problemləri yaranarsa, geri çəkilməzdən əvvəl təsirə məruz qalan portalın dayandırılmasına, onun xarici girişinin məhdudlaşdırılmasına və ya tətbiqin tənzimlənməsinə üstünlük verilməlidir. Təmir edilməmiş iş vaxtının ictimai şəbəkəyə yenidən xidmət göstərməsinə birbaşa icazə verilməsi ilkin riski yenidən açacaq.

5. Dərhal təkmilləşdirmə mümkün olmadıqda təsirin azaldılması tədbirləri

Bu bölmə məruz qalmanın qısamüddətli azaldılması və ya əlçatanlığın yaxşılaşdırılması üçün nəzərdə tutulub. Hər bir tədbir yalnız müəyyən bir yolu əhatə edir və çoxsaylı tədbirlərin birləşməsi tam təmirə bərabər deyil. S1S2S3

5.1 PHP-dən əvvəl trafik nəzarətinə üstünlük verin

Xidmət buna icazə verirsə, PHP-dən əvvəl həssas son nöqtələri etibarlı mənbələrə müvəqqəti məhdudlaşdırın və ya giriş nəzarətini tətbiq edin. Yükləmə iş yükləri üçün sorğunun gövdə ölçüsünü, sahə saylarını, hissə sayılarını, hər hissəyə başlıqları və yuva dərinliyini məhdudlaşdırın. Çox hissəyə ehtiyacı olmayan xidmətlər onu frontenddə rədd edə bilər. S2

Bu məhdudiyyətlər PHP-yə bütün girişləri əhatə edir. Yalnız “yükləmə” adlı URL-nin tutulması sorğunun mətnində hələ də PHP tərəfindən avtomatik təhlil edilən digər qeydləri əldən verəcək. Parçalanmış köçürmələr, mövcud elan edilmiş uzunluğun olmaması və s. kimi hallar üçün limit faktiki oxunuş ölçüsünə əsaslanmalıdır; Tətbiqin məzmunu yenidən açarkən və ya genişləndirərkən öz çıxış ölçüsü büdcəsi də olmalıdır.

5.2 FPM pool konfiqurasiya şablonu

Aşağıdakı parametrləri php.ini-də sözlə deyil, sorğularına xidmət edənFPM pool konfiqurasiya bölməsinə yerləşdirin. 8M və 4M dəyərləri iş yükünü tənzimləmək üçün nümunələrdir. Bütün POST sorğusunu məhdudlaşdırarkən forma sahələri və çoxhissəli sərhədlər üçün yer buraxın. S11S12

; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off

Yalnız PHP 8.5, əlavə olaraq:

php_admin_flag[fatal_error_backtraces] = off

Hər birinin funksiyaları və sərhədləri aşağıdakılardır:

Konfiqurasiyagözlənilən təsirSaxlanılmalı olan məhdudiyyətlərin təsviri
memory_limit=-1Proqnozlaşdırıla bilən PHP sorğu yaddaşının yuxarı həddi tetikleme vəziyyətini silinO, əsas ayırma uğursuzluğunun qarşısını almır; orijinal büdcənin ləğvi yaddaşın tükənməsi və xidmətin dayandırılması riskini artıra bilər.
Daha kiçik post_max_sizeAnaliz prosesinə daxil olan məlumatların ölçüsünü azaldınSabitləşdirilməmiş analizatorda məlum boşluq var; yaddaşın gücləndirilməsinin qarşısı müstəqil olaraq alına bilməz
upload_max_filesize < post_max_sizeTək fayl ölçüsünü məhdudlaşdırın və sorğunun yerüstü sahəsini rezerv edinBütün sahələri, metadataları və ya tətbiqdaxili ayırmaları məhdudlaşdırmır
Yükləmə prosesini bağlayınTəsdiqlənmiş sessiya ilə əlaqəli yolu bloklayınDigər qlobal dövlət variantlarını əhatə etmir
PHP 8.5 yaxın ölümcül geri izTəsdiqlənmiş əlaqəli status istehsalçılarını bloklayınSessiya kimi digər yolları əhatə etmir

Tədbirin sərhədləri rəsmi elandan gəlir; hovuz sintaksisi və idarəetmə səviyyəsində konfiqurasiya semantikası üçün PHP təlimatına baxın. S1S2S3S11

İdarəetmə səviyyəli php_admin_* parametrləri ini_set() vasitəsilə tətbiqlər tərəfindən ləğv edilə bilməz. Faktiki sorğulardakı dəyərlərin gözlənildiyi kimi olduğunu təsdiqləmək üçün bütün hovuz, kataloq səviyyəli və ön uç daxil olan konfiqurasiyalar hələ də nəzərdən keçirilməlidir. Dəyişiklikdən sonra, mövcud proseslərin köhnə vəziyyəti saxlamağa davam etməsinin qarşısını almaq üçün bütün işçiləri yenidən qurun.

php.ini-ni birbaşa dəyişdirməyi seçsəniz, sintaksis aşağıdakı kimi dəyişdirilməlidir:

memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off

Hovuzdakı php_admin_value-dən fərqli olaraq, sadəcə memory_limit=-1-nin php.ini-də qurulması proqramın onu yenidən dəyişdirməsinə mane olmur. Çərçivə, proqram kodu və digər konfiqurasiyalar məhdud dəyəri sıfırlayıb-yaratmadığını yoxlamaq üçün yoxlanılmalıdır; icra tələb olunduqda, cari SAPI üçün uyğun idarəetmə səviyyəli parametrlərdən istifadə edin və faktiki effektiv dəyəri yoxlayın. S11S12

Yalnız PHP 8.5 üçün fatal_error_backtraces = Off əlavə edin. Yükləmə prosesinin dayandırılması üçün proqram səviyyəsində ini_set()-dən istifadə etməyin və sorğunun təhlilindən əvvəl onu effektiv etmək üçün FPM .user.ini-ə etibar etməyin. S1S3

5.3 PHP yaddaş məhdudiyyətlərinin aradan qaldırılması xərclərini idarə edin

memory_limit=-1 sabitləşdirilməmiş mühitlər üçün müvəqqəti yolun azaldılmasıdır və uzunmüddətli defolt konfiqurasiya kimi kopyalanmamalıdır. Tətbiq və ya sorğu nəzarətdən çıxdıqda o, hostun yaddaşından daha çox istifadə edə bilər. Buna görə də, istifadə etməzdən əvvəl, paralellərin sayını, pik tək işçini və ümumi xidmət tutumunu qiymətləndirməli və front-end giriş məhdudiyyətlərini tətbiq etməlisiniz. S2

Konteyner və ya qrup yaddaş məhdudiyyətləri əlçatanlıq sərhədlərini təmin edə bilər, lakin ayırmaların heç vaxt uğursuz olmayacağına zəmanət vermir; limit işə salındıqda bütün konteyner, usta və bütün işçi də işdən çıxarıla bilər. İzolyasiya qranularlığı və dayandırma strategiyaları yerləşdirmə ilə birlikdə qiymətləndirilməlidir və bu iki CVE üçün tam qorunma adlandırıla bilməz. S2

Yuxarıdakı strategiyaları RLIMIT_AS, RLIMIT_DATA və ya müvafiq proses ünvan məkanı məhdudiyyətləri ilə əvəz etməyin; onlar birbaşa əsas ayırmanın hələ də problemli OOM yolunda uğursuz olmasına səbəb ola bilər. S2

5.4 Nginx Konfiqurasiya Nümunəsi

Nginx sorğuları PHP-FPM-ə yönləndirdiyi yerləşdirmə üçün tətbiq edilir. O, faktiki hosting xidmətinin konfiqurasiya səviyyəsində təyin edilə bilər:

client_max_body_size 8m;
fastcgi_request_buffering on;

client_max_body_size sorğunun əsas ölçüsünü məhdudlaşdırır; fastcgi_request_buffering on, Nginx-ə əvvəlcə tam sorğu orqanını oxumağa və sonra onu FastCGI arxasına göndərməyə imkan verir. Bunun müəyyən server və ya location-də qüvvəyə minməsi mövcud miras və əhatə əlaqələri ilə birlikdə yoxlanılmalıdır. S13S14

Yalnız biznesə çox hissəli ehtiyacı olmadıqda, müvafiq xidmət girişinə rədd etmə qaydası əlavə edə bilərsiniz:

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

Bu, if və return istifadə edən sadə giriş məhdudiyyəti şablonudur, təhlilçi zəiflikləri üçün ümumi filtrləmə qaydası deyil. Yerləşdirmədən əvvəl konfiqurasiya sintaksisini və normal sorğuları yoxlayın və xüsusi error_page-nin 403 sorğunu PHP-ə yönləndirib-yönləndirmədiyini yoxlayın. Sətir uyğunluğu bütün təhlil fərqlərinə tam zəmanət vermir. S15

Bundan əlavə, bu konfiqurasiyalar proqram tərəfindən açıla bilən verilənlərin miqdarını, sahələrin sayını və ya PHP obyektlərinin sayını avtomatik məhdudlaşdırmır; yükləməli olan bizneslər sorğularının strukturunu başa düşən əlavə məhdudiyyətlərdən istifadə etməlidirlər.

5.5 Könüllü yumşaldılma: hər FPM işçisi üçün bir sorğu

Yerüstü xərcləri ödəyə bilən FPM yerləşdirmələri üçün qısamüddətli quraşdırmalar qiymətləndirilə bilər:

pm.max_requests = 1

Və mövcud işçini yenidən qurun. O, işçinin təkrar istifadəsi səviyyəsində təsvir olunan çarpaz sorğu zəncirini bloklayır, lakin prosesin yaradılmasını və işə salınmasını artıracaq; eyni zamanda, eyni sorğu OOM və CVE-2026-109618-nin təmizlənməsi məsələlərini təmir edə bilməz. Dəyər kiçik, lakin 1-dən böyük olduqda, yenə də təkrar istifadə sorğusu pəncərəsi var. S3S11

5.6 WAF və Cloudflare əhatə dairəsi limitləri

Cloudflare, Free planı da daxil olmaqla, PHP2Shell-dən qorunmaq üçün yerləşdirmə tədbirlərini elan etdi. Onun xidmətlərindən istifadə edərkən, faktiki trafikin proksidən keçib-keçmədiyini, qorunma qaydalarının qüvvədə olub-olmadığını və mənşə saytının birbaşa yan keçməsinin mümkün olub-olmadığını yoxlamaq lazımdır; ödənişli planlar üçün, həmçinin müvafiq İdarə olunan Qaydaların konfiqurasiyasını və istisnalarını yoxlamaq lazımdır. S16

Satıcı tərəfindən təsvir edilən bəzi aşkarlamalar cavab siqnallarından istifadə edir, ona görə də bütün müdafiələr “PHP-ə çatmamış hər hücum bloklanır” kimi şərh edilə bilməz. WAF məruz qalmağı azaltmağa və müşahidə məlumatları təmin etməyə kömək edə bilər, lakin PHP-ə davamlı təkmilləşdirmələr hələ də lazımdır. S16

5.7 Niyə ümumi tədbirlər kifayət deyil

tədbirlər və ya hökmlərçatışmazlıqlar
Yalnız file_uploads bağlayınBütün çoxhissəli emalları əhatə edə və öz OOM yolunu tətbiq edə bilməz
enable_post_data_reading=Off parametriPOST/FILES-in avtomatik doldurulmasının davranışını dəyişdirin; sorğu orqanı hələ də tətbiq tərəfindən oxuna bilər və normal işi poza bilər
Səhv ekranını söndürün, daxil olun və ya @ istifadə edinDaxili diaqnostik proses hələ də sallanan vəziyyətə daxil ola bilər
İşçilərin sayını artırınTəhlükəsiz dövlət təmizləmə mexanizmi yaratmayın və tək işçinin təkrar istifadəsini aradan qaldırmayın
Yalnız disable_functions və ya open_basedir konfiqurasiya edinBu məhdudiyyətlər C mühərrik qatının yaddaş pozğunluğunu aradan qaldırmır
Versiyanı və ya bir nüsxəni yalnız bir dəfə yoxlayınBütün girişlərin və işləyən instansiyaların dəyişdirildiyini sübut etmək mümkün deyil
Heç bir istisna qeydləri görünmürO, zəifliyin mövcud olmadığını və ya ondan əvvəl istifadə olunmadığını sübut edə bilməz.

Onların arasında PHP-nin konfiqurasiya və zəiflik mexanizminin əsasını S2S3S12-də tapmaq olar; əhatə dairəsi, qəbul və icazə sərhədləri ilə bağlı mülahizələr bu mexanizmlər tərəfindən irəli sürülən icra təkliflərinə əsaslanır.

6. Rəsmi yamağın həyata keçirilməsi ideyaları və baxış nöqtələri

6.1 Düzgün filial üçün tam düzəlişlərdən istifadə edin

PHP 8.5 üçün rəsmi təqdimat:

31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout

Həm OOM çıxış mexanizmini tənzimləmək, həm də başlatma mərhələsində əldə edilə bilən qlobal vəziyyəti düzəltmək üçün öhdəlik iki CVE-ni açıq şəkildə əlaqələndirir. Səhifəni tam fərqlə təqdim edin S4S5. Digər filiallar öz rəsmi təhlükəsizlik buraxılışlarından və ya uyğun yamaqlardan istifadə etməlidirlər və 8.5-ə edilən dəyişikliklərin hər hansı köhnə versiyaya birbaşa tətbiq oluna biləcəyini güman etmək olmaz.

6.2 OOM Təmir: əvvəlcə emal olunan vəziyyəti bərpa edin, sonra sorğunu dayandırın

Rəsmi tətbiq yumşaq və sərt OOM emalının iki səviyyəsini təqdim edir: yumşaq limitə çatdıqda, gözlənilən status qeydə alınır və VM kimi təhlükəsiz yerdə idarə olunan çıxış həyata keçirilir; uğursuz ayırma interfeysi zəng edənə uğursuzluğu açıq şəkildə idarə etməyə imkan verir. Uğursuzluğu birbaşa qaytara bilməyən ayırmalar üçün, daha yüksək həddi aşması gözlənildiyi təqdirdə, təhlükəli aralıq vəziyyətdə sorğuların işlənməsinə davam etməmək üçün proses birbaşa dayandırılacaq. S2S5

Aşağıda gözlənilən OOM-i qeyd etmək üçün istifadə edilən 8.5 fərqindəki əsas kodun bir hissəsi verilmişdir:

EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);

VM fasilələrlə işləmə və digər təhlükəsiz yerlər sonradan zend_handle_delayed_oom()-ə zəng edir. Onun istifadəçi kodunun icrası konteksti idarə olunan açılma yolundan istifadə edir; çətin OOM yolu _exit(137) çağırır. S5

Dizayn baxımından əsas dəyişiklik budur: struktur aralıq vəziyyətdə olduqda C çağırış steki boyunca ixtiyari sıçrayışdan qaçmaq və çıxışı vəziyyət invariantlarının qoruna bildiyi nöqtəyə keçirmək. Yumşaq hədd işə düşdükdən sonra emalı tamamlamaq üçün əlavə yaddaş lazım ola bilər. Buna görə yeni yumşaq həddi prosesin ümumi yaddaşı üçün mütləq yuxarı hədd kimi başa düşmək olmaz.

Həm də “PHP bütün zend_bailout()-ni sildi” kimi ümumiləşdirilə bilməz. Yamaq hələ də xüsusi kontekstlərdə müvafiq mexanizmlərdən istifadə edir; sabit olan təhlükəli çıxış vaxtı və onu müşayiət edən dövlət rəhbərliyidir. S5

6.3 Ayrılan zəng edənləri yeniləyin və çox hissəli təhlili birlikdə

Əgər siz ayırma funksiyasını yalnız “uğursuzluqda NULL-u qaytarın” olaraq dəyişdirsəniz və orijinal zəng edən hələ də etibarlı göstəricinin həmişə qaytarıldığını güman edirsə, siz yeni null göstərici girişlərini və ya natamam təmizləməni təqdim edəcəksiniz. Yamaqdakı uğursuz ayırma interfeysi zəng edənin yoxlanılması və istisnaların yayılması ilə birlikdə nəzərdən keçirilməlidir. S5

çoxhissəli əlaqəli düzəlişlərə həmçinin faktiki oxunma həcminə əsaslanan məcmu yoxlamaların aparılması, faydasız və ya dublikat başlıqların işlənməsinin azaldılması və OOM gözlənilən zaman ardıcıl çıxış və təmizləmə məntiqinin qəbul edilməsi daxildir. Bu dəyişikliklər həm resursun gücləndirilməsini azaldır, həm də təhlilçini yeni OOM protokoluna uyğunlaşdırır. S5

Öz filiallarını saxlayan komandalar üçün kodun nəzərdən keçirilməsində aşağıdakı məsələlərin diqqət mərkəzində olması tövsiyə olunur:

  • Dövlət tam işə salınmamışdan əvvəl xarici dünyaya görünürmü?
  • Ayrılma uğursuzluğu və ya geri çağırış istisnasından sonra sahiblik hələ də unikal və birmənalı deyilmi?
  • Yarı yolda uğursuz olsanız, vahid təmizləmə çıxışına çata bilərsinizmi?
  • Təmizləmə funksiyası işə salınmamış və ya boşaldılmış sahələri tanıya bilərmi?
  • Təhlil büdcəsi yalnız etibar sorğusu iddialarına deyil, faktiki emal həcminə əsaslanırmı?
  • Yeni uğursuzluq qaytarma dəyəri bütün zəng edənlər tərəfindən idarə olunubmu?

Bunlar düzəliş mexanizmi əsasında ümumiləşdirilmiş yoxlama suallarıdır və təmin edilməmiş kod bazası üçün tamamlanmış auditin nəticəsi deyil.

6.4 Çarpaz sorğunun düzəldilməsi: əvvəllər işə salın, son təmizləmə sonra

CVE-2026-109619-ə uyğun olaraq yamaq eyni vaxtda bir neçə həyat dövrü sərhədlərini tənzimləyir. Aşağıda sadalanan fayllar və əməliyyatlar nümunə kimi PHP 8.5 rəsmi fərqini götürür. S5

yeristiqamətini dəyişdirinProblem həll edildi
Zend/zend_execute_API.c və s.Səhvlər, istisnalar, işləyicilər, obyektlər və s. kimi icraçı statusunu sıfırlayın.Sorğu başa çatdıqdan sonra, növbəti sorğu ilə əldə edilə bilən köhnə istinadlar hələ də qalır.
main/main.c başlanğıc yoluSAPI aktivləşdirilməmişdən əvvəl php_basic_early_rinit()-ə zəng edinErkən istehlakçı meydana gəldikdə, müvafiq əsas vəziyyət hələ işə salınmayıb.
main/main.c yolunu bağlayınHTTP globals-ni məhv edin və onu qeyri-müəyyən kimi qeyd edinBuraxılmış dəyər hələ də etibarlı obyekt hesab olunur
sorğu yığını nəhayət azad edilməzdən əvvəlSon səhv mesajını yenidən təmizləyinGecikmiş təmizləmə diaqnostikası xəta statusunu təkrarlayır
ext/session/session.cyüklənmənin gedişi İlkin yol qlobal olaraq ilk sessiyanın başlanğıcıdırAdi modul RINIT əvvəllər köhnə vəziyyətə daxil olub
Serializasiya ilə bağlı kodErkən emalda sinif təhlili və istifadəçi geri çağırışlarını məhdudlaşdırınBaşlama tamamlanmadıqda əlavə istifadəçi kodunu icra edin

Məsələn, başlanğıc ardıcıllığına aşağıdakılar daxildir:

zend_activate();
php_basic_early_rinit();
sapi_activate();

HTTP globals məhv edildikdən sonra statusun uğursuzluğu işarəsini əlavə edin:

zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);

Bu çıxarışlar iki prinsipi göstərir: mümkün olan ən erkən istehlakçıdan əvvəl işə salın və vəziyyəti yenidən yarada biləcək son əməliyyatdan sonra son təmizləmə aparın. Göstərici yalnız normal rejimdə sıfırlanır RINIT və ya daha erkən bağlanma mərhələsi əvvəllər və ya sonrakı girişləri əldən verə bilər. S5

6.5 Niyə öz “bir xətt təmirinizi” etmək tövsiyə edilmir?

Bütün zend_bailout()-ni _exit() ilə əvəz etmək və ya sadəcə müəyyən girişdə null göstərici yoxlanışı əlavə etmək çoxlu sayda müxtəlif icra kontekstini əhatə edəcək. Onlar digər status sahələrini buraxa bilər və ya məhvetməni, uzadılmış geri çağırışları, hostinq prosesini dəyişdirə və son semantika tələb edə bilərlər.

Dəstəklənən versiyalar üçün artıq buraxılmış tam düzəlişlər üstünlük təşkil edir. Öz filiallarının miqrasiyası yamaqların mənbəyini, müvafiq əsasları, münaqişələrin idarə edilməsini və davranış dəyişikliklərini qeyd etməli və müvafiq yuxarı reqressiyadan istifadə hallarından istifadə etməli və bu biznes prosesinin yoxlanılmasını təmin etməlidir. Buradakı təkliflər ayırıcı, VM, sessiya və sorğunun həyat dövrü dəyişiklikləri üzrə yamağın əhatə dairəsinin təhlilindən irəli gəlir. S4S5

7. PHP 7.4, 8.0, 8.1 üçün təcili yardım portu

PHP rəsmi olaraq şiddətə əsaslanan üç köhnə filialın minimum mənbə kodu backportunu təqdim edir. Filial adları bunlardır:

PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619

Filial keçidləri üçün baxın S7S8S9. Bunlar bu zəiflik üçün təcili çatdırılmalardır və köhnə filial üçün müntəzəm yuxarı dəstəyə qayıtmağı təmsil etmir və digər təhlükəsizlik yeniləmələrini əvəz etmir. S1

7.1 Nümunə olaraq PHP 8.1 backportunu götürün

PHP 8.1 üçün müvafiq təqdimatlar bunlardır:

1d7dec178a094e6e75b229ce22754045f8c6070a

Onun strategiyası uğursuzluğa üstünlük verir: müvafiq OOM yolunda diaqnostikanı çıxardıqdan sonra _exit(1)-ə zəng etmək, o cümlədən qlobal status və digər müvafiq düzəlişlər etmək; sessiya yükləmə tərəqqisinin müvafiq emalını daxildən söndürərkən. Müvafiq mənbə kodu təqdim etmək üçün S6-ə baxın.

Bu dəstəklənən filialda daha tam gecikmiş OOM dizaynından davranış fərqidir. Konfiqurasiya hələ də yükləmə tərəqqisinin aktiv olduğunu göstərdiyi üçün bu, bu backportdan sonra daxili emal davranışının dəyişməz qalacağı anlamına gəlmir.

7.2 Yerləşdirərkən qəbul etməli olduğunuz qiymət

Prosesdən birbaşa çıxmaq, normal PHP bağlanma geri çağırışlarını və tətbiqin bağlanmasının bir hissəsini atlayaraq, cari sorğunun uğursuz olmasına səbəb ola bilər; əgər ev sahibi iplik modelini qəbul edərsə, bütün host prosesindən çıxışın digər paralel işə təsirini də qiymətləndirmək lazımdır. Proses menecerinin dəyişdirmə prosesini vaxtında apara bilib-bilməyəcəyi də yoxlamaya daxil edilməlidir.

Buna görə də, köhnə versiyaların istifadəçiləri aşağıdakıları nəzərə almalıdırlar:

  1. Dəstəklənən PHP filialına və onun sabit versiyasına köçürün.
  2. Həm CVE, həm də LTS istehsalçı yeniləməsini açıq şəkildə əhatə edən buraxılışdan istifadə edin.
  3. Əgər o, həqiqətən mənbə kodunun köhnə versiyasına tabedirsə, tam dəyişiklikləri və uyğunluğu yoxlamaq və sonrakı miqrasiyanı təşkil etmək üçün uyğun versiyanın rəsmi təcili yardım portundan istifadə edin.

Buradakı “minimum backport” rəsmi şəxs tərəfindən seçilmiş uyğunluq və icra miqyasını təsvir edir və avtomatik olaraq “məlum natamam zəiflik aradan qaldırılması” kimi şərh edilməməlidir. Müvafiq filialın mənbə koduna və istehsalçının elanına əsasən mühakimə etməlisiniz və dəstəkləyici dəyişiklikləri özünüz silməyin. S1S6

8. Qəbul meyarları və sonrakı yoxlamalar

Bu təmiri başa çatdırmaq üçün aşağıdakı nəticələrin əsas kimi istifadə edilməsi tövsiyə olunur:

Qəbul maddələriTamamlama standartları
zəifliyin əhatə dairəsiQuraşdırma və ya satıcı elanı CVE-2026-109618 və CVE-2026-109619-ni açıq şəkildə düzəldir
Yerləşdirmə əhatəsiBütün portallar, hovuz, xidmətlər və replikalar təmir edilmiş iş vaxtından istifadə edir
Proses qüvvəyə minirKöhnə işçi, köhnə host prosesi və köhnə konteyner hamısı çıxış edir
Orijinal sorğunun yoxlanılmasıTəsdiqlənmiş SAPI, keşin yanlış yönləndirilməsini aradan qaldırmaq üçün faktiki Web linki ilə qurulmuş və konfiqurasiya edilmişdir.
biznesin mövcudluğuSessiya, yükləmə, idxal və səhvlərin idarə edilməsi kimi əsas funksiyalar normal şəkildə geri döndü.
Müvəqqəti tədbirlərin dayandırılmasıLimitsiz yaddaş və həddindən artıq işçi təkrar emal konfiqurasiyaları tutum planına uyğun olaraq bərpa edildi və ya saxlanması üçün aydın bir səbəb var
Dəyişikliyin sübutuPaket versiyasını və ya şəkil həzmini, yeniləmənin əhatə dairəsini, tamamlanma vaxtını və yoxlama nəticələrini qeyd edin

Yuxarıdakılar həyata keçirmək üçün təkliflərdir. OOM davranışını, anormal çıxışı və ya xüsusi yamaqları yoxlamaq lazımdırsa, qəbul üsulu kimi istehsal mühitində təkrar yaddaş tükənməsi yaratmamaq üçün təcrid olunmuş mühitdə yuxarı reqressiya testindən və ya idarə olunan nasazlıq inyeksiyasından istifadə etməlisiniz.

Həmçinin PHP ölümcül, işçi qəzası, anormal yenidən başladın, sorğu xətası dərəcəsi və yeniləmədən əvvəl və sonra WAF hadisələrini yoxlayın. Qeydlər yalnız araşdırma ipuçlarını verə bilər: OOM-nin baş verməsi onun istismar edildiyi anlamına gəlmir və həyəcan siqnallarının olmaması heç bir istismarın baş vermədiyini sübut etmir. Təkmilləşdirmə gələcəkdə əldə edilə biləcək zəiflik yollarını düzəldir; faylların dəyişdirilməsi və ya etimadnamənin sızması kimi anomaliyalar aşkar edilərsə, hadisə ilə bağlı ayrıca araşdırmalar aparılmalıdır.

Əlavə: İstinad edilən mənbələr və keçidlər

Bütün mənbə bağlantıları aşağıda toplanmışdır. Məsləhətlər, yamaqlar və satıcı təlimatları 22 oktyabr 2026 tarixinə olan yoxlamaları əks etdirir; sonrakı yerləşdirmələr satıcı yeniləmələrini yoxlamalıdır. Mətndə nömrələnmiş sitatlar bu qeydlərə aiddir.

S1 — PHP rəsmi təhlükəsizlik bülleteni və təmir versiyası

  • Mənbə: Layihə PHP, 21 oktyabr 2026-cı il.
  • Məqsəd: Risk dairəsi, dörd rəsmi təmir versiyası, rəsmi müvəqqəti tədbirlər və köhnə filiallar üçün təcili yardım təlimatları.
  • İstinad: PHP 2026 This security bulletin illik bülleten arxivindədir

S2 — CVE-2026-109618 Rəsmi Texniki Bülleten

  • Mənbə: php/php-src GitHub Security Advisory, 21 oktyabr 2026-cı il.
  • Eyniləşdirmə: GHSA-w8hw-w9fx-j79w.
  • Məqsəd: OOM, çoxhissəli gücləndirmə, SAPI fərqi və azaldılması üçün əhatə dairəsi.
  • İstinad: RCE via OOM corruption

S3 — CVE-2026-109619 Rəsmi Texniki Bülleten

  • Mənbə: php/php-src GitHub Security Advisory, 21 oktyabr 2026-cı il.
  • Eyniləşdirmə: GHSA-6wmf-4rv5-p3rp.
  • Məqsəd: Çarpaz sorğu sallanan dövlət, istehsalçılar və istehlakçılar, erkən başlatma, konfiqurasiyanın azaldılması.
  • İstinad: RCE via stale global state

S4 — PHP 8.5 rəsmi düzəliş təqdimatı

  • Mənbə: php/php-src.
  • Göndər: 31c0ea7d7ff1d1fccb6492e52dab544011628065.
  • Məqsəd: Eyni zamanda iki zəifliyi aradan qaldırmaq üçün rəsmi təqdimatı təsdiqləyin və ümumi dəyişiklik istiqamətini izah edin.
  • İstinad: Avoid state corruption via bailout

S5 — PHP 8.5 Rəsmi bərpa olunub və tam fərq

  • Mənbə: eyni rəsmi təqdimatdan fərqli.
  • Məqsəd: Ayırıcının, VM, HTTP globals, sessiya, seriallaşdırma və sorğunun həyat dövrünün xüsusi icrasını yoxlayın.
  • İstinad: official complete diff

S6 — PHP 8.1 rəsmi təcili yardım təqdimatı

S7 — PHP 7.4 rəsmi təcili yardım şöbəsi

S8 — PHP 8.0 rəsmi təcili yardım şöbəsi

S9 — PHP 8.1 rəsmi təcili yardım şöbəsi

S10 — Ubuntu Təhlükəsizlik Bülleteni USN-8948-1

  • Mənbə: Canonical / Ubuntu, 21 oktyabr 2026-cı il.
  • Məqsəd: Backport və tam paket versiyası nümunələrini buraxın.
  • İstinad: USN-8948-1: PHP vulnerabilities

S11 — PHP-FPM Configuration Təlimat

  • Mənbə: PHP rəsmi sənədi.
  • Məqsəd: Konfiqurasiya semantikası, məsələn, php_admin_value, php_admin_flag, pm.max_requests və s.
  • İstinad: PHP-FPM Configuration

S12 — PHP Əsas INI Konfiqurasiya Təlimatı

  • Mənbə: PHP rəsmi sənədi.
  • Məqsəd: Sorğu orqanının tərifi və əhatə dairəsi, yükləmə, yaddaş və avtomatik POST oxu konfiqurasiyası.
  • İstinad: Description of core php.ini directives

S13 — Nginx tələb bədən ölçüsü limiti

S14 — Nginx FastCGI sorğu buferi

S15 — Nginx Vəziyyət və qaytarma təlimatları

  • Mənbə: Nginx rəsmi sənədi.
  • Məqsəd: if və return konfiqurasiya sintaksisi.
  • İstinad: ngx_http_rewrite_module

S16 — Cloudflare PHP2Shell Qoruma Təlimatları