---
title: "PHP2Shell: មូលហេតុ និងការណែនាំអំពីដំណោះស្រាយ"
description: "ស្វែងយល់ពីគុណវិបត្តិនៃវដ្តជីវិត PHP2Shell ការធ្វើឱ្យប្រសើរពេលវេលាដំណើរការ ការបន្ធូរបន្ថយបណ្តោះអាសន្ន ការជ្រើសរើសបំណះ និងការផ្ទៀងផ្ទាត់តាមរយៈផ្លូវសំណើ Web ផ្ទាល់។"
language: "km"
url: "https://keendigit.com/km/insights/php2shell-remediation-guide"
author: "KeenDigit"
published: "2026-10-22"
---

# PHP2Shell: មូលហេតុ និងការណែនាំអំពីដំណោះស្រាយ

ស្វែងយល់ពីគុណវិបត្តិនៃវដ្តជីវិត PHP2Shell ការធ្វើឱ្យប្រសើរពេលវេលាដំណើរការ ការបន្ធូរបន្ថយបណ្តោះអាសន្ន ការជ្រើសរើសបំណះ និងការផ្ទៀងផ្ទាត់តាមរយៈផ្លូវសំណើ Web ផ្ទាល់។

**Sources បានពិនិត្យនៅថ្ងៃទី 22 ខែតុលា ឆ្នាំ 2026។** **Audience: PHP ប្រតិបត្តិករកម្មវិធី អ្នកឆ្លើយតបសុវត្ថិភាព និងវិស្វករដែលរក្សា PHP builds.**

អត្ថបទនេះសង្ខេបអំពីមូលហេតុ វិសាលភាពនៃផលប៉ះពាល់ ដំណើរការជួសជុលផ្លូវការ វិធានការកាត់បន្ថយបណ្តោះអាសន្ន និងការអនុវត្តបំណះផ្លូវការនៃភាពងាយរងគ្រោះ PHP2Shell ។ អត្ថបទចម្បងត្រូវបានដកស្រង់ដោយប្រើលេខដូចជា [S1](https://keendigit.com/km/insights/php2shell-remediation-guide#source-1); តំណប្រភពទាំងអស់ត្រូវបានរាយក្នុងឧបសម្ព័ន្ធនៅចុងបញ្ចប់នៃអត្ថបទ។ បំណែកនៃការកំណត់រចនាសម្ព័ន្ធគឺជាគំរូនៃការដាក់ពង្រាយ ដែលត្រូវការកែតម្រូវដោយផ្អែកលើកំណែជាក់ស្តែង សមត្ថភាពអាជីវកម្ម និងទំនាក់ទំនងមរតកនៃការកំណត់រចនាសម្ព័ន្ធ។

## TL;DR៖ ជំហានជួសជុល និងសំណូមពរ

1. **ធ្វើឱ្យប្រសើរឡើង PHP ពេលដំណើរការ** ៖ ធ្វើឱ្យប្រសើរឡើងនូវសាខាពាក់ព័ន្ធយ៉ាងហោចណាស់ **8.2.35 , 8.3.36 , 8.4.27 ឬ 8.5.12** . សម្រាប់កញ្ចប់ចែកចាយ សូមប្រើកំណែកញ្ចប់ពេញលេញដែលអ្នកលក់បញ្ជាក់ថាជួសជុល CVEs ទាំងពីរ។ [S1](https://keendigit.com/km/insights/php2shell-remediation-guide#source-1) [S10](https://keendigit.com/km/insights/php2shell-remediation-guide#source-10)
2. **ជំនួសដំណើរការចាស់ទាំងអស់**៖ ចាប់ផ្តើមឡើងវិញ ឬវិលជុំវិញរាល់ PHP worker សេវាបង្ហោះ និងកុងតឺន័របន្ទាប់ពីការអាប់ដេត ហើយបញ្ជាក់ថាវត្ថុចាស់ៗបានចាកចេញ។
3. **ផ្ទៀងផ្ទាត់តាមរយៈផ្លូវសំណើ Web ពិតប្រាកដ**៖ ពិនិត្យមើល Web SAPI កំណែកញ្ចប់ពេញលេញ និងដំណើរការឧទាហរណ៍។ ការពិនិត្យមើល `php -v` តែម្នាក់ឯងមិនបញ្ជាក់ថាសេវាបន្តផ្ទាល់ត្រូវបានជួសជុលទេ។
4. **Run ត្រួតពិនិត្យការតំរែតំរង់អាជីវកម្ម និងស្ដារថវិកាធនធានធម្មតា**៖ សាកល្បងការចូល ការគ្រប់គ្រងសម័យ ការបង្ហោះ ការនាំចូល និងការដោះស្រាយកំហុស។ ប្រសិនបើដែនកំណត់អង្គចងចាំ PHP ត្រូវបានដកចេញជាបណ្ដោះអាសន្ន សូមស្ដារថវិកាកំណត់សមស្របមួយឡើងវិញបន្ទាប់ពីការបំណះ។
5. **ប្រសិនបើការអាប់ដេតភ្លាមៗគឺមិនអាចទៅរួច**៖ ដាក់កម្រិតចរាចរណ៍ដែលមិនគួរឱ្យទុកចិត្ត មុនពេលវាទៅដល់ PHP ។ វាយតម្លៃការបិទដំណើរការការអាប់ឡូត និងដានដ៏គ្រោះថ្នាក់ PHP 8.5 ដូចដែលបានពិពណ៌នានៅក្នុងផ្នែកទី 5។ ការបន្ធូរបន្ថយការកំណត់រចនាសម្ព័ន្ធ និងច្បាប់ WAF មានកម្រិតគ្របដណ្តប់ និងមិនអាចជំនួសការធ្វើឱ្យប្រសើរឡើងបានទេ។ [S1](https://keendigit.com/km/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)

## 1. ទិដ្ឋភាពទូទៅនៃភាពងាយរងគ្រោះ និងការវិនិច្ឆ័យហានិភ័យ

PHP2Shell នៅក្នុងអត្ថបទនេះសំដៅទៅលើភាពងាយរងគ្រោះកម្រិត Critical ចំនួនពីរដែលត្រូវបានបង្ហាញជាផ្លូវការដោយ PHP កាលពីថ្ងៃទី 21 ខែតុលា ឆ្នាំ 2026។ ទាំងពីរនេះទាក់ទងទៅនឹងអង្គចងចាំ និងស្នើសុំការគ្រប់គ្រងវដ្តជីវិតរបស់ម៉ាស៊ីន PHP ដែលបង្កហានិភ័យនៃការកាត់កូដពីចម្ងាយ។ [S1](https://keendigit.com/km/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)

| គម្រោង                         | CVE-2026-109618                                                                                                      | CVE-2026-109619                                                                    |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| ឈ្មោះផ្លូវការ                  | RCE via OOM corruption                                                                                               | RCE via stale global state                                                         |
| បញ្ហាស្នូល                     | ការ​ចងចាំ​មិន​គ្រប់គ្រាន់​បណ្តាល​ឱ្យ​លោត​ខុស​ប្រក្រតី ដោយ​បន្សល់​ទុក​នូវ​ស្ថានភាព​ដែល​មិន​ទាន់​បញ្ចប់​ការ​ចាប់ផ្តើម។ | ស្ថានភាពសកលដែលនៅសេសសល់ក្នុងកម្មករចង្អុលទៅអង្គចងចាំសំណើដែលបានចេញផ្សាយ។              |
| ពេលវេលាកើតឡើងធម្មតា។           | ការចាប់ផ្តើម ការប្រតិបត្តិ ឬដំណើរការសម្អាតនៃសំណើបច្ចុប្បន្ន                                                          | សំណើពីមុនទុកស្ថានភាព ហើយសំណើបន្តបន្ទាប់ប្រើប្រាស់វាជាមុន។                          |
| តើ OOM ជាលក្ខខណ្ឌចាំបាច់មែនទេ? | ជាកម្មសិទ្ធិរបស់យន្តការកេះស្នូលនៃភាពងាយរងគ្រោះ                                                                       | ទេ កំហុសធ្ងន់ធ្ងរផ្សេងទៀត និងការសម្អាតក្រោយការធ្វើរោគវិនិច្ឆ័យក៏អាចពាក់ព័ន្ធផងដែរ។ |
| ទិសដៅជួសជុលមូលដ្ឋាន            | ដោះស្រាយការបរាជ័យក្នុងការបែងចែក និងការស្នើសុំការបញ្ចប់ដោយសុវត្ថិភាព                                                  | ជួសជុលភាពជាម្ចាស់របស់រដ្ឋ ពេលវេលាសម្អាត និងការចាប់ផ្ដើមដំបូង                       |
| តម្រូវការការចោល                | ត្រូវតែជួសជុល                                                                                                        | ត្រូវតែជួសជុលក្នុងពេលតែមួយ                                                         |

មូលដ្ឋាន៖ ព្រឹត្តិបត្រសុវត្ថិភាពផ្លូវការចំនួនពីរ និងជួសជុលការដាក់ស្នើ។ [S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)[S4](https://keendigit.com/km/insights/php2shell-remediation-guide#source-4)

### 1.1 ការយល់ដឹងអំពីការដាក់ពង្រាយដែលរងផលប៉ះពាល់

PHP ពិចារណាជាផ្លូវការ **ទាំងអស់។ PHP ការគ្រប់គ្រងការដាក់ពង្រាយ Web សំណើ** ហានិភ័យ រួមទាំង PHP-FPM , Apache mod\_php , php-cgi , FrankenPHP , និង LiteSpeed . បានបង្ហាញ mod\_php ការវាយប្រហារអាចកើតឡើងមុនពេលដំណើរការកូដកម្មវិធី ដូច្នេះការត្រួតពិនិត្យការចូល បណ្តាញកណ្តាលនៃក្របខ័ណ្ឌ និងសុពលភាពនៃការបង្ហោះកម្មវិធីមិនអាចគ្របដណ្តប់ផ្លូវនោះបានទេ។ [S1](https://keendigit.com/km/insights/php2shell-remediation-guide#source-1)

វាចាំបាច់ក្នុងការបែងចែករវាង "ការដាក់ពង្រាយត្រូវតែជួសជុល" និង "ខ្សែសង្វាក់ការវាយប្រហារជាក់លាក់មួយត្រូវបានបញ្ជាក់ទាំងស្រុង" ។ សេចក្តីប្រកាសរបស់ CVE-2026-109618៖ FPM នឹងចេញពីដំណើរការកុមារបន្ទាប់ពីការចាប់ផ្តើមសំណើរបរាជ័យ ដោយរារាំងផ្លូវសម្អាតដែលត្រូវគ្នានៃ mod\_php បន្ទាប់ពីបរាជ័យនៃការចាប់ផ្តើម។ ទោះយ៉ាងណាក៏ដោយ ផ្លូវ OOM បន្ទាប់ពីការចាប់ផ្តើមជោគជ័យនៅតែមានហានិភ័យ។ សេចក្តីប្រកាសក៏បានកត់សម្គាល់ផងដែរថាការកេងប្រវ័ញ្ច FPM ពេញលេញសម្រាប់ CVE នេះមិនទាន់ត្រូវបានបង្ហាញនៅឡើយទេ។ ការរឹតបន្តឹងនេះមិនអាចប្រើដើម្បីសន្និដ្ឋានថា FPM មានសុវត្ថិភាពទេ ជាពិសេស CVE-2026-109619 មិនអាចមិនអើពើបានទេ។ [S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)

ព្រំដែននៃការអនុញ្ញាតភ្លាមៗសម្រាប់ការកេងប្រវ័ញ្ចដោយជោគជ័យអាស្រ័យលើអត្តសញ្ញាណនៃដំណើរការដែលបង្ហោះ PHP និងធនធានដែលវាមាន។ ជាទូទៅ ការយកចិត្តទុកដាក់គួរត្រូវបានបង់ទៅកូដគេហទំព័រ ថតផ្ទុកឡើង អត្តសញ្ញាណប័ណ្ណទិន្នន័យ សញ្ញាសម្ងាត់សេវាកម្ម និងសមត្ថភាពចូលប្រើបណ្តាញខាងក្នុង។ "ការប្រតិបត្តិលេខកូដពីចម្ងាយ" មិនមានន័យថាទទួលបានសិទ្ធិជា root ទេ។ ការវិនិច្ឆ័យលទ្ធផលនៅទីនេះគឺផ្អែកលើគំរូការអនុញ្ញាតដំណើរការ ហើយផលប៉ះពាល់ជាក់ស្តែងចាំបាច់ត្រូវវាយតម្លៃដោយភ្ជាប់ជាមួយការអនុញ្ញាតសម្រាប់ដាក់ពង្រាយ។

ស្គ្រីប CLI តែមួយដងធម្មតា មិនមានធាតុ HTTP ដូចគ្នាទេ។ ប៉ុន្តែដំណើរការដែលគ្រប់គ្រងកិច្ចការខាងក្រៅសម្រាប់រយៈពេលដ៏យូរនៅក្នុង CLI ឬរបៀបបង្កប់គួរតែនៅតែត្រូវបានបញ្ចូលក្នុងបញ្ជីសារពើភណ្ឌរយៈពេលដំណើរការ និងវដ្តជីវិត។ មានតែភាពអាស្រ័យ CMS ក្របខ័ណ្ឌ ឬ Composer ប៉ុណ្ណោះដែលត្រូវបានធ្វើបច្ចុប្បន្នភាព ហើយម៉ាស៊ីន PHP មូលដ្ឋានមិនត្រូវបានជំនួសដោយស្វ័យប្រវត្តិទេ។

## 2. ការវិភាគមូលហេតុ

### 2.1 ដំបូងយល់អំពីវដ្តជីវិតទាំងពីរ

PHP worker ជារឿយៗដោះស្រាយសំណើជាច្រើនជាបន្តបន្ទាប់។ អង្គចងចាំដែលបានបែងចែកកំឡុងពេលសំណើអាចត្រូវបានបញ្ចេញឱ្យស្មើគ្នានៅចុងបញ្ចប់នៃសំណើនេះ ខណៈពេលដែលកម្មករខ្លួនឯង និងផ្នែកសកលមួយចំនួនរបស់វានៅតែបន្តកើតមាន។

ដូច្នេះ​ម៉ាស៊ីន​ត្រូវ​រក្សា​នូវ​ឧបសគ្គ​ពីរ៖

- **កម្រិតចាប់ផ្ដើម**៖ ទិន្នន័យដែលអាចមើលឃើញដោយលេខកូដផ្សេងទៀតត្រូវតែស្ថិតក្នុងស្ថានភាពដែលអាចអាន ឆ្លងកាត់ និងបំផ្លាញដោយសុវត្ថិភាព។
- **Lifecycle constraint**៖ នៅពេលដែលការស្នើសុំអង្គចងចាំត្រូវបានដោះលែង វាលដែលរស់នៅបានយូរមិនត្រូវបន្តព្យាបាលអាសយដ្ឋាននៅក្នុងអង្គចងចាំនោះជាស្ថានភាពត្រឹមត្រូវនោះទេ។

ឧបសគ្គទាំងពីរនេះត្រូវគ្នាទៅនឹងរបៀបបរាជ័យចម្បងនៃក្រុមភាពងាយរងគ្រោះទាំងពីរ។ ដំណើរការខាងក្រោមគឺជាការពិពណ៌នាអំពីយន្តការដែលរួមបញ្ចូលការប្រកាស និងការចងក្រងបំណះ។ វាមិនមានន័យថា រាល់ការដាក់ពង្រាយមានផ្លូវដែលអាចទៅដល់បានដូចគ្នានោះទេ។ [S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)[S5](https://keendigit.com/km/insights/php2shell-remediation-guide#source-5)

### 2.2 CVE-2026-109618៖ OOM បានរំខានការអាប់ដេតស្ថានភាពដែលមិនទាន់បានបញ្ចប់

ការអនុវត្តចាស់ប្រើការលោតមិនមែនក្នុងស្រុកនៃប្រភេទ `longjmp()` ដើម្បីដោះស្រាយ OOM ហើយផ្លូវដែលពាក់ព័ន្ធនឹងចេញពីបរិបទប្រតិបត្តិបច្ចុប្បន្នតាមរយៈ `zend_bailout()` ។ គ្រោះថ្នាក់គឺថាបំណែកនៃលេខកូដ C ប្រហែលជាបានបោះពុម្ពវត្ថុថ្មី អារេ ឬស្ថានភាពស្នើសុំទៅកាន់កូដផ្សេងទៀត ប៉ុន្តែមិនទាន់បានបញ្ចប់ការចាប់ផ្ដើមវាលទាំងអស់នៅឡើយទេ។ នៅពេលនេះ ការបរាជ័យក្នុងការបែងចែកណាមួយនៅពេលពាក់ព័ន្ធអាចបណ្តាលឱ្យជំហានបិទធម្មតាត្រូវបានរំលង។ [S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)

ដំណើរការបរាជ័យអាចចែកចេញជាបួនជំហាន៖

1. បង្កើត ឬធ្វើបច្ចុប្បន្នភាពរចនាសម្ព័ន្ធផ្ទៃក្នុងសំណើ និងធ្វើឱ្យវាអាចចូលដំណើរការបាន។
2. ការបែងចែកអង្គចងចាំជាបន្តបន្ទាប់បរាជ័យ ហើយ OOM ត្រូវបានកេះ។
3. លំហូរការប្រតិបត្តិលោតចេញពីមុខងារបច្ចុប្បន្ន ហើយកូដដែលប្រើដំបូងដើម្បីបញ្ចប់ការចាប់ផ្តើម ឬស្ដារស្ថានភាពមិនត្រូវបានប្រតិបត្តិទេ។
4. សំណើសម្អាតបន្តដំណើរការរចនាសម្ព័ន្ធទាំងនេះ ហើយចាត់ទុកខ្លឹមសារមិនត្រឹមត្រូវជាវាល ឬអាសយដ្ឋានត្រឹមត្រូវ។

បញ្ហាគឺមិនមែនថាការអស់អង្គចងចាំតែងតែបណ្តាលឱ្យ RCE នោះទេ។ ផ្ទុយទៅវិញ ការហត់នឿយ **memory ផ្លាស់ប្តូរលំហូរនៃការគ្រប់គ្រង និងរំលោភលើការសន្មត់របស់ម៉ាស៊ីនអំពីរចនាសម្ព័ន្ធត្រឹមត្រូវ** ។ តម្រូវការការបែងចែកដែលបរាជ័យមិនជាប់ពាក់ព័ន្ធដោយផ្ទាល់នូវរចនាសម្ព័ន្ធដែលត្រូវបានអានមិនត្រឹមត្រូវ។ [S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)

#### ហេតុអ្វីបានជាសំណើតូចៗក៏អាចអស់អង្គចងចាំដែរ។

ចំនួនបៃនៅក្នុងតួសំណើ និងការប្រើប្រាស់ heap បន្ទាប់ពីការញែកគឺមិនដូចគ្នាទេ។ វាល A អាច​ត្រូវ​គ្នា​នឹង​ខ្សែ​ច្រើន ធាតុ​អារេ និង​វត្ថុ​ទិន្នន័យ​មេតា​នៅ​ក្នុង PHP; ភាពស្មុគស្មាញនៃរចនាសម្ព័ន្ធបញ្ចូលនឹងប៉ះពាល់ដល់កម្រិតនៃការពង្រីកអង្គចងចាំ។

បញ្ហាជាមួយពហុផ្នែកដែលបានរាយក្នុងសេចក្តីប្រកាសជាផ្លូវការរួមមានៈ គម្លាតពិនិត្យទំហំដំបូង នៅពេលដែលប្រវែងការប្រកាសដែលអាចប្រើបានត្រូវបានបាត់ ចំនួនបឋមកថាសម្រាប់ផ្នែកតែមួយមិនមានកម្រិតគ្រប់គ្រាន់ទេ ហើយការគ្រប់គ្រងឯកសារទទេនៅតែបង្កើតទិន្នន័យមេតា ដោយមានឈ្មោះដាក់បញ្ចូលបន្ថែមនូវបន្ទុកការងារអារេ។ ការដោះសោ ការឌិកូដ ឬការចាត់ចែងបញ្ចូលឡើងវិញរបស់កម្មវិធីក៏អាចជាប្រភពនៃ OOM ផងដែរ។ [S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)

ការសន្និដ្ឋានការពារពីរអាចត្រូវបានដកចេញពីនេះ:

- សំណើររឹតបន្តឹងរាងកាយត្រូវតែអនុវត្តឱ្យបានច្រើនតាមតែអាចធ្វើទៅបាន មុនពេលបញ្ចូល PHP ហើយប្រវែងអានពិតប្រាកដ និងភាពស្មុគស្មាញនៃរចនាសម្ព័ន្ធត្រូវតែយកមកពិចារណា។
- ការកំណត់ទំហំឯកសារ ចំនួនឯកសារ ឬបិទវិបផតថលបង្ហោះតែមួយមិនអាចគ្របដណ្តប់ប្រភព OOM ទាំងអស់បានទេ។

#### ហេតុអ្វីបានជាការផ្ទៀងផ្ទាត់កម្មវិធីអាចយឺតពេល

នៅក្នុង mod\_php តួសំណើអាចត្រូវបានញែកដោយស្វ័យប្រវត្តិក្នុងអំឡុងពេលដំណាក់កាលចាប់ផ្តើមសំណើ។ ទោះបីជាការចាប់ផ្ដើមបរាជ័យក៏ដោយ ការសម្អាតសំណើដែលពាក់ព័ន្ធនឹងនៅតែត្រូវបានអនុវត្ត។ ដូច្នេះ​ផ្លូវ​វាយ​ប្រហារ​ដែល​បាន​បញ្ជាក់​អាច​កើត​ឡើង​មុន​នឹង​កូដ​កម្មវិធី។ ដើម្បីកាត់បន្ថយការប៉ះពាល់នៅដំណាក់កាលនេះ ការរឹតបន្តឹងចាំបាច់ត្រូវដាក់នៅប្រូកស៊ីបញ្ច្រាស ម៉ាស៊ីនមេ Web ឬព្រំដែនផ្សេងទៀតដែលមុនដំណើរការសំណើ PHP ។ [S1](https://keendigit.com/km/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)

### 2.3 CVE-2026-109619៖ អង្គចងចាំសំណើត្រូវបានចេញផ្សាយ ឯកសារយោងសកលនៅតែមានជីវិត

បញ្ហានេះពាក់ព័ន្ធនឹងបញ្ហា សម័យ វត្ថុ ឬស្ថានភាពផ្នែកបន្ថែម៖ វាលត្រូវបានរក្សាទុកក្នុងទីតាំងចូលប្រើប្រាស់រយៈពេលវែងរបស់កម្មករ ប៉ុន្តែទិន្នន័យដែលយោងដោយវាលនេះជាកម្មសិទ្ធិរបស់សំណើតែមួយ។ ដរាបណាឯកសារយោងមិនត្រូវបានសម្អាតឲ្យបានត្រឹមត្រូវ មុនពេលដែលកញ្ចប់សំណើត្រូវបានចេញផ្សាយ សំណើជាបន្តបន្ទាប់អាចជួបប្រទះនឹងស្ថានភាព dangling បង្កើតជាការប្រើប្រាស់បន្ទាប់ពីឥតគិតថ្លៃ។ [S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)

ការវិភាគជាផ្លូវការបែងចែកលក្ខខណ្ឌនៃការកេងប្រវ័ញ្ចទៅជា "អ្នកផលិត" និង "អ្នកប្រើប្រាស់"៖

| តួនាទី ឬលក្ខខណ្ឌ | អត្ថន័យ                                                                                 | ផលប៉ះពាល់សម្រាប់ការការពារ                                                                    |
| ---------------- | --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| អ្នកផលិតរដ្ឋ     | ដាក់រដ្ឋដែលជាកម្មសិទ្ធិដោយសំណើនេះទៅក្នុងទីតាំងដែលនៅតែអាចចូលបាននៅពេលក្រោយ                | ដើម្បីពិនិត្យមើលថាតើការសម្អាតដែលត្រូវគ្នាត្រូវបានបញ្ចប់បន្ទាប់ពីការចេញក្រៅមិនប្រក្រតី        |
| ស្ថានភាពនៅតែមាន  | វា​មិន​ត្រូវ​បាន​ជម្រះ​ឬ​វា​ត្រូវ​បាន​ជម្រះ​ហើយ​បន្ទាប់​មក​បំពេញ​ដោយ​ប្រតិបត្តិការ​យឺត។ | គ្រាន់តែសម្អាតម្តងនៅដំណាក់កាលបិទមុនប្រហែលជាមិនគ្រប់គ្រាន់ទេ។                                 |
| កម្មករប្រើឡើងវិញ | កម្មករដដែលបន្តដំណើរការសំណើជាបន្តបន្ទាប់                                                 | បុគ្គលិកច្រើននាក់គ្រាន់តែជាភាពខុសគ្នានៃការកំណត់ពេល មិនមែនជាការធានាសុវត្ថិភាពនៃការចងចាំនោះទេ។ |
| អតិថិជនជឿនលឿន    | អាន ចេញផ្សាយ ឬកំណត់តម្លៃដែលនៅសល់ មុនពេលស្ថានភាពដែលត្រូវគ្នាត្រូវបានចាប់ផ្តើមជាធម្មតា។   | ត្រូវតែពិនិត្យមើល INI វគ្គ និងផ្លូវផ្សេងទៀតមុនពេលចាប់ផ្តើម                                   |

លក្ខខណ្ឌទាំងនេះចាំបាច់ត្រូវបំពេញក្នុងការរួមបញ្ចូលគ្នា; កំណត់ហេតុកំហុសណាមួយដោយខ្លួនឯងមិនបង្ហាញថាភាពងាយរងគ្រោះត្រូវបានទាញយកដោយជោគជ័យនោះទេ។ [S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)

#### វាមិនតម្រូវឱ្យមាន OOM ជាតម្រូវការជាមុនចាំបាច់នោះទេ។

កំហុសធ្ងន់ធ្ងរអាចរំខានការបោះពុម្ព និងការស្តាររដ្ឋដែលបានផ្គូផ្គង។ ការបរាជ័យក្នុងការចងក្រង ឬញែក កំហុសដែលមិនអាចចាប់បាន ការបរាជ័យ `require` និងការអស់ពេលនៃការអនុវត្តអាចទុកឱ្យរដ្ឋជាក់លាក់នៅពីក្រោយ។ ការ​ធ្វើ​រោគវិនិច្ឆ័យ​មិន​បណ្ដាល​ឱ្យ​ស្លាប់​យឺតយ៉ាវ​ក្នុង​ការ​សម្អាត​ក៏​អាច​បញ្ចូល​ព័ត៌មាន​កំហុស​ដែល​ត្រូវ​បាន​សម្អាត​រួច​មក​វិញ​ដែរ។ [S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)

ដូច្នេះ ការផ្លាស់ប្តូរ `memory_limit` ទៅជាគ្មានដែនកំណត់ មិនគ្របដណ្តប់លើសំណុំនៃភាពងាយរងគ្រោះនេះទេ។

#### "មុនពេលចាប់ផ្តើម" ចាំបាច់ត្រូវព្យាបាលដោយឡែកពីគ្នា។

ពេលវេលានៃអ្នកប្រើប្រាស់ទាំងពីរប្រភេទដែលបានបញ្ជាក់គឺខុសគ្នា៖

- **Early INI diagnostics**៖ ការកំណត់រចនាសម្ព័ន្ធមួយចំនួនបានអនុវត្តលើបញ្ហាស្នើសុំការព្រមាន ការជូនដំណឹង ឬការបដិសេធមុនពេលចាប់ផ្តើមដំណើរការធម្មតារបស់ប្រតិបត្តិករ ហើយដំណើរការវិនិច្ឆ័យអាចចូលប្រើស្ថានភាពកំហុសចាស់។
- **session upload progress**៖ វគ្គអាចត្រូវបានដំណើរការជាមុនក្នុងអំឡុងពេលដំណើរការញែកតួសំណើ ប៉ុន្តែម៉ូឌុលធម្មតា `RINIT` មិនទាន់ត្រូវបានបញ្ចប់នៅឡើយទេ។ វាមិនអាចត្រូវបានសន្និដ្ឋានថាផ្លូវមិនមានទេពីព្រោះកម្មវិធីមិនហៅ `session_start()` ច្បាស់លាស់។ [S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)

មិនមែនទាំងអស់ទេ។ INI ការកំណត់រចនាសម្ព័ន្ធមានពេលវេលាហានិភ័យដូចគ្នា។ ការកំណត់រចនាសម្ព័ន្ធកម្រិតថត mod\_php និង `PHP_VALUE` / `PHP_ADMIN_VALUE` ឆ្លងកាត់ដោយ FPM ផ្នែកខាងមុខត្រូវតែសម្គាល់ពីធម្មតា។ `php.ini` , FPM pool ការកំណត់រចនាសម្ព័ន្ធចាប់ផ្តើម និង FPM `.user.ini` . អ្នកក្រោយៗទៀតមានពេលវេលាកំណត់រចនាសម្ព័ន្ធខុសៗគ្នា ហើយមិនអាចហៅថាជាអ្នកប្រើប្រាស់ដំបូងដូចគ្នាបានទេ។ [S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)

ការបិទ `display_errors`, `log_errors` កាត់បន្ថយ `error_reporting` ឬការប្រើ `@` ប៉ះពាល់តែភាពមើលឃើញនៃការធ្វើរោគវិនិច្ឆ័យ។ ស្ថានភាពខាងក្នុងដែលពាក់ព័ន្ធអាចត្រូវបានចូលប្រើ មុនពេលសម្រេចចិត្តថាតើត្រូវបញ្ចេញកំណត់ហេតុ។ [S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)

## 3. ជួសជុលកំណែ និងការជ្រើសរើសបំណះ

### 3.1 ខ្សែបន្ទាត់ជួសជុលខាងលើផ្លូវការ

| សាខា PHP បច្ចុប្បន្ន | កំណែដំបូងដែលរួមបញ្ចូលការជួសជុលផ្លូវការនេះ។ | ការណែនាំ                                                                                                          |
| -------------------- | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- |
| 8.2                  | 8.2.35                                     | ដំឡើងកំណែទៅកំណែនេះ ឬកំណែបន្តបន្ទាប់ដែលមានការជួសជុលដូចគ្នា។                                                        |
| 8.3                  | 8.3.36                                     | ដូច​គ្នា​ខាង​លើ                                                                                                   |
| 8.4                  | 8.4.27                                     | ដូច​គ្នា​ខាង​លើ                                                                                                   |
| 8.5                  | 8.5.12                                     | ដូច​គ្នា​ខាង​លើ                                                                                                   |
| 8.1 និងកំណែមុន។      | ការ​គាំទ្រ​ទូទៅ​ខាង​លើ​ត្រូវ​បាន​បញ្ចប់    | ផ្តល់អាទិភាពដល់ការធ្វើចំណាកស្រុកទៅកាន់សាខាដែលគាំទ្រ។ ការចេញផ្សាយការត្រួតពិនិត្យរយៈពេលខ្លី ឬ LTS អ្នកផលិត backport |

កំណែ និងស្ថានភាពគាំទ្រគឺផ្អែកលើការប្រកាសជាផ្លូវការរបស់ PHP ហើយពេលវេលាមូលដ្ឋានគឺថ្ងៃទី 22 ខែតុលា ឆ្នាំ 2026។ [S1](https://keendigit.com/km/insights/php2shell-remediation-guide#source-1)

ទាំងនេះគឺជា **កម្រិតកំណែដែលបានជួសជុលសម្រាប់សាខានីមួយៗ**។ ពួកវាមិនអាចជំនួសដោយសេចក្តីថ្លែងការណ៍ដែលគ្រប់កំណែខាងក្រោម 8.5.12 ងាយរងគ្រោះទេ៖ កំណែដូចជា 8.2.35 និង 8.4.27 នៅក្នុងសាខាផ្សេងទៀតមានការជួសជុលរួចហើយ។

### 3.2 ពិនិត្យមើលកំណែកញ្ចប់ចែកចាយពេញលេញ

Distros តែងតែបន្ថែមការកែសុវត្ថិភាពដោយផ្អែកលើកំណែអាប់ដេតចាស់។ ការទទួលយកគួរតែពិនិត្យមើលកំណែចេញផ្សាយ ប្រភពឃ្លាំង កំណែកញ្ចប់ពេញលេញ និងព្រឹត្តិបត្រសុវត្ថិភាព។

ឧទាហរណ៍ កំណែកញ្ចប់ជួសជុល Ubuntu 24.04 LTS ដែលបានរាយបញ្ជីសម្រាប់ Ubuntu USN-8948-1 គឺ៖

```text
8.3.6-0ubuntu0.24.04.13
```

ផ្នែកខាងលើរបស់វានៅតែជា `8.3.6` ប៉ុន្តែកំណែកញ្ចប់ពេញលេញនៃការចែកចាយនោះត្រូវបានរួមបញ្ចូលនៅក្នុងការប្រកាសជួសជុលនេះ។ ការសន្និដ្ឋាននេះអនុវត្តតែចំពោះប្រភពនៃការចែកចាយ និងកញ្ចប់ដែលត្រូវគ្នាប៉ុណ្ណោះ ហើយមិនអាចធ្វើជាទូទៅចំពោះការសាងសង់ណាមួយដែលបង្ហាញ `8.3.6` ផងដែរ។ [S10](https://keendigit.com/km/insights/php2shell-remediation-guide#source-10)

### 3.3 ការជ្រើសរើសបំណះត្រឹមត្រូវ។

| កន្លែងកើតហេតុ                                         | ផែនការអាទិភាព                                                                             | ចំណុចសំខាន់សម្រាប់ការទទួលយក                                                           |
| ----------------------------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| ការប្រើប្រាស់កញ្ចប់ចែកចាយ PHP                         | ដំឡើងបច្ចុប្បន្នភាពសុវត្ថិភាពដែលចេញផ្សាយដោយក្រុមហ៊ុនផលិត                                  | សេចក្តីប្រកាសគ្របដណ្តប់ទាំង CVE; កំណែកញ្ចប់ពេញលេញគឺត្រឹមត្រូវ។                        |
| ប្រើកុងតឺន័រ PHP ផ្លូវការ ឬរូបភាពដែលបង្កើតដោយខ្លួនឯង។ | ធ្វើបច្ចុប្បន្នភាពរយៈពេលដំណើរការមូលដ្ឋាន បង្កើតឡើងវិញ និងដាក់ឱ្យប្រើប្រាស់                | វត្ថុដែលកំពុងដំណើរការប្រើរូបភាពថ្មី; ច្បាប់ចម្លងចាស់ទាំងអស់ត្រូវបានដកចេញ              |
| សាខាដែលគាំទ្រដោយចងក្រងដោយខ្លួនឯង។                     | ប្រើកំណែសុវត្ថិភាពផ្លូវការនៃសាខានេះ ឬសំណុំបំណះផ្លូវការពេញលេញ                              | ការផ្គូផ្គងសាខា ការបញ្ចប់ភាពអាស្រ័យ ភាពឆបគ្នានៃផ្នែកបន្ថែម និងការឆ្លងកាត់ការតំរែតំរង់ |
| ប្រធានបទ 7.4, 8.0, 8.1                                | ផ្តល់អាទិភាពដល់អ្នកផ្គត់ផ្គង់ backport; វាយតម្លៃសាខាប្រភពកូដអាសន្នផ្លូវការប្រសិនបើចាំបាច់ | កំណត់អត្តសញ្ញាណការផ្លាស់ប្តូរអាកប្បកិរិយា និងកំណត់ពេលផ្លាស់ប្តូរទៅជាកំណែដែលគាំទ្រ     |

បំណះផ្លូវការត្រូវបានចេញផ្សាយ ហើយការជួសជុលជាក់ស្តែងគួរតែចាប់ផ្តើមពីបំណះទាំងនេះ។ អត្ថបទកូដនៅក្នុងផ្នែកទី 6 គឺមានបំណងបង្ហាញការរចនា និងពិនិត្យមើលការរំលេច ហើយមិនបង្កើតបំណះពេញលេញដែលអាចត្រូវបានអនុវត្តដោយឯករាជ្យ។ [S1](https://keendigit.com/km/insights/php2shell-remediation-guide#source-1)[S4](https://keendigit.com/km/insights/php2shell-remediation-guide#source-4)[S6](https://keendigit.com/km/insights/php2shell-remediation-guide#source-6)

## 4. ដំណើរការជួសជុលជាផ្លូវការ

### 4.1 សារពើភ័ណ្ឌនៃពេលវេលាដំណើរការដែលពិតជាដោះស្រាយសំណើ

វាត្រូវបានណែនាំឱ្យបង្កើតសៀវភៅកត់ត្រាខ្លីៗ ដើម្បីកត់ត្រាយ៉ាងហោចណាស់៖

- បញ្ចូលឈ្មោះដែន ឬសេវាកម្ម ប្រូកស៊ី backend បញ្ច្រាស PHP SAPI ។
- សាខា PHP កំណែកញ្ចប់ពេញលេញ ឬរូបភាពសង្ខេប ប្រភពបង្កើត។
- FPM pool, អង្គភាពសេវាកម្មជាក់ស្តែង, កុងតឺន័រ ឬ Pod, ចំនួននៃការចម្លង។
- ផ្នែកបន្ថែម ការកំណត់រចនាសម្ព័ន្ធចម្បង និងឯកសារកំណត់រចនាសម្ព័ន្ធបន្ថែមត្រូវបានផ្ទុក។
- តើមានកំណែ PHP ផ្សេងទៀត ច្បាប់ចម្លងនៃការដាក់ពង្រាយចាស់ ឬវិបផតថលដើមដែលអាចចូលប្រើដោយផ្ទាល់បានទេ?

ទាំងនេះគឺជាការណែនាំអំពីការអនុវត្ត ដូច្នេះ "ធ្វើឱ្យប្រសើរឡើង" អាចឆ្លើយតបទៅនឹងធាតុចូលចរាចរណ៍ជាក់ស្តែងនីមួយៗ។ ជាពិសេសពិនិត្យមើលថាតើបន្ទាត់ពាក្យបញ្ជា PHP និង Web PHP ប្រើកំណែផ្សេងគ្នា រូបភាពត្រូវបានសាងសង់ ប៉ុន្តែកុងតឺន័រចាស់នៅតែដំណើរការ ផ្នែកនៃអាង ឬច្បាប់ចម្លងមិនត្រូវបានជំនួស។ល។

### 4.2 ជ្រើសរើស និងដាក់ពង្រាយការអាប់ដេតត្រឹមត្រូវ។

បញ្ជាក់កំណែជួសជុលតាមផ្នែកទី 3 និយមដោយប្រើប្រភពកញ្ចប់ដែលទុកចិត្តដែលមានស្រាប់ ឬខ្សែសង្វាក់សាងសង់ដែលបានគ្រប់គ្រង។ វិសាលភាពនៃការអាប់ដេតគួរតែរួមបញ្ចូលធាតុផ្សំដែលពិតជារៀបចំសំណើ ដូចជាកញ្ចប់ FPM ម៉ូឌុល Apache PHP គោលពីរ CGI ឬសេវាកម្មបង្កើតដែល PHP ត្រូវបានបង្កប់។

មុនពេលដំឡើងកំណែ សូមរក្សាការកំណត់រចនាសម្ព័ន្ធ និងបញ្ជីកញ្ចប់ ហើយផ្ទៀងផ្ទាត់ការចាប់ផ្តើម និងសេវាកម្មសំខាន់ៗនៅក្នុងបរិយាកាសស្រដៀងគ្នាទៅនឹងការផលិត។ សម្រាប់ផ្នែកបន្ថែមដែលរក្សាដោយខ្លួនឯង សូមពិនិត្យមើលការស្ថាបនា និងដំណើរការភាពឆបគ្នាដែលត្រូវគ្នានឹងកំណែ PHP ។ គ្រាន់តែជ្រើសរើសការប្តេជ្ញាចិត្តដែលហាក់ដូចជាពាក់ព័ន្ធពីសាខាមួយផ្សេងទៀត មិនធានាថាការដោះស្រាយទាំងអស់ត្រូវបានអនុវត្តនោះទេ។

### 4.3 ចាប់ផ្តើមឡើងវិញ ឬរំកិលលើករណីដែលកំពុងដំណើរការ

ការដំឡើងឯកសារ និងផ្ទុកកូដថ្មីទៅក្នុងដំណើរការគឺជារឿងពីរផ្សេងគ្នា។ សេវាកម្មដែលត្រូវគ្នាគួរតែត្រូវបានចាប់ផ្តើមឡើងវិញ ឬការជំនួសរំកិលគួរតែត្រូវបានបញ្ចប់ ហើយកម្មករចាស់ និងកុងតឺន័រចាស់គួរតែត្រូវបានបញ្ជាក់ថាបានចាកចេញ។

សម្រាប់ mod\_php ចាប់ផ្តើមដំណើរការ Apache ដែលបង្ហោះម៉ូឌុលឡើងវិញ។ សេវាកម្មដែលបង្កប់ PHP ត្រូវការដំណើរការបង្ហោះរបស់ពួកគេជំនួស។ សម្រាប់ FPM ការឈូសឆាយ OPcache មិនជំនួសការធ្វើបច្ចុប្បន្នភាពរយៈពេលដំណើរការ និងការចូលនិវត្តន៍របស់កម្មករចាស់នោះទេ។

នៅពេលប្រើការប្តូរដ៏ប្រណិត អ្នកត្រូវពិនិត្យមើលថាតើដំណើរការជំនាន់ចាស់នៅតែដោះស្រាយការភ្ជាប់ដ៏យូរ ឬសំណើដែលមិនទាន់សម្រេច។ កំណត់ត្រាទទួលយកគួរតែរួមបញ្ចូលសេវាកម្មជាក់ស្តែង កំណែដាក់ឱ្យប្រើប្រាស់ ផ្លាស់ប្តូរពេលវេលាបញ្ចប់ និងលទ្ធផលចេញនៃវត្ថុចាស់។

### 4.4 ផ្ទៀងផ្ទាត់តាមរយៈសំណើ Web ពិតប្រាកដ

វាត្រូវបានផ្ដល់អនុសាសន៍ឱ្យបញ្ចូលគ្នានូវបំណែកនៃភស្តុតាងខាងក្រោមជាជាងការពឹងផ្អែកតែលើពាក្យបញ្ជាកំណែតែមួយ៖

| ភស្តុតាង                                                         | អ្វីដែលអាចបញ្ជាក់បាន។                                      | មិនអាចបញ្ជាក់អ្វីតែម្នាក់ឯងបានទេ។           |
| ---------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------- |
| កម្មវិធីគ្រប់គ្រងកញ្ចប់ ឬទិន្នន័យមេតារូបភាព                      | ប្រភពនៃការដំឡើង និងការកសាងពេញលេញ                           | ចរាចរណ៍ត្រូវបានប្តូរទៅករណីនេះ។              |
| ដំណើរការ និងស្ថានភាពនៃការដាក់ពង្រាយ                              | កម្មករ ឬកុងតឺន័របញ្ចប់ការជំនួស                             | ច្រកចូលខាងក្រៅត្រូវតែឆ្លងកាត់វា។            |
| លទ្ធផល​វិនិច្ឆ័យ​ដែល​បាន​ដាក់​កំហិត​បាន​ចូល​ប្រើ​តាម​វិបផតថល​ពិត | Web SAPI ពិតប្រាកដ និងការកំណត់រចនាសម្ព័ន្ធដែលកំពុងដំណើរការ | ថាតើការចេញផ្សាយ backport គ្របដណ្តប់ CVE ពីរ |
| ការប្រកាសរបស់អ្នកលក់ ឬកំណត់ត្រាបំណះពេញលេញ                        | ការជួសជុលកំហុសនេះត្រូវបានរួមបញ្ចូលនៅក្នុងការបង្កើតនេះ។     | ការចម្លងទាំងអស់ត្រូវបានដាក់ពង្រាយ           |

`PHP_VERSION`, `PHP_SAPI`, ឯកសារកំណត់រចនាសម្ព័ន្ធដែលបានផ្ទុក និងការកំណត់រចនាសម្ព័ន្ធសង្គ្រោះបន្ទាន់អាចត្រូវបានពិនិត្យតាមរយៈសមត្ថភាពវិនិច្ឆ័យខាងក្នុងដែលមានស្រាប់ ឬវិបផតថលវិភាគបណ្តោះអាសន្ន និងគ្រប់គ្រងការចូលប្រើ។ ត្រូវប្រាកដថាសំណើមិនត្រូវបានបញ្ជូនមកវិញដោយផ្ទាល់ដោយ CDN ឬឃ្លាំងសម្ងាត់ទំព័រ។ ដកធាតុវិនិច្ឆ័យបណ្តោះអាសន្ននៅពេលបញ្ចប់។

`php -v` ជាធម្មតាបង្ហាញតែលេខគោលពីរ CLI បច្ចុប្បន្នដែលត្រូវបានជ្រើសរើសដោយសែល។ ពាក្យបញ្ជាដូចជា `php-fpm -i` មិនស្មើនឹងការផ្ទៀងផ្ទាត់កម្មករដែលមានស្រាប់ដែលកំពុងទទួលចរាចរណ៍នោះទេ។ កុំបង្ហាញទំព័រ `phpinfo()` ពេញលេញទៅបណ្តាញសាធារណៈក្នុងរយៈពេលយូរ។

### 4.5 ពិនិត្យការតំរែតំរង់ធុរកិច្ច និងដកចេញការកំណត់គ្រាអាសន្ន

ផ្ទៀងផ្ទាត់ការចូលធម្មតា ការអាន និងសរសេរវគ្គ ទម្រង់ និងការបង្ហោះ ការនាំចូល ការគ្រប់គ្រងកំហុស និងស្ថេរភាពរបស់កម្មករជុំវិញមុខងារដែលរងផលប៉ះពាល់ដោយការផ្លាស់ប្តូរនេះ។ ពិនិត្យមើលថាតើអត្រាកំហុស ការពន្យាពេលការឆ្លើយតប កម្រិតនៃការចងចាំ ការចាកចេញពីដំណើរការ និងប្រេកង់បង្កើតឡើងវិញគឺខុសប្រក្រតី។

ប្រសិនបើ `memory_limit=-1` ត្រូវបានកំណត់ជាបណ្ដោះអាសន្ន ថវិកាមានកំណត់ដែលត្រូវគ្នានឹងសមត្ថភាពអាជីវកម្មនឹងត្រូវបានស្ដារឡើងវិញ បន្ទាប់ពីបំណះផ្លូវការចូលជាធរមាន។ ប្រសិនបើ `pm.max_requests=1` ត្រូវបានកំណត់ ការកំណត់រចនាសម្ព័ន្ធវដ្តជីវិតដែលវាយតម្លៃសមត្ថភាពនឹងត្រូវបានស្ដារឡើងវិញ បន្ទាប់ពីការជួសជុលត្រូវបានបញ្ជាក់។ ដែនកំណត់ទំហំបញ្ចូល និងការគ្រប់គ្រងការចូលប្រើប្រភពអាចត្រូវបានរក្សាទុក ដោយសារតម្រូវការអាជីវកម្មកំណត់។

ប្រសិនបើបញ្ហាភាពឆបគ្នាកើតឡើងកំឡុងពេលដំឡើងកំណែ អាទិភាពគួរតែត្រូវបានផ្តល់ទៅឱ្យការផ្អាកវិបផតថលដែលរងផលប៉ះពាល់ ការដាក់កម្រិតការចូលប្រើខាងក្រៅរបស់វា ឬកែតម្រូវកម្មវិធីមុនពេលត្រលប់មកវិញ។ ការអនុញ្ញាតឱ្យពេលវេលាដំណើរការដែលមិនបានជួសជុលដោយផ្ទាល់ដើម្បីបម្រើបណ្តាញសាធារណៈម្តងទៀតនឹងបើកហានិភ័យដើមឡើងវិញ។

## 5. វិធានការកាត់បន្ថយនៅពេលដែលការធ្វើឱ្យប្រសើរឡើងជាបន្ទាន់គឺមិនអាចធ្វើទៅបាន

ផ្នែកនេះត្រូវបានបម្រុងទុកសម្រាប់ការកាត់បន្ថយរយៈពេលខ្លីនៃការប៉ះពាល់ ឬកែលម្អភាពអាចរកបាន។ វិធានការនីមួយៗគ្របដណ្តប់តែផ្លូវជាក់លាក់មួយប៉ុណ្ណោះ ហើយការរួមផ្សំនៃវិធានការជាច្រើនមិនស្មើនឹងការជួសជុលពេញលេញនោះទេ។ [S1](https://keendigit.com/km/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)

### 5.1 ផ្តល់អាទិភាពដល់ការគ្រប់គ្រងចរាចរណ៍មុន PHP

ប្រសិនបើសេវាកម្មអនុញ្ញាត សូមដាក់កម្រិតជាបណ្ដោះអាសន្ននូវចំណុចបញ្ចប់ដ៏រសើបចំពោះប្រភពដែលអាចទុកចិត្តបាន ឬពង្រឹងការគ្រប់គ្រងការចូលប្រើមុនពេល PHP ។ សម្រាប់ការផ្ទុកការងារ កំណត់ទំហំការស្នើសុំ - តួខ្លួន ចំនួនវាល ចំនួនផ្នែក បឋមកថាក្នុងមួយផ្នែក និងជម្រៅសំបុក។ សេវាកម្មដែលមិនត្រូវការពហុផ្នែកអាចបដិសេធវានៅផ្នែកខាងមុខ។ [S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)

ការរឹតបន្តឹងទាំងនេះគឺដើម្បីគ្របដណ្តប់ច្រកចូលទាំងអស់ទៅកាន់ PHP ។ មានតែការស្ទាក់ចាប់ URL ដែលមានឈ្មោះថា "ផ្ទុកឡើង" នឹងខកខានធាតុផ្សេងទៀតដែលនៅតែត្រូវបានញែកដោយស្វ័យប្រវត្តិដោយ PHP នៅក្នុងផ្នែកសំណើ។ សម្រាប់ករណីដូចជាការផ្ទេរកំណាត់ ការខ្វះខាតប្រវែងដែលបានប្រកាស។ល។ ដែនកំណត់គួរតែផ្អែកលើទំហំដែលបានអានពិតប្រាកដ។ កម្មវិធីក៏គួរតែមានថវិកាទំហំលទ្ធផលរបស់វាដែរ នៅពេលបង្រួម ឬពង្រីកមាតិកាម្តងទៀត។

### គំរូកំណត់រចនាសម្ព័ន្ធ 5.2 FPM pool

ដាក់ការកំណត់ខាងក្រោមនៅក្នុងផ្នែកកំណត់រចនាសម្ព័ន្ធ **FPM pool ដែលពិតជាបម្រើសំណើ** មិនមែនជាពាក្យសំដីនៅក្នុង `php.ini` ទេ។ តម្លៃ 8M និង 4M គឺជាឧទាហរណ៍ដើម្បីកែតម្រូវសម្រាប់បន្ទុកការងារ។ ទុកកន្លែងសម្រាប់វាលទម្រង់ និងព្រំដែនពហុផ្នែក នៅពេលកំណត់សំណើ POST ទាំងមូល។ [S11](https://keendigit.com/km/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/km/insights/php2shell-remediation-guide#source-12)

```ini
; 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
```

**PHP 8.5** តែប៉ុណ្ណោះ បូក៖

```ini
php_admin_flag[fatal_error_backtraces] = off
```

មុខងារ និងព្រំដែននីមួយៗមានដូចខាងក្រោម៖

| ការកំណត់រចនាសម្ព័ន្ធ                  | ប្រសិទ្ធិភាពរំពឹងទុក                                  | ការពិពណ៌នាអំពីការរឹតបន្តឹងដែលត្រូវតែរក្សាទុក                                                                      |
| ------------------------------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| `memory_limit=-1`                     | ដកលក្ខខណ្ឌដែលអាចព្យាករណ៍បាន PHP ស្នើសុំអង្គចងចាំខាងលើ | វាមិនការពារការបរាជ័យនៃការបែងចែកមូលដ្ឋានទេ។ ការលុបចោលថវិកាដើមអាចបង្កើនហានិភ័យនៃការអស់ការចងចាំ និងការរំខានសេវាកម្ម។ |
| `post_max_size` តូចជាង                | កាត់បន្ថយទំហំនៃទិន្នន័យដែលចូលក្នុងដំណើរការញែក         | ឧបករណ៍ញែកមិនកំណត់បានស្គាល់គម្លាត; ការពង្រីកអង្គចងចាំមិនអាចរារាំងដោយឯករាជ្យបានទេ។                                  |
| `upload_max_filesize < post_max_size` | កំណត់ទំហំឯកសារតែមួយ ហើយស្នើសុំទំហំផ្ទុកលើស            | មិនដាក់កម្រិតលើវាលទាំងអស់ ទិន្នន័យមេតា ឬការបែងចែកក្នុងកម្មវិធីទេ។                                                 |
| បិទដំណើរការផ្ទុកឡើង                   | រារាំងផ្លូវដែលទាក់ទងនឹងវគ្គដែលបានបញ្ជាក់              | មិនគ្របដណ្តប់វ៉ារ្យ៉ង់រដ្ឋសកលផ្សេងទៀត។                                                                            |
| PHP 8.5 បិទដានក្រោយស្លាប់             | រារាំងអ្នកផលិតស្ថានភាពដែលពាក់ព័ន្ធដែលបានបញ្ជាក់       | មិនគ្របដណ្តប់ផ្លូវផ្សេងទៀតដូចជាវគ្គ                                                                               |

ព្រំដែនរង្វាស់បានមកពីការប្រកាសជាផ្លូវការ; សម្រាប់​វាក្យសម្ព័ន្ធ​រួម និង​ការ​កំណត់​រចនាសម្ព័ន្ធ​កម្រិត​នៃ​ការ​គ្រប់គ្រង​ន័យ​វិទ្យា សូមមើល​សៀវភៅដៃ PHP ។ [S1](https://keendigit.com/km/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/km/insights/php2shell-remediation-guide#source-11)

ការកំណត់ `php_admin_*` កម្រិតគ្រប់គ្រងមិនអាចបដិសេធដោយកម្មវិធីតាមរយៈ `ini_set()` ទេ។ រាល់ការដាក់បញ្ចូល កម្រិតថត និងការកំណត់ចូលខាងមុខគួរតែនៅតែត្រូវបានពិនិត្យឡើងវិញ ដើម្បីបញ្ជាក់ថាតម្លៃនៅលើសំណើពិតប្រាកដគឺដូចការរំពឹងទុក។ បន្ទាប់ពីការកែប្រែ បង្កើតកម្មករទាំងអស់ឡើងវិញ ដើម្បីការពារដំណើរការដែលមានស្រាប់ពីការបន្តរក្សាសភាពចាស់។

ប្រសិនបើអ្នកជ្រើសរើសកែប្រែ `php.ini` ដោយផ្ទាល់ វាក្យសម្ព័ន្ធគួរតែត្រូវបានប្តូរទៅជា៖

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

មិនដូច `php_admin_value` នៅក្នុងអាងទេ គ្រាន់តែកំណត់ `memory_limit=-1` នៅក្នុង `php.ini` មិនរារាំងកម្មវិធីពីការកែប្រែវាម្តងទៀតទេ។ ក្របខ័ណ្ឌ កូដកម្មវិធី និងការកំណត់រចនាសម្ព័ន្ធផ្សេងទៀតគួរតែត្រូវបានពិនិត្យ ដើម្បីមើលថាតើពួកគេបានកំណត់តម្លៃដែលបានកំណត់ឡើងវិញឬអត់។ នៅពេលដែលតម្រូវឱ្យមានការអនុវត្ត ប្រើការកំណត់កម្រិតគ្រប់គ្រងដែលសមរម្យសម្រាប់ SAPI បច្ចុប្បន្ន ហើយពិនិត្យមើលតម្លៃជាក់ស្តែង។ [S11](https://keendigit.com/km/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/km/insights/php2shell-remediation-guide#source-12)

បន្ថែម `fatal_error_backtraces = Off` សម្រាប់ PHP 8.5 ប៉ុណ្ណោះ។ កុំប្រើកម្រិតកម្មវិធី `ini_set()` ជាដំណោះស្រាយសម្រាប់បិទដំណើរការដំណើរការផ្ទុកឡើង ហើយកុំពឹងផ្អែកលើ FPM `.user.ini` ដើម្បីធ្វើឱ្យវាមានប្រសិទ្ធភាពមុនពេលស្នើសុំការញែក។ [S1](https://keendigit.com/km/insights/php2shell-remediation-guide#source-1)[S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)

### 5.3 គ្រប់គ្រងការចំណាយលើការដកដែនកំណត់អង្គចងចាំ PHP

`memory_limit=-1` គឺជាការបន្ធូរបន្ថយផ្លូវបណ្តោះអាសន្នសម្រាប់បរិស្ថានដែលមិនបានជួសជុល ហើយមិនគួរត្រូវបានចម្លងជាការកំណត់លំនាំដើមរយៈពេលវែងនោះទេ។ នៅពេលដែលកម្មវិធី ឬសំណើរមិនអាចគ្រប់គ្រងបាន វាអាចប្រើប្រាស់អង្គចងចាំរបស់ម៉ាស៊ីនបានកាន់តែច្រើន។ ដូច្នេះមុននឹងប្រើប្រាស់ អ្នកគួរតែវាយតម្លៃចំនួននៃការស្របគ្នា បុគ្គលិកតែមួយកំពូល និងសមត្ថភាពសេវាកម្មសរុប ហើយដាក់ពង្រាយដែនកំណត់នៃការបញ្ចូលផ្នែកខាងមុខ។ [S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)

ដែនកំណត់នៃអង្គចងចាំក្នុងកុងតឺន័រ ឬ cgroup អាចផ្តល់នូវព្រំដែនភាពអាចរកបាន ប៉ុន្តែកុំធានាថាការបែងចែកនឹងមិនបរាជ័យឡើយ។ កុងតឺន័រទាំងមូល មេ និងកម្មករទាំងអស់ក៏អាចនឹងត្រូវបានបញ្ចប់ផងដែរ នៅពេលដែលដែនកំណត់ត្រូវបានកេះ។ ភាពឯកោនៃភាពឯកោ និងយុទ្ធសាស្ត្របញ្ចប់ចាំបាច់ត្រូវវាយតម្លៃដោយភ្ជាប់ជាមួយនឹងការដាក់ពង្រាយ ហើយមិនអាចត្រូវបានគេហៅថាការការពារពេញលេញសម្រាប់ CVE ទាំងពីរនេះទេ។ [S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)

កុំជំនួសយុទ្ធសាស្រ្តខាងលើជាមួយ `RLIMIT_AS`, `RLIMIT_DATA` ឬដំណើរការដែលត្រូវគ្នាការរឹតបន្តឹងចន្លោះអាសយដ្ឋាន។ ពួកគេអាចបណ្តាលឱ្យការបែងចែកមូលដ្ឋានដោយផ្ទាល់មិនចូលទៅក្នុងផ្លូវ OOM ដែលកំពុងមានបញ្ហា។ [S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)

### ឧទាហរណ៍នៃការកំណត់រចនាសម្ព័ន្ធ 5.4 Nginx

អនុវត្តចំពោះការដាក់ពង្រាយដែល Nginx បញ្ជូនបន្តសំណើទៅ PHP-FPM ។ វាអាចត្រូវបានកំណត់នៅកម្រិតកំណត់រចនាសម្ព័ន្ធនៃសេវាកម្មបង្ហោះពិតប្រាកដ៖

```nginx
client_max_body_size 8m;
fastcgi_request_buffering on;
```

`client_max_body_size` កំណត់ទំហំរាងកាយសំណើ។ `fastcgi_request_buffering on` អនុញ្ញាតឱ្យ Nginx អានអត្ថបទសំណើពេញលេញជាមុន ហើយបន្ទាប់មកផ្ញើវាទៅផ្នែកខាងក្រោយ FastCGI ។ ថាតើវាមានប្រសិទ្ធិភាពនៅក្នុង `server` ឬ `location` ជាក់លាក់ដែរឬទេ ចាំបាច់ត្រូវពិនិត្យដោយភ្ជាប់ជាមួយទំនាក់ទំនងមរតក និងគ្របដណ្តប់ដែលមានស្រាប់។ [S13](https://keendigit.com/km/insights/php2shell-remediation-guide#source-13)[S14](https://keendigit.com/km/insights/php2shell-remediation-guide#source-14)

**Onតែនៅពេលដែលអាជីវកម្មមិនត្រូវការ multipart** អ្នកអាចបន្ថែមច្បាប់បដិសេធទៅច្រកចូលសេវាកម្មដែលត្រូវគ្នា៖

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

នេះគឺជាគំរូការរឹតបន្តឹងការចូលសាមញ្ញដោយប្រើ `if` និង `return` មិនមែនជាច្បាប់តម្រងទូទៅសម្រាប់ភាពងាយរងគ្រោះផ្នែកញែកទេ។ ផ្ទៀងផ្ទាត់វាក្យសម្ព័ន្ធនៃការកំណត់រចនាសម្ព័ន្ធ និងសំណើធម្មតាមុនពេលដាក់ឱ្យប្រើប្រាស់ ហើយពិនិត្យមើលថាតើ `error_page` ផ្ទាល់ខ្លួនបញ្ជូនបន្តសំណើ 403 ទៅ PHP ដែរឬទេ។ ការផ្គូផ្គងខ្សែអក្សរមិនផ្តល់ការធានាពេញលេញលើភាពខុសគ្នានៃការវិភាគទាំងអស់ទេ។ [S15](https://keendigit.com/km/insights/php2shell-remediation-guide#source-15)

លើសពីនេះ ការកំណត់រចនាសម្ព័ន្ធទាំងនេះមិនកំណត់ដោយស្វ័យប្រវត្តិនូវចំនួនទិន្នន័យ ចំនួនវាល ឬចំនួនវត្ថុ PHP ដែលអាចបង្រួមបានដោយកម្មវិធី។ អាជីវកម្មដែលត្រូវការផ្ទុកឡើងគួរតែប្រើការរឹតបន្តឹងបន្ថែមដែលយល់ពីរចនាសម្ព័ន្ធនៃសំណើរបស់ពួកគេ។

### 5.5 ការបន្ធូរបន្ថយជាជម្រើស៖ សំណើមួយសម្រាប់បុគ្គលិក FPM

សម្រាប់ការដាក់ពង្រាយ FPM ដែលអាចចំណាយប្រាក់លើស ការដំឡើងរយៈពេលខ្លីអាចត្រូវបានវាយតម្លៃ៖

```ini
pm.max_requests = 1
```

និងកសាងកម្មករដែលមានស្រាប់ឡើងវិញ។ វារារាំងខ្សែសង្វាក់សំណើឆ្លងដែលបានពិពណ៌នានៅកម្រិតប្រើឡើងវិញរបស់កម្មករ ប៉ុន្តែនឹងបង្កើនការបង្កើតដំណើរការ និងការចាប់ផ្តើមដំបូង។ ក្នុងពេលជាមួយគ្នានេះ វាមិនអាចជួសជុលសំណើដូចគ្នា OOM និងបញ្ហាសម្អាត CVE-2026-109618 បានទេ។ នៅពេលដែលតម្លៃតូចជាង ប៉ុន្តែធំជាង 1 វានៅតែមានបង្អួចស្នើសុំប្រើឡើងវិញ។ [S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/km/insights/php2shell-remediation-guide#source-11)

### ដែនកំណត់គ្របដណ្តប់ 5.6 WAF និង Cloudflare

Cloudflare បានប្រកាសពីការរៀបចំដាក់ពង្រាយសម្រាប់ការការពារប្រឆាំងនឹង PHP2Shell រួមទាំងផែនការ Free ។ នៅពេលប្រើប្រាស់សេវាកម្មរបស់វា អ្នកគួរតែពិនិត្យមើលថាតើចរាចរណ៍ពិតប្រាកដឆ្លងកាត់ប្រូកស៊ី ថាតើច្បាប់ការពារមានសុពលភាពដែរឬទេ និងថាតើគេហទំព័រដើមអាចត្រូវបានឆ្លងកាត់ដោយផ្ទាល់ដែរឬទេ។ សម្រាប់គម្រោងបង់ប្រាក់ អ្នកក៏ត្រូវពិនិត្យមើលការកំណត់រចនាសម្ព័ន្ធ និងការលើកលែងនៃច្បាប់គ្រប់គ្រងដែលត្រូវគ្នា។ [S16](https://keendigit.com/km/insights/php2shell-remediation-guide#source-16)

ការរកឃើញមួយចំនួនដែលត្រូវបានពិពណ៌នាដោយអ្នកលក់ប្រើប្រាស់សញ្ញាឆ្លើយតប ដូច្នេះការការពារទាំងអស់មិនអាចបកស្រាយថា "រាល់ការវាយប្រហារត្រូវបានរារាំងមុនពេលឈានដល់ PHP" ។ WAF អាចជួយកាត់បន្ថយការបង្ហាញ និងផ្តល់ព័ត៌មានសង្កេត ប៉ុន្តែការបន្តដំឡើងកំណែទៅ PHP គឺនៅតែចាំបាច់។ [S16](https://keendigit.com/km/insights/php2shell-remediation-guide#source-16)

### 5.7 ហេតុអ្វីបានជាវិធានការទូទៅមិនគ្រប់គ្រាន់

| វិធានការ ឬការវិនិច្ឆ័យ                                   | កង្វះខាត                                                                                                                     |
| -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| បិទ `file_uploads` ប៉ុណ្ណោះ។                             | មិនអាចគ្របដណ្តប់ដំណើរការពហុផ្នែកទាំងអស់ និងអនុវត្តផ្លូវ OOM ផ្ទាល់របស់វា។                                                    |
| ការកំណត់ `enable_post_data_reading=Off`                  | ផ្លាស់ប្តូរឥរិយាបថនៃការបំពេញដោយស្វ័យប្រវត្តិ POST/FILES; ពាក្យស្នើសុំនៅតែអាចអានបានដោយកម្មវិធី ហើយអាចរំខានដល់អាជីវកម្មធម្មតា។ |
| បិទការបង្ហាញកំហុស កត់ត្រា ឬប្រើ `@`                      | ដំណើរការរោគវិនិច្ឆ័យខាងក្នុងនៅតែអាចចូលប្រើស្ថានភាព dangling                                                                  |
| បង្កើនបរិមាណកម្មករ                                       | កុំបង្កើតយន្តការសម្អាតរដ្ឋប្រកបដោយសុវត្ថិភាព ឬលុបបំបាត់ការប្រើឡើងវិញនូវកម្មករតែមួយ                                           |
| កំណត់រចនាសម្ព័ន្ធតែ `disable_functions` ឬ `open_basedir` | ដែនកំណត់ទាំងនេះមិនជួសជុលអង្គចងចាំស្រទាប់ម៉ាស៊ីន C ខូចទេ។                                                                     |
| ពិនិត្យកំណែ ឬច្បាប់ចម្លងតែមួយដងប៉ុណ្ណោះ។                 | វាមិនអាចបញ្ជាក់បានទេថា ច្រកចូល និងករណីដែលកំពុងដំណើរការទាំងអស់ត្រូវបានជំនួស                                                   |
| គ្មាន​កំណត់​ហេតុ​លើក​លែង​ត្រូវ​បាន​គេ​មើល​ឃើញ​ទេ។        | វាមិនអាចបង្ហាញថាភាពងាយរងគ្រោះមិនមាន ឬថាវាមិនត្រូវបានកេងប្រវ័ញ្ចពីមុនមកនោះទេ។                                                 |

ក្នុងចំណោមពួកគេ មូលដ្ឋានយន្តការនៃការកំណត់រចនាសម្ព័ន្ធ និងភាពងាយរងគ្រោះនៃ PHP អាចត្រូវបានរកឃើញនៅក្នុង [S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/km/insights/php2shell-remediation-guide#source-3)[S12](https://keendigit.com/km/insights/php2shell-remediation-guide#source-12); ការវិនិច្ឆ័យអំពីការគ្របដណ្តប់ ការទទួលយក និងការអនុញ្ញាតគឺផ្អែកលើការផ្តល់យោបល់លើការអនុវត្តដែលដាក់ចេញដោយយន្តការទាំងនេះ។

## 6. គំនិតនៃការអនុវត្ត និងចំណុចពិនិត្យឡើងវិញនៃបំណះផ្លូវការ

### 6.1 ប្រើការជួសជុលពេញលេញសម្រាប់សាខាត្រឹមត្រូវ។

ការបញ្ជូនជាផ្លូវការតំណាងសម្រាប់ PHP 8.5 គឺ៖

```text
31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout
```

ការប្តេជ្ញាចិត្តភ្ជាប់ CVEs ពីរយ៉ាងច្បាស់លាស់ ទាំងការកែតម្រូវយន្តការចេញ OOM និងដើម្បីជួសជុលស្ថានភាពសកលដែលអាចចូលប្រើបានក្នុងដំណាក់កាលចាប់ផ្តើម។ ដាក់ស្នើទំព័រជាមួយនឹងភាពខុសគ្នាពេញលេញសូមមើល [S4](https://keendigit.com/km/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/km/insights/php2shell-remediation-guide#source-5) ។ សាខាផ្សេងទៀតគួរតែប្រើការចេញផ្សាយសុវត្ថិភាពផ្លូវការរបស់ពួកគេផ្ទាល់ ឬបំណះដែលត្រូវគ្នា ហើយវាមិនអាចត្រូវបានសន្មត់ថាការផ្លាស់ប្តូរទៅ 8.5 អាចត្រូវបានអនុវត្តដោយផ្ទាល់ទៅកំណែចាស់ណាមួយឡើយ។

### 6.2 OOM ជួសជុល៖ ស្ដារស្ថានភាពដែលអាចដំណើរការបានជាមុនសិន ហើយបន្ទាប់មកបញ្ចប់សំណើ

ការអនុវត្តជាផ្លូវការណែនាំពីរកម្រិតនៃការដំណើរការ OOM ទន់ និងរឹង៖ នៅពេលដែលកម្រិតទន់ត្រូវបានឈានដល់ ស្ថានភាពដែលមិនទាន់សម្រេចត្រូវបានកត់ត្រា ហើយការចាកចេញដែលគ្រប់គ្រងត្រូវបានអនុវត្តនៅទីតាំងសុវត្ថិភាពដូចជា VM ។ ចំណុចប្រទាក់ការបែងចែកដែលបរាជ័យអនុញ្ញាតឱ្យអ្នកហៅទូរស័ព្ទដោះស្រាយការបរាជ័យយ៉ាងច្បាស់លាស់។ សម្រាប់ការបែងចែកដែលមិនអាចត្រឡប់ការបរាជ័យដោយផ្ទាល់ ប្រសិនបើកម្រិតរឹងខ្ពស់ជាងត្រូវបានគេរំពឹងថានឹងលើសពីនោះ ដំណើរការនឹងត្រូវបានបញ្ចប់ដោយផ្ទាល់ ដើម្បីជៀសវាងការបន្តដំណើរការសំណើក្នុងស្ថានភាពមធ្យមដែលមិនមានសុវត្ថិភាព។ [S2](https://keendigit.com/km/insights/php2shell-remediation-guide#source-2)[S5](https://keendigit.com/km/insights/php2shell-remediation-guide#source-5)

ខាងក្រោមនេះគឺជាការដកស្រង់នៃកូដគន្លឹះនៅក្នុង 8.5 diff ដែលប្រើដើម្បីសម្គាល់ OOM ដែលមិនទាន់សម្រេច៖

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

VM រំខានការគ្រប់គ្រង និងទីតាំងសុវត្ថិភាពផ្សេងទៀត ហៅទូរសព្ទទៅ `zend_handle_delayed_oom()` ជាបន្តបន្ទាប់។ បរិបទប្រតិបត្តិកូដអ្នកប្រើប្រាស់របស់វាប្រើផ្លូវ unwind ដែលបានគ្រប់គ្រង។ ផ្លូវ OOM ពិបាកហៅ `_exit(137)` ។ [S5](https://keendigit.com/km/insights/php2shell-remediation-guide#source-5)

តាមទស្សនៈនៃការរចនា ការផ្លាស់ប្តូរសំខាន់ៗគឺ៖ **avoids ឆ្លងកាត់ជង់ការហៅ C តាមអំពើចិត្ត នៅពេលដែលរចនាសម្ព័ន្ធស្ថិតនៅក្នុងស្ថានភាពមធ្យម ហើយដាក់ច្រកចេញនៅទីតាំង** ដែលអាចរក្សាកម្រិតនៃរដ្ឋ។ បន្ទាប់ពីដែនកំណត់ទន់ត្រូវបានកេះ អង្គចងចាំបន្ថែមអាចត្រូវបានទាមទារដើម្បីបញ្ចប់ដំណើរការ ដូច្នេះកម្រិតទន់ថ្មីមិនអាចយល់បានថាជាដែនកំណត់ខាងលើដាច់ខាតសម្រាប់អង្គចងចាំសរុបនៃដំណើរការនោះទេ។

វាក៏មិនអាចសង្ខេបថា "PHP បានលុប `zend_bailout()` ទាំងអស់"។ បំណះនៅតែប្រើយន្តការពាក់ព័ន្ធក្នុងបរិបទជាក់លាក់។ អ្វី​ដែល​ត្រូវ​បាន​ជួសជុល​នោះ​គឺ​ការ​កំណត់​ពេល​ចេញ​ចេញ​ដ៏​គ្រោះថ្នាក់ និង​ការ​គ្រប់គ្រង​រដ្ឋ​ដែល​អម​ជាមួយ។ [S5](https://keendigit.com/km/insights/php2shell-remediation-guide#source-5)

### 6.3 អាប់ដេតអ្នកហៅចូលបែងចែក និងការញែកពហុផ្នែកជាមួយគ្នា

ប្រសិនបើអ្នកគ្រាន់តែផ្លាស់ប្តូរមុខងារបែងចែកទៅ "ត្រឡប់ NULL លើការបរាជ័យ" ហើយអ្នកហៅដើមនៅតែសន្មត់ថាទ្រនិចត្រឹមត្រូវតែងតែត្រលប់មកវិញ អ្នកនឹងណែនាំការចូលប្រើទ្រនិច null ថ្មី ឬការសម្អាតមិនពេញលេញ។ ចំណុចប្រទាក់ការបែងចែកដែលបរាជ័យនៅក្នុងបំណះត្រូវពិនិត្យឡើងវិញរួមជាមួយនឹងការត្រួតពិនិត្យអ្នកហៅចូល និងការផ្សព្វផ្សាយករណីលើកលែង។ [S5](https://keendigit.com/km/insights/php2shell-remediation-guide#source-5)

ការជួសជុលដែលទាក់ទងគ្នាច្រើនផ្នែកក៏រួមបញ្ចូលផងដែរនូវការត្រួតពិនិត្យការប្រមូលដោយផ្អែកលើបរិមាណអានជាក់ស្តែង កាត់បន្ថយដំណើរការនៃបឋមកថាដែលគ្មានប្រយោជន៍ ឬស្ទួន និងការទទួលយកតក្កវិជ្ជាការចាកចេញស្របគ្នា និងការសម្អាតនៅពេលដែល OOM កំពុងរង់ចាំ។ ការផ្លាស់ប្តូរទាំងនេះទាំងពីរកាត់បន្ថយការពង្រីកធនធាន និងធ្វើឱ្យអ្នកញែកអនុលោមតាមពិធីការ OOM ថ្មី។ [S5](https://keendigit.com/km/insights/php2shell-remediation-guide#source-5)

សម្រាប់​ក្រុម​ដែល​រក្សា​សាខា​របស់​ពួកគេ​បាន​ត្រូវ​ផ្ដល់​អនុសាសន៍​ថា​បញ្ហា​ខាង​ក្រោម​គឺ​ជា​ការ​ផ្តោត​លើ​ការ​ពិនិត្យ​កូដ​៖

- តើ​រដ្ឋ​អាច​មើល​ឃើញ​ដល់​ពិភព​ខាងក្រៅ​មុន​ពេល​ដែល​វា​ត្រូវ​បាន​គេ​ចាប់​ផ្ដើម​ពេញ​លេញ​ឬ?
- បន្ទាប់​ពី​ការ​បែងចែក​បរាជ័យ ឬ​ការ​លើក​លែង​ការ​ហៅ​ត្រឡប់​វិញ តើ​កម្មសិទ្ធិ​នៅ​តែ​មាន​លក្ខណៈ​ពិសេស និង​មិន​ច្បាស់​លាស់​ទេ?
- តើ​អ្នក​អាច​ឈាន​ដល់​ច្រក​ចេញ​នៃ​ការ​សម្អាត​រួម​គ្នា​បាន​ទេ ប្រសិន​បើ​អ្នក​បរាជ័យ​ពាក់​កណ្តាល​ផ្លូវ?
- តើ​មុខងារ​សម្អាត​អាច​ទទួល​ស្គាល់​វាល​ដែល​មិន​បាន​បង្កើត​ឡើង ឬ​បាន​ដោះលែង​ទេ?
- តើថវិកាវិភាគផ្អែកលើបរិមាណដំណើរការជាក់ស្តែង មិនមែនគ្រាន់តែជាការអះអាងនៃសំណើការជឿទុកចិត្តទេ?
- តើតម្លៃត្រឡប់ការបរាជ័យថ្មីត្រូវបានដោះស្រាយដោយអ្នកហៅចូលទាំងអស់ទេ?

ទាំងនេះគឺជាសំណួរពិនិត្យឡើងវិញដែលសង្ខេបដោយផ្អែកលើយន្តការជួសជុល ហើយមិនមែនជាការសន្និដ្ឋាននៃសវនកម្មដែលបានបញ្ចប់សម្រាប់មូលដ្ឋានកូដដែលមិនបានផ្ដល់ឱ្យនោះទេ។

### 6.4 ការជួសជុលសំណើឆ្លងកាត់៖ ការចាប់ផ្ដើមមុន ការសម្អាតចុងក្រោយនៅពេលក្រោយ

ដែលត្រូវគ្នាទៅនឹង CVE-2026-109619 បំណះនេះកែតម្រូវព្រំដែននៃវដ្តជីវិតជាច្រើនក្នុងពេលតែមួយ។ ឯកសារ និងប្រតិបត្តិការដែលបានរាយខាងក្រោមយក PHP 8.5 ខុសគ្នាជាឧទាហរណ៍។ [S5](https://keendigit.com/km/insights/php2shell-remediation-guide#source-5)

| ទីតាំង                           | ផ្លាស់ប្តូរទិសដៅ                                                            | បញ្ហាត្រូវបានដោះស្រាយ                                                                        |
| -------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| `Zend/zend_execute_API.c` ជាដើម។ | កំណត់ស្ថានភាពប្រតិបត្តិឡើងវិញដូចជា កំហុស ករណីលើកលែង អ្នកគ្រប់គ្រង វត្ថុ ។ល។ | បន្ទាប់ពីសំណើបញ្ចប់ វានៅតែមានឯកសារយោងចាស់ៗដែលអាចចូលប្រើបានដោយសំណើបន្ទាប់។                    |
| ផ្លូវចាប់ផ្តើមនៃ `main/main.c`   | ហៅ `php_basic_early_rinit()` មុនពេល SAPI ត្រូវបានធ្វើឱ្យសកម្ម               | នៅពេលដែលអ្នកប្រើប្រាស់ដំបូងកើតឡើង ស្ថានភាពមូលដ្ឋានដែលពាក់ព័ន្ធមិនទាន់ត្រូវបានចាប់ផ្តើមនៅឡើយ។ |
| ផ្លូវបិទ `main/main.c`           | បំផ្លាញ HTTP globals ហើយសម្គាល់វាថាមិនបានកំណត់                              | តម្លៃដែលបានចេញផ្សាយនៅតែត្រូវបានចាត់ទុកថាជាវត្ថុត្រឹមត្រូវ។                                   |
| មុនពេលសំណើត្រូវបានដោះលែង         | សម្អាតសារកំហុសចុងក្រោយម្តងទៀត                                               | ការ​វិភាគ​ការ​សម្អាត​យឺត​នឹង​បង្កើត​ឡើង​វិញ​នូវ​ស្ថានភាព​បញ្ហា                               |
| `ext/session/session.c`          | ដំណើរការផ្ទុកឡើង ផ្លូវដំបូងត្រូវបានចាប់ផ្តើមសម័យដំបូងជាសកល                  | ម៉ូឌុលធម្មតា RINIT ពីមុនបានចូលប្រើស្ថានភាពចាស់                                               |
| លេខ​កូដ​ដែល​ទាក់ទង​នឹង​សៀរៀល     | កំណត់ការញែកថ្នាក់ និងការហៅត្រឡប់មកវិញរបស់អ្នកប្រើក្នុងដំណើរការដំបូង         | ប្រតិបត្តិកូដអ្នកប្រើប្រាស់បន្ថែម នៅពេលដែលការចាប់ផ្តើមមិនទាន់បានបញ្ចប់                       |

ឧទាហរណ៍ លំដាប់នៃការចាប់ផ្តើមរួមមានៈ

```c
zend_activate();
php_basic_early_rinit();
sapi_activate();
```

បន្ទាប់ពី HTTP globals ត្រូវបានបំផ្លាញ បន្ថែមសញ្ញាបរាជ័យនៃស្ថានភាព៖

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

ការដកស្រង់ទាំងនេះបង្ហាញពីគោលការណ៍ពីរ៖ **initialize មុនពេលអ្នកប្រើប្រាស់ដែលអាចធ្វើបានមុនគេបំផុត និងធ្វើការសម្អាតចុងក្រោយបន្ទាប់ពីប្រតិបត្តិការចុងក្រោយដែលអាចបង្កើតស្ថានភាពឡើងវិញ។** កំណត់ទ្រនិចឡើងវិញតែក្នុងអំឡុងពេលធម្មតា RINIT ឬដំណាក់កាលបិទមុននេះ។ អាចខកខានការចូលប្រើមុន ឬក្រោយ។ [S5](https://keendigit.com/km/insights/php2shell-remediation-guide#source-5)

### 6.5 ហេតុអ្វីបានជាវាមិនត្រូវបានណែនាំអោយធ្វើ "ការជួសជុលមួយខ្សែ" ដោយខ្លួនឯង?

ការជំនួស `zend_bailout()` ទាំងអស់ជាមួយ `_exit()` ឬគ្រាន់តែបន្ថែមការពិនិត្យមើលទ្រនិចទទេនៅធាតុជាក់លាក់មួយនឹងពង្រីកបរិបទប្រតិបត្តិផ្សេងៗគ្នាជាច្រើន។ ពួកគេអាចនឹងលុបចោលវាលស្ថានភាពផ្សេងទៀត ឬពួកគេអាចផ្លាស់ប្តូរការបំផ្លិចបំផ្លាញ ពង្រីកការហៅត្រឡប់មកវិញ ដំណើរការបង្ហោះ និងស្នើសុំបញ្ចប់អត្ថន័យ។

សម្រាប់កំណែដែលបានគាំទ្រ ការជួសជុលពេញលេញដែលត្រូវបានចេញផ្សាយរួចហើយមានអាទិភាព។ ការធ្វើចំណាកស្រុកនៃសាខាផ្ទាល់ខ្លួនគួរតែកត់ត្រាប្រភពនៃបំណះ ខ្សែបន្ទាត់មូលដ្ឋានដែលអាចអនុវត្តបាន ការដោះស្រាយជម្លោះ និងការផ្លាស់ប្តូរអាកប្បកិរិយា ហើយប្រើប្រាស់ករណីប្រើប្រាស់តំរែតំរង់ចរន្តដែលត្រូវគ្នា និងការផ្ទៀងផ្ទាត់ដំណើរការអាជីវកម្មនេះ។ ការផ្ដល់យោបល់នៅទីនេះបានមកពីការវិភាគលើវិសាលភាពនៃបំណះនៅទូទាំងអ្នកបែងចែក VM វគ្គ និងសំណើការផ្លាស់ប្តូរវដ្តជីវិត។ [S4](https://keendigit.com/km/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/km/insights/php2shell-remediation-guide#source-5)

## 7. ច្រកក្រោយសង្គ្រោះបន្ទាន់នៃ PHP 7.4, 8.0, 8.1

PHP ផ្តល់ជាផ្លូវការនូវប្រភពកូដប្រភពអប្បបរមានៃសាខាចាស់ចំនួនបីដោយផ្អែកលើភាពធ្ងន់ធ្ងរ។ ឈ្មោះសាខាគឺ៖

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

សម្រាប់តំណភ្ជាប់សាខា សូមមើល [S7](https://keendigit.com/km/insights/php2shell-remediation-guide#source-7)[S8](https://keendigit.com/km/insights/php2shell-remediation-guide#source-8)[S9](https://keendigit.com/km/insights/php2shell-remediation-guide#source-9) ។ ទាំងនេះគឺជាការចែកចាយបន្ទាន់សម្រាប់ភាពងាយរងគ្រោះនេះ ហើយមិនតំណាងឱ្យការវិលត្រឡប់ទៅកាន់ការគាំទ្រជាប្រចាំសម្រាប់សាខាចាស់នោះទេ ហើយក៏មិនជំនួសការធ្វើបច្ចុប្បន្នភាពសុវត្ថិភាពផ្សេងទៀតដែរ។ [S1](https://keendigit.com/km/insights/php2shell-remediation-guide#source-1)

### 7.1 យក PHP 8.1 backport ជាឧទាហរណ៍

ការដាក់ស្នើដែលពាក់ព័ន្ធសម្រាប់ PHP 8.1 គឺ៖

```text
1d7dec178a094e6e75b229ce22754045f8c6070a
```

យុទ្ធសាស្រ្តរបស់វាអនុគ្រោះដល់ការបរាជ័យយ៉ាងឆាប់រហ័ស៖ ការហៅទូរស័ព្ទទៅ `_exit(1)` បន្ទាប់ពីចេញលទ្ធផលរោគវិនិច្ឆ័យនៅក្នុងផ្លូវ OOM ដែលត្រូវគ្នា និងរួមទាំងស្ថានភាពសកល និងការកែតម្រូវដែលពាក់ព័ន្ធផ្សេងទៀត។ ខណៈពេលដែលខាងក្នុងបិទដំណើរការដែលត្រូវគ្នានៃដំណើរការផ្ទុកឡើងវគ្គ។ សម្រាប់ការដាក់ស្នើកូដប្រភពដែលពាក់ព័ន្ធ សូមមើល [S6](https://keendigit.com/km/insights/php2shell-remediation-guide#source-6) ។

នេះគឺជាភាពខុសគ្នានៃអាកប្បកិរិយាពីការរចនា OOM ដែលបានពន្យារពេលពេញលេញនៅក្នុងសាខាដែលគាំទ្រ។ ដោយសារតែការកំណត់រចនាសម្ព័ន្ធនៅតែបង្ហាញថាដំណើរការផ្ទុកឡើងត្រូវបានបើក វាមិនមានន័យថាឥរិយាបថដំណើរការខាងក្នុងបន្ទាប់ពី backport នេះនឹងនៅតែមិនផ្លាស់ប្តូរនោះទេ។

### 7.2 តម្លៃដែលអ្នកត្រូវទទួលយកនៅពេលដាក់ពង្រាយ

ការចាកចេញពីដំណើរការដោយផ្ទាល់អាចបណ្តាលឱ្យសំណើបច្ចុប្បន្នបរាជ័យ ដោយរំលងការបិទការហៅត្រឡប់ PHP ធម្មតា និងផ្នែកនៃការបិទកម្មវិធី។ ប្រសិនបើម៉ាស៊ីនទទួលយកគំរូខ្សែស្រឡាយ វាក៏ចាំបាច់ដើម្បីវាយតម្លៃផលប៉ះពាល់នៃដំណើរការម៉ាស៊ីនទាំងមូលចេញពីការងារដំណាលគ្នាផ្សេងទៀត។ ថាតើអ្នកគ្រប់គ្រងដំណើរការអាចទាញដំណើរការជំនួសទាន់ពេលក៏គួរតែត្រូវបានរួមបញ្ចូលនៅក្នុងការផ្ទៀងផ្ទាត់ផងដែរ។

ដូច្នេះ អ្នក​ប្រើ​កំណែ​ចាស់​គួរ​ពិចារណា​តាម​លំដាប់​លំដោយ៖

1. ផ្ទេរទៅសាខា PHP ដែលគាំទ្រ និងកំណែថេររបស់វា។
2. ប្រើការចេញផ្សាយដែលគ្របដណ្តប់យ៉ាងច្បាស់ទាំង CVE ឬការធ្វើបច្ចុប្បន្នភាពក្រុមហ៊ុនផលិត LTS ។
3. ប្រសិនបើវាពិតជាស្ថិតនៅក្រោមកំណែចាស់នៃកូដប្រភព សូមប្រើ backport សង្គ្រោះបន្ទាន់ផ្លូវការនៃកំណែដែលត្រូវគ្នាដើម្បីផ្ទៀងផ្ទាត់ការផ្លាស់ប្តូរពេញលេញ និងភាពឆបគ្នា ហើយរៀបចំការផ្លាស់ប្តូរជាបន្តបន្ទាប់។

"របាយការណ៍ខាងក្រោយអប្បបរមា" នៅទីនេះពិពណ៌នាអំពីភាពឆបគ្នា និងវិសាលភាពនៃការអនុវត្តដែលត្រូវបានជ្រើសរើសដោយមន្ត្រី ហើយមិនគួរត្រូវបានបកស្រាយដោយស្វ័យប្រវត្តិថាជា "ការដោះស្រាយភាពងាយរងគ្រោះមិនពេញលេញដែលគេស្គាល់" នោះទេ។ អ្នកគួរតែវិនិច្ឆ័យដោយផ្អែកលើកូដប្រភពនៃសាខាដែលត្រូវគ្នា និងការប្រកាសរបស់អ្នកផលិត ហើយកុំលុបការផ្លាស់ប្តូរដែលគាំទ្រដោយខ្លួនឯងឡើយ។ [S1](https://keendigit.com/km/insights/php2shell-remediation-guide#source-1)[S6](https://keendigit.com/km/insights/php2shell-remediation-guide#source-6)

## 8. លក្ខណៈវិនិច្ឆ័យនៃការទទួលយក និងការត្រួតពិនិត្យតាមដាន

វាត្រូវបានណែនាំថាលទ្ធផលខាងក្រោមត្រូវបានប្រើជាមូលដ្ឋានសម្រាប់ការបញ្ចប់ការជួសជុលនេះ៖

| ធាតុទទួលយក                    | ស្តង់ដារនៃការបញ្ចប់                                                                                                                                                      |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| គ្របដណ្តប់ភាពងាយរងគ្រោះ       | ប្រកាសបង្កើត ឬអ្នកលក់ជួសជុល CVE-2026-109618 និង CVE-2026-109619                                                                                                          |
| ការគ្របដណ្តប់លើការដាក់ពង្រាយ  | វិបផតថល អាង សេវាកម្ម និងឧបករណ៍ចម្លងទាំងអស់ប្រើពេលដំណើរការដែលបានជួសជុល                                                                                                    |
| ដំណើរការមានប្រសិទ្ធិភាព       | កម្មករចាស់ ដំណើរការម៉ាស៊ីនចាស់ និងកុងតឺន័រចាស់ចេញទាំងអស់។                                                                                                                |
| ការផ្ទៀងផ្ទាត់សំណើពិតប្រាកដ   | បានបញ្ជាក់ SAPI សាងសង់ និងកំណត់រចនាសម្ព័ន្ធជាមួយតំណ Web ពិតប្រាកដ ដើម្បីលុបបំបាត់ការដឹកនាំមិនត្រឹមត្រូវនៃឃ្លាំងសម្ងាត់                                                   |
| ភាពអាចរកបានអាជីវកម្ម          | មុខងារសំខាន់ៗដូចជា សម័យ ការផ្ទុកឡើង ការនាំចូល និងការដោះស្រាយកំហុសបានត្រលប់មកវិញជាធម្មតា។                                                                                 |
| ការបញ្ចប់វិធានការបណ្តោះអាសន្ន | ការ​ចងចាំ​គ្មាន​ដែន​កំណត់ និង​ការ​កំណត់​រចនាសម្ព័ន្ធ​កែច្នៃ​របស់​កម្មករ​ខ្លាំង​ត្រូវ​បាន​ស្ដារ​ឡើង​វិញ​តាម​ផែនការ​សមត្ថភាព ឬ​មាន​ហេតុផល​ច្បាស់លាស់​សម្រាប់​ការ​រក្សា​ទុក |
| ភស្តុតាងនៃការផ្លាស់ប្តូរ      | កត់ត្រាកំណែកញ្ចប់ ឬរូបភាពសង្ខេប វិសាលភាពធ្វើបច្ចុប្បន្នភាព ពេលវេលាបញ្ចប់ និងលទ្ធផលផ្ទៀងផ្ទាត់                                                                            |

ខាងលើ​នេះ​ជា​ការ​ណែនាំ​សម្រាប់​ការ​អនុវត្ត។ ប្រសិនបើអ្នកត្រូវការផ្ទៀងផ្ទាត់ឥរិយាបថ OOM ការចេញមិនធម្មតា ឬបំណះផ្ទាល់ខ្លួន អ្នកគួរតែប្រើការធ្វើតេស្តតំរែតំរង់ខាងលើ ឬការបញ្ចូលកំហុសដែលបានគ្រប់គ្រងនៅក្នុងបរិយាកាសដាច់ស្រយាល ដើម្បីជៀសវាងការបង្កើតការហត់នឿយក្នុងការចងចាំម្តងហើយម្តងទៀតនៅក្នុងបរិយាកាសផលិតកម្មជាវិធីសាស្ត្រទទួលយក។

សូមពិនិត្យមើលផងដែរនូវ PHP ធ្ងន់ធ្ងរ ការគាំងកម្មករ ការចាប់ផ្ដើមឡើងវិញមិនប្រក្រតី អត្រាស្នើសុំកំហុស និងព្រឹត្តិការណ៍ WAF មុន និងក្រោយការធ្វើបច្ចុប្បន្នភាព។ កំណត់ហេតុអាចផ្តល់តម្រុយស៊ើបអង្កេតតែប៉ុណ្ណោះ៖ ការកើតឡើងនៃ OOM មិនមែនមានន័យថាវាត្រូវបានកេងប្រវ័ញ្ចនោះទេ ហើយការខ្វះខាតសំឡេងរោទិ៍មិនបង្ហាញថាគ្មានការកេងប្រវ័ញ្ចបានកើតឡើងនោះទេ។ ការអាប់ដេតជួសជុលផ្លូវងាយរងគ្រោះដែលអាចទៅដល់នៅពេលអនាគត។ ប្រសិនបើភាពមិនប្រក្រតីដូចជាការលួចចម្លងឯកសារ ឬការលេចធ្លាយព័ត៌មានសម្ងាត់ត្រូវបានរកឃើញ ការស៊ើបអង្កេតឧប្បត្តិហេតុដាច់ដោយឡែកគួរតែត្រូវបានអនុវត្ត។

## ឧបសម្ព័ន្ធ៖ ដកស្រង់ប្រភព និងតំណ

តំណប្រភពទាំងអស់ត្រូវបានប្រមូលនៅខាងក្រោម។ ការណែនាំ បំណះ និងការណែនាំរបស់អ្នកលក់ឆ្លុះបញ្ចាំងពីការត្រួតពិនិត្យគិតត្រឹមថ្ងៃ **October 22, 2026**; ការដាក់ពង្រាយជាបន្តបន្ទាប់គួរតែពិនិត្យមើលការអាប់ដេតរបស់អ្នកលក់។ ការដកស្រង់លេខនៅក្នុងអត្ថបទសំដៅលើធាតុទាំងនេះ។

### S1 — PHP ព្រឹត្តិបត្រសុវត្ថិភាព និងកំណែជួសជុលផ្លូវការ

- ប្រភព៖ Project PHP ថ្ងៃទី 21 ខែតុលា ឆ្នាំ 2026។
- គោលបំណង៖ វិសាលភាពហានិភ័យ, កំណែជួសជុលផ្លូវការចំនួនបួន, វិធានការបណ្តោះអាសន្នផ្លូវការ និងការណែនាំអំពីរបាយការណ៍សង្គ្រោះបន្ទាន់សម្រាប់សាខាចាស់។
- តំណភ្ជាប់៖ [PHP 2026 This security bulletin](https://www.php.net/archive/2026.php#2026-10-21-5) ស្ថិតនៅក្នុងបណ្ណសារព្រឹត្តិបត្រប្រចាំឆ្នាំ

### S2 — CVE-2026-109618 ព្រឹត្តិបត្របច្ចេកទេសផ្លូវការ

- ប្រភព៖ php/php-src GitHub Security Advisory ថ្ងៃទី 21 ខែតុលា ឆ្នាំ 2026។
- អត្តសញ្ញាណ៖ GHSA-w8hw-w9fx-j79w ។
- គោលបំណង៖ ព្រំដែនគ្របដណ្តប់សម្រាប់ OOM ការពង្រីកពហុផ្នែក ភាពខុសគ្នា SAPI និងការបន្ធូរបន្ថយ។
- តំណភ្ជាប់៖ [RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)

### S3 — CVE-2026-109619 ព្រឹត្តិបត្របច្ចេកទេសផ្លូវការ

- ប្រភព៖ php/php-src GitHub Security Advisory ថ្ងៃទី 21 ខែតុលា ឆ្នាំ 2026។
- អត្តសញ្ញាណ៖ GHSA-6wmf-4rv5-p3rp ។
- គោលបំណង៖ សំណើរឆ្លងរដ្ឋ អ្នកផលិត និងអ្នកប្រើប្រាស់ ការចាប់ផ្តើមដំបូង ការកាត់បន្ថយការកំណត់រចនាសម្ព័ន្ធ។
- តំណភ្ជាប់៖ [RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)

### S4 — PHP 8.5 ការបញ្ជូនជួសជុលជាផ្លូវការ

- ប្រភព៖ php/php-src ។
- ដាក់ស្នើ៖ `31c0ea7d7ff1d1fccb6492e52dab544011628065` ។
- គោលបំណង៖ បញ្ជាក់ការបញ្ជូនជាផ្លូវការដើម្បីជួសជុលភាពងាយរងគ្រោះពីរក្នុងពេលតែមួយ និងពន្យល់ពីទិសដៅនៃការផ្លាស់ប្តូរទាំងមូល។
- តំណភ្ជាប់៖ [Avoid state corruption via bailout](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065)

### S5 — PHP 8.5 បានស្ដារឡើងវិញជាផ្លូវការ និងខុសគ្នាទាំងស្រុង

- ប្រភព៖ ខុសគ្នាពីឯកសារផ្លូវការដូចគ្នា។
- គោលបំណង៖ ពិនិត្យមើលការអនុវត្តជាក់លាក់នៃអ្នកបែងចែក VM HTTP globals វគ្គ សៀរៀល និងវដ្តជីវិតស្នើសុំ។
- តំណភ្ជាប់៖ [official complete diff](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065.diff)

### S6 — PHP 8.1 ការបញ្ជូនសារសង្គ្រោះបន្ទាន់ជាផ្លូវការ

- ប្រភព៖ php/php-src ។
- ដាក់ស្នើ៖ `1d7dec178a094e6e75b229ce22754045f8c6070a` ។
- គោលបំណង៖ ពិនិត្យមើលការចាកចេញយ៉ាងរហ័សនៃសាខាចាស់ ហើយបង្ហោះការផ្លាស់ប្តូរឥរិយាបថដំណើរការ។
- តំណភ្ជាប់៖ [PHP 8.1 Emergency backport submission](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a)
- តំណភ្ជាប់៖ [corresponds to complete diff](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a.diff)

### S7 — PHP 7.4 សាខា backport សង្គ្រោះបន្ទាន់ផ្លូវការ

- ប្រភព៖ php/php-src, PHP សាខាកូដប្រភពដែលបានរាយក្នុងព្រឹត្តិបត្រសុវត្ថិភាពផ្លូវការ។
- តំណភ្ជាប់៖ [PHP-7.4-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619)

### S8 — PHP 8.0 សាខា backport សង្គ្រោះបន្ទាន់ផ្លូវការ

- ប្រភព៖ php/php-src, PHP សាខាកូដប្រភពដែលបានរាយក្នុងព្រឹត្តិបត្រសុវត្ថិភាពផ្លូវការ។
- តំណភ្ជាប់៖ [PHP-8.0-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619)

### S9 — PHP 8.1 សាខា backport សង្គ្រោះបន្ទាន់ផ្លូវការ

- ប្រភព៖ php/php-src, PHP សាខាកូដប្រភពដែលបានរាយក្នុងព្រឹត្តិបត្រសុវត្ថិភាពផ្លូវការ។
- តំណភ្ជាប់៖ [PHP-8.1-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619)

### S10 — Ubuntu ព្រឹត្តិបត្រសុវត្ថិភាព USN-8948-1

- ប្រភព៖ Canonical / Ubuntu ថ្ងៃទី 21 ខែតុលា ឆ្នាំ 2026។
- គោលបំណង៖ ចេញផ្សាយ backport និងឧទាហរណ៍កំណែកញ្ចប់ពេញលេញ។
- តំណភ្ជាប់៖ [USN-8948-1: PHP vulnerabilities](https://ubuntu.com/security/notices/USN-8948-1)

### S11 — សៀវភៅណែនាំ PHP-FPM Configuration

- ប្រភព៖ PHP ឯកសារផ្លូវការ។
- គោលបំណង៖ ការកំណត់រចនាសម្ព័ន្ធដូចជា `php_admin_value`, `php_admin_flag`, `pm.max_requests` ជាដើម។
- តំណភ្ជាប់៖ [PHP-FPM Configuration](https://www.php.net/manual/en/install.fpm.configuration.php)

### S12 — PHP Core INI សៀវភៅណែនាំកំណត់រចនាសម្ព័ន្ធ

- ប្រភព៖ PHP ឯកសារផ្លូវការ។
- គោលបំណង៖ និយមន័យ និងវិសាលភាពនៃតួសំណើ ការបង្ហោះ អង្គចងចាំ និងការកំណត់រចនាសម្ព័ន្ធអាន POST ដោយស្វ័យប្រវត្តិ។
- តំណភ្ជាប់៖ [Description of core php.ini directives](https://www.php.net/manual/en/ini.core.php)

### S13 — Nginx ស្នើសុំដែនកំណត់ទំហំតួ

- ប្រភព៖ Nginx ឯកសារផ្លូវការ។
- គោលបំណង៖ អត្ថន័យនៃ `client_max_body_size` និងកម្រិតកំណត់រចនាសម្ព័ន្ធដែលមាន។
- តំណភ្ជាប់៖ [ngx\_http\_core\_module / client\_max\_body\_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)

### S14 — Nginx FastCGI សតិបណ្តោះអាសន្នសំណើ

- ប្រភព៖ Nginx ឯកសារផ្លូវការ។
- គោលបំណង៖ លំដាប់ដំណើរការ និងមុខងាររបស់ `fastcgi_request_buffering` ។
- តំណភ្ជាប់៖ [ngx\_http\_fastcgi\_module / fastcgi\_request\_buffering](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_request_buffering)

### S15 — Nginx លក្ខខណ្ឌ និងការណែនាំត្រឡប់

- ប្រភព៖ Nginx ឯកសារផ្លូវការ។
- គោលបំណង៖ វាក្យសម្ព័ន្ធកំណត់រចនាសម្ព័ន្ធនៃ `if` និង `return` ។
- តំណភ្ជាប់៖ [ngx\_http\_rewrite\_module](https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#if)

### S16 — Cloudflare PHP2Shell ការណែនាំអំពីការការពារ

- ប្រភព៖ Cloudflare ប្លក់ផ្លូវការ។
- គោលបំណង៖ ការពិពណ៌នាអំពីវិសាលភាពនៃការដាក់ពង្រាយ WAF របស់ខ្លួន យន្តការរៀបចំផែនការ និងយន្តការរាវរក Free ។
- តំណភ្ជាប់៖ [Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)

## ការប្រឹក្សាថែទាំសុវត្ថិភាព

ត្រូវការជំនួយក្នុងការធ្វើបច្ចុប្បន្នភាពប្រព័ន្ធ PHP របស់អ្នកទេ? យើងអាចវាយតម្លៃការប៉ះពាល់ រៀបចំផែនការអាប់ដេត និងផ្ទៀងផ្ទាត់កម្មវិធីដែលកំពុងដំណើរការ។

[ពិភាក្សាអំពីបច្ចុប្បន្នភាពសុវត្ថិភាព](<https://keendigit.com/km/contact?service=security-remediation#form>)

[ទំព័រដើម](<https://keendigit.com/km/insights/php2shell-remediation-guide>) · [សន្ទស្សន៍មាតិកា](<https://keendigit.com/km/llms.txt>)

KeenDigit LLC · លេខសម្គាល់ឯកសារ Wyoming: 2026-002106155

[ផ្ទៀងផ្ទាត់ជាមួយរដ្ឋលេខាធិការ Wyoming](<https://wyobiz.wyo.gov/Business/filingSearch.aspx>)

© 2026 KeenDigit LLC · Sheridan, Wyoming, សហរដ្ឋអាមេរិក · រក្សាសិទ្ធិគ្រប់យ៉ាង។