--- title: "ភាពងាយរងគ្រោះ NGINX៖ មូលហេតុ ការជួសជុល និងការផ្ទៀងផ្ទាត់ផលិតកម្ម" description: "ពិនិត្យមើលភាពងាយរងគ្រោះរបស់ NGINX ថ្ងៃទី 5 ខែតុលា ឆ្នាំ 2026 តម្រូវការជាមុននៃការកំណត់រចនាសម្ព័ន្ធរបស់ពួកគេ ការជួសជុលជាក់លាក់នៃសាខា ការចែកចាយ backports និងការផ្ទៀងផ្ទាត់ផលិតកម្ម។" language: "km" url: "https://keendigit.com/km/insights/nginx-remediation-guide" author: "KeenDigit" published: "2026-10-14" updated: "2026-10-27" --- # ភាពងាយរងគ្រោះ NGINX៖ មូលហេតុ ការជួសជុល និងការផ្ទៀងផ្ទាត់ផលិតកម្ម ពិនិត្យមើលភាពងាយរងគ្រោះរបស់ NGINX ថ្ងៃទី 5 ខែតុលា ឆ្នាំ 2026 តម្រូវការជាមុននៃការកំណត់រចនាសម្ព័ន្ធរបស់ពួកគេ ការជួសជុលជាក់លាក់នៃសាខា ការចែកចាយ backports និងការផ្ទៀងផ្ទាត់ផលិតកម្ម។ កាលបរិច្ឆេទអត្ថបទប្រវត្តិសាស្ត្រ៖ 2026-10-14 (កាលបរិច្ឆេទចេញផ្សាយ និងសុវត្ថិភាព)។ ប្រភពបានពិនិត្យ និងបន្ថែមព័ត៌មានតាមរយៈ 2026-10-27 ។ អត្ថបទនេះត្រូវបានទុកក្នុងប័ណ្ណសារតាមកាលបរិច្ឆេទព្រឹត្តិការណ៍។ កំណែ និងការចេញផ្សាយបច្ចុប្បន្នភាពដែលបានចេញផ្សាយក្រោយថ្ងៃទី 14 ខែតុលា ត្រូវបានរួមបញ្ចូលដូចខាងក្រោម។ ទស្សនិកជន៖ គេហទំព័រ NGINX Open Source / NGINX Plus និងប្រតិបត្តិការប្រូកស៊ីបញ្ច្រាស និងបុគ្គលិកថែទាំ បុគ្គលិកឆ្លើយតបសុវត្ថិភាព អ្នកថែទាំចែកចាយ ក៏ដូចជាវិស្វករដែលចងក្រងដោយខ្លួនឯង NGINX និងរក្សាម៉ូឌុលភាគីទីបី។ អត្ថបទនេះផ្តោតលើភាពងាយរងគ្រោះស្នូល NGINX ចំនួនប្រាំដែលត្រូវបានបង្ហាញ និងជួសជុលយ៉ាងខ្លាំងនៅថ្ងៃទី 14 ខែតុលា ឆ្នាំ 2026 ហើយក៏ពិនិត្យមើលឡើងវិញអំពីសុវត្ថិភាពអង្គចងចាំតំណាង និងសំណើភាពងាយរងគ្រោះពីខែឧសភាដល់ខែកញ្ញា ឆ្នាំ 2026។ ខ្លឹមសារគ្របដណ្តប់លក្ខខណ្ឌកេះ មូលហេតុកម្រិតកូដ ការអនុវត្តផលប៉ះពាល់ វិធានការជួសជុលរយៈពេលខ្លី ដំណោះស្រាយការងារ។ ត្រឡប់ទៅកាន់សាខាចាស់ និងការផ្ទៀងផ្ទាត់ផលិតកម្ម។ ឯកសារយោងដូចជា [S1](https://keendigit.com/km/insights/nginx-remediation-guide#source-1) ភ្ជាប់ទៅឧបសម្ព័ន្ធប្រភព។ ការកំណត់រចនាសម្ព័ន្ធឧទាហរណ៍ត្រូវបានប្រើដើម្បីបង្ហាញតែគំនិតដាក់ពង្រាយ និងសវនកម្មប៉ុណ្ណោះ ហើយគួរតែត្រូវបានផ្ទៀងផ្ទាត់ដោយផ្អែកលើកំណែជាក់ស្តែង ការទទួលមរតកនៃការកំណត់រចនាសម្ព័ន្ធ ភាពអាស្រ័យ និងសមត្ថភាពអាជីវកម្មមុនពេលអនុវត្ត។ ## TL;DR៖ សកម្មភាពអាទិភាព 1. ផ្តល់អាទិភាពដល់ការដំឡើងសុវត្ថិភាព។ សម្រាប់ nginx.org កញ្ចប់ប្រភពបើកចំហ ធ្វើបច្ចុប្បន្នភាព Stable 1.30 សាខាយ៉ាងហោចណាស់ 1.30.6 និង Mainline 1.31 សាខាយ៉ាងហោចណាស់ 1.31.7. នៅកាលបរិច្ឆេទផ្ទៀងផ្ទាត់ 1.31.8 គឺជាចុងក្រោយបំផុត។ Mainline ដោះលែង។ ទាំងនេះគឺជាមូលដ្ឋានសាខាដាច់ដោយឡែក; កុំប្រៀបធៀបលេខរបស់ពួកគេនៅទូទាំងសាខា។ [S1](https://keendigit.com/km/insights/nginx-remediation-guide#source-1) [S2](https://keendigit.com/km/insights/nginx-remediation-guide#source-2) 2. ផ្ទៀងផ្ទាត់ការដំឡើងការចែកចាយដោយកំណែកញ្ចប់ពេញលេញ។ Ubuntu 22.04 / 24.04 / 26.04 / 26.10 មានច្រកខាងក្រោយរបស់អ្នកលក់; Debian 13 (trixie) ទាមទារយ៉ាងហោចណាស់ `1.26.3-3+deb13u10` ។ នៅឯការផ្ទៀងផ្ទាត់ កញ្ចប់ Debian 12 (bookworm) `1.22.1-9+deb12u10` នៅតែត្រូវបានសម្គាល់ថារងផលប៉ះពាល់។ ពិនិត្យ CVE នីមួយៗ; ការណែនាំ Debian 13 មិនកំណត់ថា Debian 12 ត្រូវបានជួសជុលទេ។ [S13](https://keendigit.com/km/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/km/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/km/insights/nginx-remediation-guide#source-15) 3. សវនកម្មការបញ្ចូលគ្នានៃការកំណត់រចនាសម្ព័ន្ធចំនួនប្រាំ៖ `alias + rewrite + $request_filename` , `map` + regex + ការវាយតម្លៃអថេរ, `aio + ssi + include virtual` , HTTP/3 ជាមួយ `proxy_request_buffering on` , និង `ssl_session_cache shared:...` ជាមួយនឹងស្វ័យប្រវត្តិ TLS ការបង្វិលគ្រាប់ចុចសំបុត្រវគ្គ។ វត្តមាននៃការណែនាំតែម្នាក់ឯងមិនបង្កើតភាពអាចធ្វើអាជីវកម្មបានទេ។ វាយតម្លៃផ្លូវស្នើសុំ និងវិសាលភាពកំណត់រចនាសម្ព័ន្ធ។ [S1](https://keendigit.com/km/insights/nginx-remediation-guide#source-1) [S3](https://keendigit.com/km/insights/nginx-remediation-guide#source-3) [S4](https://keendigit.com/km/insights/nginx-remediation-guide#source-4) 4. ជំនួសដំណើរការ និងធុងចាស់ទាំងអស់។ ដំណើរការ `nginx -t` បន្ទាប់មកចាប់ផ្តើមសេវាកម្មឡើងវិញ ឬអនុវត្តការដាក់ពង្រាយវិលដែលមានភាពអាចរកបានខ្ពស់។ បញ្ជាក់ថាដំណើរការ master/worker ចាស់បានចាកចេញ។ `nginx -s reload` តែឯងមិនបង្ហាញថាប្រព័ន្ធគោលពីរដែលកំពុងដំណើរការបានផ្លាស់ប្តូរទេ។ 5. ផ្ទៀងផ្ទាត់ចំណុចបញ្ចប់ជាក់ស្តែង៖ HTTP/1.1, HTTP/2, HTTP/3 ប្រសិនបើបានបើកដំណើរការ ការបង្ហោះប្រូកស៊ី និង API សាកសពសំណើ mTLS ការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រ SSI ទំព័រ និងការចូលដំណើរការ។ កត់ត្រាការបញ្ជាក់នៃកញ្ចប់ កំណែ ការសង្ខេបរូបភាព ដំណើរការដែលកំពុងដំណើរការ និងលទ្ធផលសម្រាប់ចំណុចបញ្ចប់នីមួយៗ។ 6. ប្រសិនបើការអាប់ដេតភ្លាមៗមិនអាចទៅរួច សូមដកលក្ខខណ្ឌដែលអាចអនុវត្តបាន៖ បិទដំណើរការដែលមិនចាំបាច់ SSI / AIO ឬ HTTP/3 ពិនិត្យភាពងាយរងគ្រោះ `alias` / `rewrite` / `map` សេចក្តីយោងអថេរ និងវាយតម្លៃបណ្តោះអាសន្ន `ssl_session_tickets off;` សម្រាប់រងផលប៉ះពាល់ mTLS សេវាកម្ម។ WAF , ASLR ការកំណត់អត្រា និងការផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធគ្របដណ្តប់តែលក្ខខណ្ឌមួយចំនួន និងមិនអាចជំនួសបំណះផ្លូវការបានទេ។ [S3](https://keendigit.com/km/insights/nginx-remediation-guide#source-3) [S4](https://keendigit.com/km/insights/nginx-remediation-guide#source-4) [S8](https://keendigit.com/km/insights/nginx-remediation-guide#source-8) [S12](https://keendigit.com/km/insights/nginx-remediation-guide#source-12) ## 1. ទិដ្ឋភាពទូទៅនៃភាពងាយរងគ្រោះ និងការវិនិច្ឆ័យហានិភ័យ NGINX បានចេញផ្សាយ 1.30.6 (Stable) និង 1.31.7 (Mainline) នៅថ្ងៃទី 14 ខែតុលា ឆ្នាំ 2026 ដោយដោះស្រាយបញ្ហាសុវត្ថិភាពចំនួនប្រាំ។ បីពាក់ព័ន្ធនឹងការហៀរសំបោរ ឬការប្រើប្រាស់បន្ទាប់ពីឥតគិតថ្លៃ និងទទួលបានពិន្ទុ F5 CVSS v4.0 នៃ 9.2 / Critical ។ ពីរផ្សេងទៀតប៉ះពាល់ដល់ភាពត្រឹមត្រូវនៃសំណើ HTTP/3 និងការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រអតិថិជន TLS ។ [S1](https://keendigit.com/km/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/km/insights/nginx-remediation-guide#source-2)[S3](https://keendigit.com/km/insights/nginx-remediation-guide#source-3) បែងចែកប្រព័ន្ធវាយតម្លៃ៖ nginx.org រាយបញ្ជីបញ្ហាទាំងប្រាំជា `medium` ខណៈពេលដែល F5 CVSS v4.0 និងភ្នាក់ងារសន្តិសុខជាតិមួយចំនួនចាត់ថ្នាក់បញ្ហាអង្គចងចាំទាំងបីជាការសំខាន់។ នេះមិនមែនមានន័យថា ទាំងប្រាំអនុញ្ញាតឱ្យដំណើរការកូដពីចម្ងាយដោយគ្មានលក្ខខណ្ឌនោះទេ។ ការកំណត់រចនាសម្ព័ន្ធ លទ្ធភាពទទួលបានចរាចរណ៍ និងលក្ខខណ្ឌនៅខាងក្រៅបញ្ហាគ្រប់គ្រងរបស់អ្នកវាយប្រហារ។ អំពើពុករលួយនៃការចងចាំ និង RCE ដែលអាចទុកចិត្តបាន គឺជាកម្រិតផ្សេងគ្នានៃភស្តុតាង។ [S1](https://keendigit.com/km/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/km/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/km/insights/nginx-remediation-guide#source-4) | CVE | បញ្ហាបច្ចេកទេស និងលក្ខខណ្ឌនៃការកេះធម្មតា។ | ផលប៉ះពាល់ស្នូល | ការវាយតម្លៃ និងការបោះចោល | | -------------- | ----------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | CVE-2026-15176 | ការគូសផែនទីផ្លូវ `alias` + `rewrite` ការផ្លាស់ប្តូរ URI + ការវាយតម្លៃ `$request_filename` | Heap buffer overflow, Worker គាំង; សក្តានុពល RCE ក្រោមលក្ខខណ្ឌជាក់លាក់ | F5 CVSS v4.0 9.2; ផ្តល់អាទិភាពដល់ការដោះស្រាយបញ្ហា | | CVE-2026-93479 | ការវាយតម្លៃស្គ្រីប HTTP/Stream ជាពិសេស `map` regex capture និង root directory, log variable cross-reference | សតិបណ្ដោះ​អាសន្ន​ដែល​បាន​បម្រុង​ទុក​ត្រូវ​បាន​សរសេរ​ជាន់​លើ ហើយ​ហ៊ាប​ក៏​ហៀរ​ចេញ។ សក្តានុពល RCE ក្រោមលក្ខខណ្ឌជាក់លាក់ | F5 CVSS v4.0 9.2; គឺជាហានិភ័យនៃការតំរែតំរង់បន្ទាប់ពីការជួសជុលពីមុន | | CVE-2026-97205 | SSI និម្មិតរួមបញ្ចូល និង AIO/ប្រតិបត្តិការអសមកាល; ចំនួនប្រតិបត្តិការលើស | ការប្រើប្រាស់-បន្ទាប់ពីឥតគិតថ្លៃ, Worker គាំង, ខូចការចងចាំ; សក្តានុពល RCE | F5 CVSS v4.0 9.2; ទាមទារ​ការ​កំណត់​រចនាសម្ព័ន្ធ​មិន​លំនាំដើម | | CVE-2026-95101 | HTTP/3 ស៊ុមមិនស្គាល់ត្រូវបានបំបែកនៅទូទាំងសតិបណ្ដោះអាសន្ន ការស្នើសុំប្រូកស៊ីត្រូវបានបើកដំណើរការ | ការចាក់បញ្ចូលបៃដែលមិនមែនជា DATA មិនត្រឹមត្រូវទៅក្នុងតួសំណើខាងលើ អាចរំលងដែនកំណត់ទំហំរាងកាយសំណើ | ភាពងាយរងគ្រោះនេះប៉ះពាល់ដល់ភាពត្រឹមត្រូវនៃសំណើ។ ខ្លួនវាមិនផ្តល់ការប្រតិបត្តិលេខកូដពីចម្ងាយ (RCE) ទេ។ | | CVE-2026-97629 | បានចែករំលែក TLS Session Cache ការបង្វិលសោដោយស្វ័យប្រវត្តិ និងការឆ្លុះសោ Worker | ការក្លែងបន្លំសំបុត្រសម័យ; ការឆ្លងកាត់ការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រអតិថិជនអាចកើតឡើងសម្រាប់សេវា mTLS ដែលរងផលប៉ះពាល់ | ការយកចិត្តទុកដាក់ជាពិសេសត្រូវតែត្រូវបានបង់ចំពោះផលប៉ះពាល់អាជីវកម្មនៃប្រភេទការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រ API | ពិន្ទុ CVSS ខាងលើត្រូវបានផ្តល់ដោយ F5 ដោយប្រើ v4.0; ភាពងាយរងគ្រោះដូចគ្នាអាចបង្ហាញពីភាពធ្ងន់ធ្ងរខុសៗគ្នានៅក្នុង CVSS 3.1, nginx.org ថ្នាក់ផ្ទាល់ខ្លួន និងចំណាត់ថ្នាក់នៃភាពធ្ងន់ធ្ងរនៃការចែកចាយ។ [S1](https://keendigit.com/km/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/km/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/km/insights/nginx-remediation-guide#source-4) ### 1.1 ផ្តល់អាទិភាពដល់ការបង្ហាញពីការដាក់ពង្រាយជាជាងពិន្ទុ CVE តែម្នាក់ឯង | ទម្រង់ដាក់ពង្រាយ | ចំណុចសំខាន់នៃការស៊ើបអង្កេត | អនុសាសន៍អាទិភាពនៃការចោល | | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | ប្រូកស៊ីបញ្ច្រាសបណ្តាញសាធារណៈ រួមទាំង `rewrite` ផ្ទាល់ខ្លួន `alias` និង `map` ស្មុគស្មាញ | CVE-2026-15176, CVE-2026-93479 និងការសរសេរឡើងវិញ/ភាពងាយរងគ្រោះក្នុងផែនទីចាប់ពីខែឧសភាដល់ខែកក្កដា | P0: ធ្វើសវនកម្ម និងធ្វើបច្ចុប្បន្នភាពភ្លាមៗ | | API / យន្តហោះគ្រប់គ្រងដោយប្រើវិញ្ញាបនបត្រអតិថិជនជាការផ្ទៀងផ្ទាត់ច្រកចូលតែមួយគត់ ឬសំខាន់ | សំបុត្រវគ្គ និងការកំណត់រចនាសម្ព័ន្ធឃ្លាំងសម្ងាត់ដែលបានចែករំលែកនៃ CVE-2026-97629 | P0៖ បញ្ជាក់​ព្រំដែន​ការ​ផ្ទៀងផ្ទាត់​និង​ធ្វើ​បច្ចុប្បន្នភាព​ភ្លាមៗ | | ផ្តល់ការបង្ហោះ HTTP/3 ខាងក្រៅ ចំណុចប្រទាក់ផ្លាស់ប្តូរស្ថានភាព ថ្នាក់ប្រតិបត្តិការ API | CVE-2026-95101 ជាពិសេស តួសំណើត្រូវបានបញ្ជូនទៅកាន់ផ្នែកខាងក្រោយ | P0/P1៖ រៀបចំទៅតាមសារៈសំខាន់អាជីវកម្ម | | SSI ទំព័រថាមវន្ត ឬឯកសារអសមកាល I/O | CVE-2026-97205 | P1: បញ្ជាក់លក្ខខណ្ឌនៃការបញ្ចូលគ្នា និងជួសជុលឱ្យបានឆាប់តាមដែលអាចធ្វើទៅបាន។ | | មានតែទំព័រឋិតិវន្ត + ប្រូកស៊ីបញ្ច្រាស HTTP/1.1/2 សាមញ្ញ | ការកំណត់រចនាសម្ព័ន្ធ និងកំណែនៅតែត្រូវការធ្វើសវនកម្ម ប៉ុន្តែលក្ខខណ្ឌ CVE មួយចំនួនអាចនឹងបាត់ | P1: រួមបញ្ចូលនៅក្នុងបង្អួចដំឡើងកំណែសុវត្ថិភាពសង្គ្រោះបន្ទាន់ | | ប្រើ Kubernetes សហគមន៍ ingress-nginx ដែលចូលនិវត្តន៍ | គម្រោងនេះបញ្ឈប់ការថែទាំសុវត្ថិភាព ហើយហានិភ័យមិនត្រូវបានកំណត់ចំពោះ CVEs ទាំងប្រាំនេះទេ។ | បង្កើតផែនការធ្វើចំណាកស្រុករបស់ឧបករណ៍បញ្ជាបុគ្គល | P0/P1 គឺជាការណែនាំអំពីការចោលប្រតិបត្តិការ និងការថែទាំដែលបានផ្ដល់ឱ្យក្នុងអត្ថបទនេះសម្រាប់ការប៉ះពាល់បណ្តាញសាធារណៈ និងការយល់ដឹងអំពីវិញ្ញាបនប័ត្រ។ វាមិនមែនជាការចាត់ថ្នាក់ CVSS ផ្លូវការទេ ហើយក៏មិនគួរជំនួសទ្រព្យសកម្មខាងក្នុងរបស់សហគ្រាស និងការផ្លាស់ប្តូរការវាយតម្លៃហានិភ័យដែរ។ ### 1.2 ព្រំដែនផលប៉ះពាល់ និងការអនុញ្ញាតការវាយប្រហារ ភាពងាយរងគ្រោះស្នូលនៅក្នុងក្រុមនេះមានទីតាំងនៅជាចម្បងនៅក្នុង NGINX Data Plane៖ ចំណុចចូលនៃការវាយប្រហារគឺការភ្ជាប់អតិថិជន និងការស្នើសុំ ហើយផលប៉ះពាល់ជាក់ស្តែងជាធម្មតាកើតឡើងនៅក្នុងដំណើរការ Worker ។ ប្រសិនបើលក្ខខណ្ឌដែលអាចកេងប្រវ័ញ្ចបានសម្រាប់អំពើពុករលួយអង្គចងចាំត្រូវបានបំពេញ នោះការអនុញ្ញាតដំណើរការកូដជាទូទៅត្រូវបានកម្រិតដោយអ្នកប្រើប្រាស់ដែលកំពុងដំណើរការ ឧបសគ្គកុងតឺន័រ សមត្ថភាពលីនុច ការដំឡើង និងការអនុញ្ញាតបណ្តាញរបស់ Worker ។ សក្តានុពល RCE មិនបង្កប់ន័យដោយស្វ័យប្រវត្តិនូវសិទ្ធិ root ឬការសម្របសម្រួលម្ចាស់ផ្ទះទេ។ [S4](https://keendigit.com/km/insights/nginx-remediation-guide#source-4) ប៉ុន្តែទោះបីជាដំណើរការនេះមិនមានសិទ្ធិក៏ដោយ វាអាចនៅតែអាចចូលប្រើព័ត៌មានសម្ងាត់ប្រូកស៊ី ឯកសារដែលអាចអានបានដែលមានកូនសោឯកជនវិញ្ញាបនបត្រ សញ្ញាសម្ងាត់នៃសេវាចរន្ត ឯកសារបណ្តោះអាសន្ន API ខាងក្នុង និងបណ្តាញដែលអាចចូលទៅដល់បាន។ សម្រាប់ mTLS ការឆ្លងកាត់ការផ្ទៀងផ្ទាត់ខ្លួនឯងអាចជាផលវិបាកអាជីវកម្មធ្ងន់ធ្ងរ ហើយមិនចាំបាច់ត្រូវបានអមដោយការប្រតិបត្តិកូដនោះទេ។ ## 2. ការវិភាគមូលហេតុ ### 2.1 ស្វែងយល់ពីព្រំដែនដែលងាយនឹងមានកំហុសទាំងបីនៅក្នុង NGINX NGINX worker គឺ​ជា​ដំណើរ​ការ​ដែល​ត្រូវ​បាន​ជំរុញ​ដោយ​ព្រឹត្តិការណ៍​ដែល​មាន​រយៈពេល​យូរ​ដែល​រក្សា​ស្ថានភាព​សំណើ​ ប្រតិបត្តិការ​អសមកាល​ និង​កម្មវិធី​ញែក​ពិធីការ។ ភាពងាយរងគ្រោះនេះបង្កប់នូវឧបសគ្គនៅកម្រិតវិស្វកម្មចំនួនបី៖ 1. ការវាយតម្លៃអថេរ និងទំហំអង្គចងចាំត្រូវតែស្របគ្នា៖ `rewrite` បន្ទាប់ពីផ្លាស់ប្តូរសំណើ URI ការគូសផែនទីផ្លូវត្រូវតែស្របជាមួយ `location` ដែលមានប្រសិទ្ធភាពនាពេលបច្ចុប្បន្ន។ នៅពេលអ្នកបកប្រែស្គ្រីបគណនាប្រវែងអថេរ ចន្លោះសរសេរត្រូវតែគ្របដណ្ដប់លើលទ្ធផលជាក់ស្តែង និងផ្ទៃដែលបានបម្រុងទុក។ 2. ប្រតិបត្តិការអសមកាលត្រូវតែពង្រីកវដ្តជីវិតនៃអង្គចងចាំដែលបានស្នើសុំ៖ នៅពេលដែលមានការអាន និងការសរសេរឯកសារមិនទាន់បញ្ចប់ ការរង់ចាំឃ្លាំងសម្ងាត់ ឬកិច្ចការខ្សែស្រឡាយ នោះក្រុមអង្គចងចាំសំណើដែលពាក់ព័ន្ធមិនអាចត្រូវបានបញ្ចេញជាមុនទេ។ 3. ស្ថានភាពពិធីការ និងស្ថានភាពសុវត្ថិភាពមិនអាចលាយបញ្ចូលគ្នា ឬលុបចោលបានទេ៖ HTTP/3 រយៈពេលនៃការរំលងស៊ុមមិនស្គាល់មិនអាចចាត់ទុកថាជាប្រវែងរាងកាយសំណើ DATA បានទេ។ TLS រន្ធគ្រាប់ចុចទាំងអស់ដែលចូលរួមក្នុងការផ្ទៀងផ្ទាត់ហត្ថលេខាត្រូវតែត្រូវបានចាប់ផ្តើម និងធ្វើសមកាលកម្មយ៉ាងត្រឹមត្រូវក្នុងអំឡុងពេលបង្វិលសំបុត្រវគ្គ។ ខ្លឹមសារខាងក្រោមគឺផ្អែកលើ NGINX ការប្តេជ្ញាចិត្តជួសជុល និងប្រកាសពីអ្នកលក់ ដើម្បីពន្យល់ពីយន្តការបរាជ័យដែលអាចកើតឡើង។ បំណែកឧទាហរណ៍គឺសម្រាប់ការវិភាគ មិនមែនជាកូដពេញលេញដែលអាចត្រូវបានប្រើដោយផ្ទាល់ដើម្បីជួសជុលបរិយាកាសផលិតកម្មនោះទេ។ [S5](https://keendigit.com/km/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/km/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/km/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/km/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/km/insights/nginx-remediation-guide#source-9) ### 2.2 CVE-2026-15176៖ ការគូសផែនទីផ្លូវរវាង `alias` និង URI ដែលសរសេរឡើងវិញគឺមិនត្រឹមត្រូវទេ។ នៅក្នុង NGINX `location` ដែលផ្គូផ្គង និង `alias` របស់វាកំណត់ផ្លូវឯកសារ។ `rewrite` អាចផ្លាស់ប្តូរសំណើបច្ចុប្បន្ន URI ។ បន្ទាប់ពីការសរសេរឡើងវិញ ការសន្មត់ដែលប្រើដោយការគូសផែនទី `location` ដើមប្រហែលជាលែងមានទៀតហើយ។ ផ្លូវដំណើរការដែលរងផលប៉ះពាល់មិនបានត្រួតពិនិត្យឱ្យបានគ្រប់គ្រាន់ថាតើសំណើត្រូវបានសរសេរឡើងវិញទេ នៅពេលពិនិត្យមើលស្ថានភាព `alias` នៅក្នុង `ngx_http_map_uri_to_path()` ។ នៅពេលដែលការកំណត់រចនាសម្ព័ន្ធបន្តវាយតម្លៃ `$request_filename` បន្ទាប់ពីសរសេរឡើងវិញ ផ្លូវអាចត្រូវបានសាងសង់ជាមួយនឹងការសន្មត់ដែលមិនអនុលោមតាមស្ថានភាព URI បច្ចុប្បន្ន ដែលនៅទីបំផុតបង្កឱ្យមានការសរសេរក្រៅព្រំដែនទៅកាន់អង្គចងចាំ។ [S5](https://keendigit.com/km/insights/nginx-remediation-guide#source-5) ការរួមបញ្ចូលគ្នាធម្មតា (ប្រើជាឧទាហរណ៍សម្រាប់តែសវនកម្មការកំណត់រចនាសម្ព័ន្ធ ការដាក់ពង្រាយមិនត្រូវបានណែនាំទេ)៖ ```nginx # 仅用于识别风险模式：不是修复配置 location /foo/ { alias /srv/alias-root/; rewrite ^/foo/.*$ /new-path; return 200 $request_filename; } ``` គ្រោះថ្នាក់មិនត្រូវបានកំណត់ចំពោះ `return` ទេ៖ `set`, `if`, `add_header`, `log_format` ជាដើម ក៏ចាំបាច់ត្រូវធ្វើសវនកម្មផងដែរ ប្រសិនបើការវាយតម្លៃ `$request_filename` ត្រូវបានបង្កឡើងក្នុងដំណើរការដូចគ្នា។ `return` ក្នុងឧទាហរណ៍គ្រាន់តែធ្វើឱ្យផ្លូវរដ្ឋនេះងាយស្រួលមើលប៉ុណ្ណោះ វាមិនអាចត្រូវបានប្រើដើម្បីសន្និដ្ឋានថាការកំណត់រចនាសម្ព័ន្ធផលិតកម្មទាំងអស់នឹងបង្កើតលំហូរលើស។ [S5](https://keendigit.com/km/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/km/insights/nginx-remediation-guide#source-10) ផលវិបាកនៃការវាយប្រហារ៖ ការសាងសង់សំណើអាចបណ្តាលឱ្យ Worker ចាប់ផ្តើមឡើងវិញ ឬការរំខានសេវាកម្ម។ នៅក្រោមលក្ខខណ្ឌដូចជា ASLR ត្រូវបានបិទ ឬអាចត្រូវបានឆ្លងកាត់ វាមានសក្តានុពល RCE ។ ស្នូលនៃបំណះខាងលើគឺដើម្បីបដិសេធមិនបញ្ចប់ការគូសផែនទីផ្លូវ URI ដែលសរសេរឡើងវិញនៅក្នុងបរិបទ `alias` ដែលលែងមានសុពលភាព ជាជាងការពង្រីកបណ្តុំបណ្តោះអាសន្នជាក់លាក់មួយ។ [S5](https://keendigit.com/km/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/km/insights/nginx-remediation-guide#source-10) ### 2.3 CVE-2026-93479៖ ភាពមិនស៊ីគ្នារវាង "ចន្លោះដែលបានបម្រុងទុក" និងប្រវែងអថេរពិតប្រាកដក្នុងការវាយតម្លៃស្គ្រីប ម៉ូឌុល HTTP និង Stream នៃ NGINX មានកម្មវិធីវាយតម្លៃស្គ្រីបដែលភ្ជាប់ខ្សែអក្សរ និងតម្លៃអថេរទៅក្នុងខ្សែអក្សរលទ្ធផល។ ឧទាហរណ៍នៃកម្មវិធីរួមមាន ឯកសារ HTTP ផ្លូវ root ផ្លូវចូលដំណើរការ និងកន្សោមអថេរក្នុង Stream ។ ការកំណត់រចនាសម្ព័ន្ធជាក់លាក់នៃ `map` + កន្សោមធម្មតាអនុញ្ញាតឱ្យតម្លៃចាប់យកត្រូវបានអានដោយកន្សោមផ្សេងទៀត មុនពេលអថេរលទ្ធផល `map` ត្រូវបានវាយតម្លៃ។ រួមផ្សំជាមួយវិធីសាស្ត្រប្រតិបត្តិស្គ្រីបជាមួយនឹងប្រវែងដែលបានបម្រុងទុក ការអនុវត្តចាស់នឹងរាប់ទំហំដែលបានបម្រុងទុក `len` ទៅក្នុងឧបករណ៍ប្រមូលប្រវែងដែលបានវាយតម្លៃជាមុន ដូច្នេះការគណនាទ្រនិចសរសេរជាបន្តបន្ទាប់លែងស្របនឹងព្រំដែនសតិបណ្ដោះអាសន្នទៀតហើយ។ នៅក្នុងលំដាប់វាយតម្លៃអថេរជាក់លាក់ ការសរសេរខ្សែអក្សរបន្តបន្ទាប់អាចសរសេរជាន់លើផ្ទៃដែលបានបម្រុងទុក ដែលបណ្តាលឱ្យមានលើសចំណុះ។ [S6](https://keendigit.com/km/insights/nginx-remediation-guide#source-6) | ធាតុចូលរួម | ហេតុអ្វីបានជាវាគួរអោយយកចិត្តទុកដាក់ | | -------------------------------------- | ----------------------------------------------------------------------------------------------- | | regex នៅក្នុង `map` | ការចាប់យកការវាយតម្លៃអថេរអាចមានវដ្តជីវិតឯករាជ្យ និងឥរិយាបថក្នុងឃ្លាំងសម្ងាត់ | | ការចាប់យកអនាមិកដូចជា `$1`, `$2` ជាដើម។ | ងាយស្រួលសរសេរជាន់ពីលើដោយកន្សោម ឬកន្សោមធម្មតាផ្សេងទៀត ដែលធ្វើឱ្យវាពិបាកក្នុងការតាមដានភាពជាម្ចាស់ | | អថេរនៅក្នុង `root` | ការប្រតិបត្តិស្គ្រីប និងការកក់ទុកបណ្ដោះអាសន្ន នៅពេលបង្កើតផ្លូវ | | `log_format`/ផ្លូវកំណត់ហេតុថាមវន្ត | ប្រភេទនៃការវាយតម្លៃដូចគ្នាអាចត្រូវបានបង្កឡើងនៅពេលក្រោយនៅក្នុងសំណើ | | កន្សោមស្គ្រីបនៅក្នុង `stream` | ការជួសជុលខាងលើក៏កែប្រែ `ngx_stream_script_run()` ផងដែរ។ អ្នកមិនអាចពិនិត្យមើលម៉ូឌុល HTTP បានទេ។ | ទំនាក់ទំនងតំរែតំរង់ដ៏សំខាន់៖ កូដដែលទាក់ទងនឹងភាពងាយរងគ្រោះនេះគឺទាក់ទងទៅនឹងការផ្លាស់ប្តូរពីមុនដែលបានជួសជុល CVE-2026-42533 ។ DSA ផ្លូវការសម្រាប់ Debian 13 បញ្ជាក់យ៉ាងច្បាស់ថាលេខកូដដែលរងផលប៉ះពាល់ត្រូវបានបញ្ចូលទៅក្នុងកញ្ចប់ trixie តាមរយៈ backport សុវត្ថិភាពមុន។ ដូច្នេះ "បំណះភាពងាយរងគ្រោះខែកក្កដា `map` ត្រូវបានដំឡើង" មិនមានន័យថា CVE-2026-93479 របស់ខែតុលាត្រូវបានគ្របដណ្តប់នោះទេ។ ខ្សែសង្វាក់ជួសជុលសុវត្ថិភាពពេញលេញគួរតែត្រូវបានពិនិត្យ។ [S6](https://keendigit.com/km/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/km/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/km/insights/nginx-remediation-guide#source-17) ហានិភ័យ RCE ដែលអាចកើតមាននៅទីនេះគឺទាក់ទងទៅនឹងបរិស្ថានការពារអង្គចងចាំ ហើយវាមិនគួរត្រូវបានអះអាងថា `map` regex តែម្នាក់ឯងនឹងអាចត្រូវបានគេកេងប្រវ័ញ្ចដោយអ្នកវាយប្រហារអនាមិកនោះទេ។ [S11](https://keendigit.com/km/insights/nginx-remediation-guide#source-11) ### 2.4 CVE-2026-97205៖ AIO ការរាប់ចំនួនប្រតិបត្តិការដែលមិនទាន់បានបញ្ចប់ មូលហេតុនៃការប្រើប្រាស់បន្ទាប់ពីឥតគិតថ្លៃ ភាពងាយរងគ្រោះនេះមិនមែនគ្រាន់តែ "បើក SSI ហើយអ្នកនឹងទទួលបាន UAF" នោះទេ។ គន្លឹះស្ថិតនៅក្នុងចំនួនសេចក្តីយោងប្រតិបត្តិការអសមកាលដែលធ្វើឡើងដោយសំណើចម្បង។ NGINX ប្រើ `r->main->blocked` ដើម្បីតាមដានដំណើរការអសមកាលដែលមិនទាន់បានបញ្ចប់ នៅក្នុងការអនុវត្តចាស់ វាត្រូវបានរាប់ចំនួន 8 ប៊ីត។ ផ្លូវមួយចំនួនមិនបានត្រួតពិនិត្យដែនកំណត់ខាងលើ មុនពេលបង្កើនចំនួន។ នៅពេលដែលសំណើមេដូចគ្នាប្រមូលផ្តុំប្រតិបត្តិការដែលមិនទាន់សម្រេចចំនួន 256 ការរាប់អាចរុំជុំវិញពី 255 ដល់ 0។ ដំណើរការជាបន្តបន្ទាប់នឹងយល់ច្រឡំថាមិនមានប្រតិបត្តិការអសមកាលដែលរារាំងសំណើមិនឱ្យចេញទេ ដោយហេតុនេះបញ្ចេញអង្គចងចាំសំណើដែលនៅតែយោងដោយកិច្ចការ។ [S7](https://keendigit.com/km/insights/nginx-remediation-guide#source-7) ដំណើរការបរាជ័យអាចត្រូវបានបែងចែកជាៈ 1. ជាមួយនឹងផ្លូវ I/O/thread អសមកាលដែលពាក់ព័ន្ធត្រូវបានបើក ទំព័រ SSI ណែនាំសំណើរងជាច្រើន ឬអានប្រតិបត្តិការតាមរយៈ `include virtual` ។ 2. ប្រតិបត្តិការលេចធ្លោនៃសំណើសំខាន់ជាក់លាក់មួយត្រូវបានប្រមូលរហូតដល់ដែនកំណត់ខាងលើដែលតំណាងដោយវាលរាប់។ 3. ការរាប់ចំនួន 8 ប៊ីតត្រូវបានរុំព័ទ្ធ ដោយបង្ហាញមិនត្រឹមត្រូវថា "គ្មានប្រតិបត្តិការដែលមិនទាន់សម្រេច"។ 4. បណ្តុំអង្គចងចាំសំណើត្រូវបានចេញផ្សាយ ខណៈពេលដែលឯកសារអាន ឃ្លាំងសម្ងាត់រង់ចាំ ឬការហៅត្រឡប់នៃកិច្ចការខ្សែស្រឡាយនៅតែរក្សាឯកសារយោងទៅវា។ 5. ការហៅត្រលប់ក្រោយការបញ្ចប់អសមកាលជាបន្តបន្ទាប់ចូលប្រើអង្គចងចាំដែលបានចេញផ្សាយ ដែលបណ្តាលឱ្យ UAF, Worker គាំង ឬការខូចខាតអង្គចងចាំដែលអាចកើតមាន។ ការជួសជុលជាផ្លូវការបន្ថែម `NGX_HTTP_MAX_BLOCKED 250` ទៅឯកសារបឋមកថាសំណើ ហើយបន្ថែមការរឹតបន្តឹងទៅតម្រងលទ្ធផល ការអានឃ្លាំងសម្ងាត់ និងផ្លូវខ្សែស្ទ្រីម។ នៅពេលឈានដល់កម្រិត ប្រតិបត្តិការជាមួយផ្លូវធ្វើសមកាលកម្មត្រូវបានបញ្ចប់ដោយសមកាលកម្ម ហើយប្រសិនបើពួកគេមិនអាចដំណើរការដោយសុវត្ថិភាពទេ ការបន្ថែមកិច្ចការដែលមិនទាន់សម្រេចនឹងត្រូវបានបដិសេធ។ [S7](https://keendigit.com/km/insights/nginx-remediation-guide#source-7) ការវិនិច្ឆ័យនៃការអនុវត្ត៖ វាត្រូវតែត្រូវបានវាយតម្លៃថាតើ SSI, AIO ការរួមបញ្ចូលនិម្មិត សំណើរង និងប្រតិបត្តិការអសមកាលដែលពាក់ព័ន្ធអាចកើតឡើងនៅក្នុងការរួមបញ្ចូលគ្នានៅក្នុងខ្សែសង្វាក់សំណើដូចគ្នា។ ជាធម្មតាទាំងនេះមិនមែនជាការកំណត់រចនាសម្ព័ន្ធប្រូកស៊ីឋិតិវន្តធម្មតាទេ។ `aio off;` ឬ `ssi off;` អាចលុបធាតុគន្លឹះជាក់លាក់ ប៉ុន្តែភាពអាស្រ័យមុខងារអាជីវកម្មគួរតែត្រូវបានបញ្ជាក់ជាមុនសិន។ [S4](https://keendigit.com/km/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/km/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/km/insights/nginx-remediation-guide#source-25) ### 2.5 CVE-2026-95101៖ HTTP/3 ស៊ុមមិនស្គាល់ត្រូវបានច្រលំជាមួយនឹងស្ថានភាពនៃតួសំណើ DATA ឧបករណ៍ញែកស៊ុម HTTP/3 ត្រូវតែបែងចែករវាងស៊ុម `DATA` (ដែលត្រូវបញ្ជូនទៅដំណើរការផ្នែកសំណើ HTTP) និងស៊ុមមិនស្គាល់ដែលគួររំលង។ ប្រវែងនៃស៊ុមដែលមិនស្គាល់ក៏ត្រូវតែរក្សាបានយ៉ាងត្រឹមត្រូវផងដែរ នៅពេលបែងចែកតាមបណ្តុំបណ្តាញ។ ការអនុវត្តចាស់របស់ `ngx_http_v3_parse_data()` បានប្រើវាល `st->length` ដើម្បីរក្សាទុក "ចំនួនបៃដែលនៅសល់ដែលត្រូវរំលង" នៅពេលរំលងស៊ុមមិនស្គាល់ ខណៈពេលដែលតម្រងតួសំណើបានបកប្រែវាលដូចគ្នានឹង "ប្រវែងបន្ទុក DATA ដែលនៅសល់" ។ ប្រសិនបើស៊ុមមិនស្គាល់កើតឡើងដើម្បីពង្រីកការហៅញែកច្រើន បាច់បន្ទាប់នៃបៃបន្ទាប់ពីការញែកត្រូវបានរំខានអាចនឹងត្រូវច្រឡំថាជាផ្នែកនៃផ្នែកសំណើ។ [S8](https://keendigit.com/km/insights/nginx-remediation-guide#source-8) ហានិភ័យពីរប្រភេទកើតឡើង៖ - ស្នើសុំការចាក់បញ្ចូលរាងកាយ៖ បន្ទុកស៊ុមដែលមិនមែនជា DATA ដែលដាក់ជូនដោយអតិថិជនអាចត្រូវបានបញ្ជូនទៅកម្មវិធីខាងលើ ដោយផ្លាស់ប្តូរទិន្នន័យដែលទទួលបានដោយកម្មវិធីខាងក្រោយ។ - ការរំលងដែនកំណត់ទំហំ៖ `client_max_body_size` និងការរឹតបន្តឹងផ្សេងទៀត។ ការត្រួតពិនិត្យដែលរំពឹងទុកត្រូវបានប្រមូលផ្តុំនៅលើផ្លូវ DATA ហើយមាតិកាដែលបានបំប្លែងមិនត្រឹមត្រូវអាចរំលងការផ្ទៀងផ្ទាត់ដែលត្រូវគ្នា។ សេណារីយ៉ូកេះធម្មតាដែលត្រូវបានពិពណ៌នាដោយមន្ត្រីគឺនៅពេលដែល `ngx_http_v3_module` ទទួលសំណើ HTTP/3 ហើយបញ្ជូនបន្ត `proxy_request_buffering on` ។ ការផ្អាកការស្នើសុំប្រូកស៊ីត្រូវបានបើកតាមលំនាំដើមនៅក្នុង `ngx_http_proxy_module` ។ ដូច្នេះ ប្រូកស៊ីបញ្ច្រាសដែលបើក HTTP/3 គួរតែត្រូវបានពិនិត្យជាមុនសិន។ វាមិនសមស្របទេក្នុងការសន្មត់ថាមិនមានលក្ខខណ្ឌកេះដោយគ្រាន់តែ `proxy_request_buffering on;` មិនត្រូវបានសរសេរយ៉ាងច្បាស់លាស់។ [S8](https://keendigit.com/km/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/km/insights/nginx-remediation-guide#source-18) ផលវិបាកដោយផ្ទាល់នៃភាពងាយរងគ្រោះនេះជាកម្មសិទ្ធិរបស់សំណើ backend សុចរិតភាព និងការផ្លាស់ប្តូរព្រំដែនសុវត្ថិភាព ដែលមិនមែនជាការបញ្ចេញមតិសមមូលនៃ RCE ដែលបានបញ្ចប់ដោយផ្ទាល់នៅក្នុងស្នូល NGINX ។ ផលប៉ះពាល់អាជីវកម្មចុងក្រោយគឺអាស្រ័យទៅលើរបៀបដែលបៃទាំងនេះត្រូវបានញែក និងជឿជាក់លើចរន្ត។ [S24](https://keendigit.com/km/insights/nginx-remediation-guide#source-24) ### 2.6 CVE-2026-97629: TLS ការបង្វិលសំបុត្រខកខានរន្ធដោតគ្រាប់ចុចទីបី នៅក្នុងការកំណត់រចនាសម្ព័ន្ធដែលរងផលប៉ះពាល់ NGINX អាចបង្កើត និងបង្វិលគ្រាប់ចុចសំបុត្រវគ្គ TLS ដោយស្វ័យប្រវត្តិ តាមរយៈឃ្លាំងផ្ទុកអង្គចងចាំដែលបានចែករំលែក ដែលអនុញ្ញាតឱ្យ Worker ជាច្រើនដំណើរការសំបុត្រតែមួយ។ តក្កវិជ្ជាធ្វើសមកាលកម្មដែលពាក់ព័ន្ធបែងចែករន្ធដោតសំខាន់ៗចំនួន 3 សម្រាប់ Worker នីមួយៗ ហើយការហៅត្រឡប់ពីការឌិគ្រីបនឹងឆ្លងកាត់រន្ធទាំងនេះផងដែរ។ ប៉ុន្តែការអនុវត្តចាស់ចម្លងតែ 2 key slots ពីអង្គចងចាំដែលបានចែករំលែករាល់ពេល ដែលបណ្តាលឱ្យមានឈ្មោះ key, HMAC key និង AES នៃរន្ធដោតទីបី។ សោអាចនៅតែមិនទាន់បានកំណត់។ ប្រសិនបើការកំណត់អត្តសញ្ញាណគន្លឹះនៃសំបុត្រត្រូវបានផ្គូផ្គងដោយស្ថានភាពនេះ សម្ភារៈសោដែលមិនទាន់ចាប់ផ្តើមអាចនឹងត្រូវបានប្រើប្រាស់សម្រាប់ការផ្ទៀងផ្ទាត់ហត្ថលេខា និងការឌិគ្រីប ដូច្នេះបង្កើតជាផ្លូវសម្រាប់បង្កើតវគ្គ TLS ។ [S9](https://keendigit.com/km/insights/nginx-remediation-guide#source-9) ការរួមបញ្ចូលគ្នានៃការដាក់ពង្រាយដែលមានហានិភ័យខ្ពស់គឺជាធម្មតា៖ ```nginx # 仅为排查触发条件所示：共享缓存本身不是恶意配置 ssl_session_cache shared:SSL:10m; # 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制 ``` ផលវិបាកអាជីវកម្មដ៏ធ្ងន់ធ្ងរបំផុតនៃភាពងាយរងគ្រោះនេះគឺថានៅលើសេវាកម្មដែលប្រើការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រអតិថិជន (mTLS) នៅក្នុង `ssl_verify_client on;` និងវិធីផ្សេងទៀត វគ្គស្ដារឡើងវិញដែលបានក្លែងបន្លំអាចរំលងការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រអតិថិជន។ ជោគជ័យនៃការវាយប្រហារក៏ជាកម្មវត្ថុនៃលក្ខខណ្ឌដែលមិនអាចគ្រប់គ្រងបាន; គេហទំព័រដែលប្រើតែវិញ្ញាបនបត្រ HTTPS ខាងម៉ាស៊ីនមេធម្មតា ហើយគ្មានការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រអតិថិជនមិនគួរត្រូវបានកំណត់លក្ខណៈខុសទេ ព្រោះថា "អ្នកវាយប្រហារអាចរំលងការចូលគេហទំព័រទាំងមូល។" [S9](https://keendigit.com/km/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/km/insights/nginx-remediation-guide#source-12) នេះគឺជាបញ្ហាស្ថានភាពផ្ទៀងផ្ទាត់សម័យ TLS ហើយមិនមានអ្វីដែលត្រូវធ្វើជាមួយថាតើសោឯកជន TLS របស់ម៉ាស៊ីនមេត្រូវបានបំបែក ឬថាតើវិញ្ញាបនបត្រ CA root សាធារណៈត្រូវបានប៉ះពាល់ដែរឬទេ។ [S24](https://keendigit.com/km/insights/nginx-remediation-guide#source-24) ### 2.7 របៀបយល់ DoS, RCE ការឆ្លងកាត់ការផ្ទៀងផ្ទាត់ និងការកេងប្រវ័ញ្ចដែលគេស្គាល់ - DoS៖ កំហុសអង្គចងចាំបណ្តាលឱ្យ Worker គាំង ឬចាប់ផ្ដើមឡើងវិញយ៉ាងខ្លាំង។ ថាតើវាបណ្តាលឱ្យមានភាពមិនអាចប្រើបានជារួមទាក់ទងនឹងសម្ពាធចរាចរណ៍ សមត្ថភាពចាប់ផ្តើមដំណើរការឡើងវិញ ពេលវេលាថែទាំការតភ្ជាប់ និងស្ថាបត្យកម្មដែលអាចរកបានខ្ពស់។ - សក្តានុពល RCE៖ សេចក្តីប្រកាសមួយចំនួនបង្ហាញថាមានលទ្ធភាពនៃការប្រតិបត្តិកូដនៅពេលដែល ASLR ត្រូវបានបិទ ឬរំលង។ នេះមិនមានន័យថាខ្សែសង្វាក់វាយប្រហារសាធារណៈដែលអាចប្រតិបត្តិពាក្យបញ្ជាប្រកបដោយស្ថេរភាព និងជាសកលត្រូវបានបង្ហាញនោះទេ។ [S4](https://keendigit.com/km/insights/nginx-remediation-guide#source-4) - ស្នើសុំការឆ្លងកាត់ការបញ្ចូល/ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ៖ វាអាចផ្លាស់ប្តូរដោយផ្ទាល់នូវស្ថានភាពអាជីវកម្មដែលត្រូវបានការពារ ឬស្នើសុំខ្លឹមសារ ហើយមិនអាចមិនអើពើបានទេ ដោយសារវាមិនទទួលបានសែលដោយផ្ទាល់។ - បានរកឃើញការប៉ុនប៉ងវាយប្រហារ៖ CVE-2026-42945 នៅខែឧសភា ឆ្នាំ 2026 មានរបាយការណ៍អំពីសកម្មភាពកេងប្រវ័ញ្ចក្នុងព្រៃ។ មិនគួរសន្និដ្ឋានដោយផ្ទាល់នូវការពិតជាប្រវត្តិសាស្រ្តនេះដើម្បីមានន័យថា CVEs ទាំងប្រាំនៅក្នុងខែតុលាត្រូវបានទាញយកដោយជោគជ័យក្នុងទ្រង់ទ្រាយធំនោះទេ។ [S23](https://keendigit.com/km/insights/nginx-remediation-guide#source-23) ## 3. ជួសជុលកំណែ និងការជ្រើសរើសបំណះ ### 3.1 NGINX Open Source មូលដ្ឋានបំណះផ្លូវការ | សាខាខាងលើ | កំណែផ្លូវការដំបូងគ្របដណ្តប់ភាពងាយរងគ្រោះចំនួនប្រាំនៅក្នុងខែតុលា | ការណែនាំជា 2026-10-27 | | --------------------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Stable 1.30.x | 1.30.6（2026-10-14） | ដំឡើងយ៉ាងហោចណាស់ 1.30.6 ហើយតាមដានជាមួយកំណែសុវត្ថិភាពជាបន្តបន្ទាប់។ | | Mainline 1.31.x | 1.31.7（2026-10-14） | 1.31.8（2026-10-21） | | សាខា NGINX Open Source មុន។ | វាមិនអាចត្រូវបានវិនិច្ឆ័យដោយផ្អែកលើ "បំណះភាពងាយរងគ្រោះចាស់ត្រូវបានអនុវត្ត" | ផ្លាស់ទីទៅសាខាថែទាំជាមុនសិន; បើមិនដូច្នេះទេ អ្នកលក់ត្រូវបានតម្រូវឱ្យផ្តល់ភស្តុតាងផ្លូវការនៃការគាំទ្រនៅលើមូលដ្ឋាន CVE-by-CVE ។ | ទាំងនេះគឺជាកំណែចុងក្រោយនៃកូដប្រភព/សាខាផ្លូវការរបស់ nginx.org ហើយមិនគួរប្រើដើម្បីបដិសេធដោយផ្ទាល់នូវកញ្ចប់សុវត្ថិភាពជាមួយនឹងការជួសជុលដែលបានផ្ញើដោយអ្នកចែកចាយនោះទេ។ ទោះបីជាតម្លៃនៃ `1.31.6` ធំជាង `1.30.6` ក៏ដោយ ក៏វានៅតែទាបជាងបន្ទាត់បំណះនៃបណ្តាញមេ។ [S1](https://keendigit.com/km/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/km/insights/nginx-remediation-guide#source-2) ### 3.2 វិសាលភាពផលប៉ះពាល់ខាងលើនៃ CVEs ប្រាំ ជួរខាងក្រោមត្រូវបានរាយបញ្ជីដោយយោងតាមអត្ថបទដើមនៃព្រឹត្តិបត្រសុវត្ថិភាព nginx.org ហើយចាំបាច់ត្រូវយល់ដោយភ្ជាប់ជាមួយ "សាខាដែលកំពុងដំណើរការបច្ចុប្បន្ន" និង "ផ្លូវកំណត់រចនាសម្ព័ន្ធជាក់ស្តែង"៖ | CVE | កំណែដែលរងផលប៉ះពាល់នៃស្លាកខាងលើ | កំណែថេរដែលមានស្លាកជាផ្លូវការ | | -------------- | ------------------------------- | ------------------------------------------ | | CVE-2026-15176 | `0.1.29–1.31.6` | `1.30.6+` ឬ `1.31.7+` នៅក្នុងសាខារៀងៗខ្លួន | | CVE-2026-93479 | `1.30.0–1.30.5`，`1.31.2–1.31.6` | ដូច​គ្នា​ខាង​លើ | | CVE-2026-97205 | `0.8.11–1.31.6` | ដូច​គ្នា​ខាង​លើ | | CVE-2026-95101 | `1.25.0–1.31.6` | ដូច​គ្នា​ខាង​លើ | | CVE-2026-97629 | `1.23.2–1.31.6` | ដូច​គ្នា​ខាង​លើ | CVE-2026-93479 មានដែនកំណត់កំណែណែនាំជាក់លាក់។ មិនមែនគ្រប់កំណែ NGINX ចាស់ទាំងអស់ត្រូវបានរងផលប៉ះពាល់ដោយការតំរែតំរង់នេះទេ។ កំណែចាស់ដែលនៅក្រៅជួរទាំងនោះអាចនៅតែរងផលប៉ះពាល់ដោយភាពងាយរងគ្រោះ `map` regex មុន CVE-2026-42533 ។ [S1](https://keendigit.com/km/insights/nginx-remediation-guide#source-1) ### 3.3 Ubuntu៖ ការចែកចាយ backports (USN-8955-1) Canonical USN-8955-1 ថ្ងៃទី 26 ខែតុលា ឆ្នាំ 2026 ផ្តល់នូវការអាប់ដេតសុវត្ថិភាពសម្រាប់ការបង្កើត Ubuntu ចំនួនបួន៖ [S13](https://keendigit.com/km/insights/nginx-remediation-guide#source-13) | កំណែ Ubuntu | `nginx` និងកំណែជួសជុលកញ្ចប់ប្រភពដូចគ្នា។ | ការពិពណ៌នា | | ----------- | ---------------------------------------- | ---------------------------------------------------------- | | 22.04 LTS | `1.18.0-6ubuntu14.22` | វា​គឺ​ជា backport អ្នក​លក់​; លេខកំណែខាងលើនៅតែបង្ហាញ 1.18.0 | | 24.04 LTS | `1.24.0-2ubuntu7.19` | ដូច​គ្នា​ខាង​លើ | | 26.04 LTS | `1.28.3-2ubuntu1.12` | ដូច​គ្នា​ខាង​លើ | | 26.10 | `1.30.4-7ubuntu1.1` | ដូច​គ្នា​ខាង​លើ | ការប្រកាសនេះមានកំណែថេរដែលត្រូវគ្នានៃកញ្ចប់ដូចគ្នាដូចជា `nginx-core`, `nginx-extras`, `nginx-full` និង `nginx-light` ។ កុំធ្វើការសន្និដ្ឋានអំពីថាតើត្រូវជួសជុលវាពីផ្នែកខាងលើដែលបង្ហាញដោយ `nginx -v` ទេ។ ដូចជា Ubuntu 24.04 និង `1.24.0-2ubuntu7.19` ត្រូវបានជួសជុលដោយអ្នកលក់នេះ ប៉ុន្តែ `1.24.0` ពីប្រភពណាមួយមិនមានសុវត្ថិភាពទេ។ Ubuntu ជាផ្លូវការក៏បានគូសបញ្ជាក់យ៉ាងច្បាស់លាស់ផងដែរ។ CVE-2026-95101 ប៉ះពាល់តែប៉ុណ្ណោះ Ubuntu 26.04 / 26.10 , និង CVE-2026-97629 ប៉ះពាល់តែប៉ុណ្ណោះ Ubuntu 24.04 / 26.04 / 26.10. នៅទីនេះ Ubuntu ការវេចខ្ចប់ផ្ទាល់ខ្លួន និងវិសាលភាពមុខងារ ដែលមិនអាចផ្សព្វផ្សាយដោយផ្ទាល់ទៅការចែកចាយផ្សេងទៀត។ [S13](https://keendigit.com/km/insights/nginx-remediation-guide#source-13) ### 3.4 Debian៖ ភាពខុសគ្នារវាងកំណែត្រូវតែពិនិត្យដោយឡែកពីគ្នា។ ការណែនាំ Debian DSA-6575-1 (2026-10-21) គ្របដណ្តប់ CVEs ទាំងប្រាំនេះហើយកំណត់អត្តសញ្ញាណកញ្ចប់ `nginx` ថេរសម្រាប់ Debian 13 / trixie ដូចជា៖ ```text 1.26.3-3+deb13u10 ``` ទោះយ៉ាងណាក៏ដោយ គិតត្រឹមពេលនៃការផ្ទៀងផ្ទាត់របាយការណ៍នេះ `1.22.1-9+deb12u10` សម្រាប់ Debian 12 / bookworm នៅតែត្រូវបានសម្គាល់ថាងាយរងគ្រោះដោយកម្មវិធីតាមដានសុវត្ថិភាព Debian ។ ដូច្នេះ៖ - Debian 13 គ្រាន់តែអាប់ដេត និងទទួលយកយោងទៅតាម DSA-6575-1។ - Debian 12 ត្រូវតែពិនិត្យមើលការជួសជុលសុវត្ថិភាពដែលផ្តល់ដោយកម្មវិធីតាមដានសុវត្ថិភាពបច្ចុប្បន្ន ឬអ្នកលក់ ELTS ម្តងមួយៗ។ មុនពេលការជួសជុលត្រូវបានបញ្ជាក់នៅក្នុងសេចក្តីប្រកាស សូមកុំប្រកាសថាធាតុទាំងប្រាំត្រូវបានជួសជុលដោយផ្អែកលើភាពជោគជ័យរបស់ `apt upgrade` ។ - កញ្ចប់ប្រភព Debian អាចផ្ទុកសំណុំបំណះដោយឯករាជ្យនៃលេខកំណែ nginx.org ។ សម្រាប់ការបង្កើតផ្ទាល់ខ្លួន អ្នកត្រូវពិនិត្យមើលសំណុំកម្មវិធីជួសជុលកូដប្រភពពេញលេញ ហើយអ្នកមិនអាចគ្រាន់តែចម្លងការប្តេជ្ញាចិត្តខាងលើតែមួយ ហើយចាត់ទុកថាវាពេញលេញនោះទេ។ ភាពខុសគ្នាខាងលើគឺផ្អែកលើកំណត់ត្រាតាមដាន DSA និង CVE ។ [S14](https://keendigit.com/km/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/km/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/km/insights/nginx-remediation-guide#source-16) ### 3.5 NGINX Plus, njs និង Ingress Controller | ផលិតផល/សមាសធាតុ | ការជ្រើសរើសសុវត្ថិភាព និងការផ្ទៀងផ្ទាត់ចំណុចសំខាន់ | | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NGINX Plus (កំណែពាណិជ្ជកម្ម) | សូមមើលសេចក្តីប្រកាស និងសេចក្តីណែនាំអំពីការធ្វើឱ្យប្រសើរឡើងនៃសាខាបូកដែលត្រូវនឹង F5 ។ CR ចុងក្រោយបំផុតនៅពេលផ្ទៀងផ្ទាត់គឺ `PLS.37.2.0.1` ហើយការស្ថាបនាសុវត្ថិភាព LTS គឺ `PLS.37.0.7.1`; កំណែបូក និង backport រួមបញ្ចូលមិនអាចជំនួសដោយផ្ទាល់ដោយកម្រិត 1.30/1.31 របស់ប្រភពបើកចំហទេ។ [S19](https://keendigit.com/km/insights/nginx-remediation-guide#source-19) | | njs / ngx\_http\_js\_module | 2026-10-14 ចេញផ្សាយ `njs 1.0.2` និងជួសជុល CVE-2026-101019 និង CVE-2026-101025; ប្រសិនបើអ្នកកំពុងប្រើ njs អ្នកក៏ត្រូវពិនិត្យមើលភាពឆបគ្នានៃម៉ូឌុលជាមួយ NGINX ផងដែរ។ [S20](https://keendigit.com/km/insights/nginx-remediation-guide#source-20) | | F5 NGINX Ingress Controller / Gateway Fabric | ស្នូល NGINX គឺជាខ្សែសង្វាក់ចែកចាយកម្មវិធីដែលពាក់ព័ន្ធ ប៉ុន្តែឯករាជ្យ។ ជួសជុលភាពងាយរងគ្រោះដែលពាក់ព័ន្ធជាមួយនឹងឧបករណ៍បញ្ជារៀងៗខ្លួន រូបភាព និងកំណត់ចំណាំចេញផ្សាយ។ អ្នកមិនអាចគ្រាន់តែជំនួសប្រព័ន្ធគោលពីរ NGINX នៅក្នុង Pod បានទេ។ | | សហគមន៍ Kubernetes `kubernetes/ingress-nginx` | គម្រោងនេះត្រូវបានបញ្ឈប់នៅខែមីនា ឆ្នាំ 2026 ហើយនឹងលែងផ្តល់ការថែទាំសុវត្ថិភាពថ្មីទៀតហើយ។ អ្នកគួរមានគម្រោងផ្លាស់ប្តូរទៅឧបករណ៍បញ្ជាដែលបានថែទាំ ឬ Gateway API ជាជាងការច្រឡំលេខចេញផ្សាយរបស់វាសម្រាប់ F5 NGINX Ingress Controller ។ [S21](https://keendigit.com/km/insights/nginx-remediation-guide#source-21) | ### 3.6 តើ Patch មួយណាដែលអ្នកពិតជាគួរជ្រើសរើស? | ទម្រង់ដាក់ពង្រាយ | ការអនុវត្តដែលបានណែនាំ | ភស្តុតាងនៃការជួសជុល | | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | កញ្ចប់ DEB/RPM ផ្លូវការ nginx.org | ដំឡើងកំណែទៅកំណែថេរនៃសាខាខាងលើ | `nginx -v/-V` ប្រភពកញ្ចប់ ការប្រកាសសុវត្ថិភាពជាផ្លូវការ | | ឃ្លាំងផ្លូវការ Ubuntu/Debian | ដំឡើងកញ្ចប់សុវត្ថិភាពរបស់អ្នកលក់ | កំណែកញ្ចប់ពេញលេញ + ស្ថានភាពអ្នកលក់ USN/DSA + CVE | | RHEL/Alma/Rocky/SUSE/ការចែកចាយផ្សេងទៀត។ | ដំឡើងកំណែដោយយោងទៅតាមព្រឹត្តិបត្រសុវត្ថិភាពចែកចាយជាក់លាក់ និងកំណែកញ្ចប់ | អ្នកលក់ដែលត្រូវគ្នា CSAF/សេចក្តីប្រកាស កំណែ Ubuntu/Debian មិនអាចអនុវត្តបានទេ | | រូបភាពធុងផ្លូវការ ឬផ្ទាល់ខ្លួន | បង្កើតឡើងវិញ ឬទាញរូបភាពជួសជុលដែលបានផ្ទៀងផ្ទាត់ ហើយជំនួសវានៅលើមូលដ្ឋានរំកិល | រូបភាពសង្ខេប, បង្កើត SBOM, ដំណើរការលេខសម្គាល់រូបភាព pod/container | | NGINX, OpenResty, Tengine ដែលចងក្រងដោយខ្លួនឯង ឬកំណែដែលបានភ្ជាប់ជាមួយម៉ូឌុលភាគីទីបី | ផ្តល់អាទិភាពដល់ការប្រើប្រាស់កំណែសុវត្ថិភាពពេញលេញរបស់អ្នកថែទាំ។ អនុវត្តការពិនិត្យមើល backports បំណះសម្រាប់មែកធាងប្រភពគោលដៅនៅពេលចាំបាច់ | ការជួសជុលភាពងាយរងគ្រោះចំនួន 5 ភាពឆបគ្នារបស់ ABI/module ឯកតា និងការតំរែតំរង់អាជីវកម្ម | OpenResty និង Tengine គឺជាប្រព័ន្ធចេញផ្សាយផ្សេងគ្នា។ តារាងនេះពិពណ៌នាតែវិធីសាស្ត្រផ្ទៀងផ្ទាត់ប៉ុណ្ណោះ។ មិនមានន័យថាកំណែទាំងអស់របស់វាត្រូវបានប៉ះពាល់ក្នុងពេលតែមួយជាមួយស្តង់ដារ NGINX នោះទេ ហើយក៏មិនអាចអនុវត្តបំណះកូដខាងលើដោយគ្មានលក្ខខណ្ឌដែរ។ ## 4. ដំណើរការជួសជុលជាផ្លូវការ ### 4.1 សារពើភ័ណ្ឌនៃករណីជាក់ស្តែងនៃការទទួលបានចរាចរខាងក្រៅ បង្រួមសម្រាប់ធាតុនីមួយៗយ៉ាងហោចណាស់៖ - ឈ្មោះដែន តុល្យភាពផ្ទុក/CDN/តំណប្រូកស៊ីគែម វិធីសាស្ត្របង្ហាញគេហទំព័រដើម និងពិធីការបណ្តាញដែលបានប្រើ។ - ផលិតផល NGINX (Open Source, Plus, Ingress ។ល។) កំណែពេញលេញ ប្រភពឃ្លាំងកញ្ចប់ ការសង្ខេបរូបភាព។ - `nginx -V` បង្ហាញម៉ូឌុលអគារ និងប៉ារ៉ាម៉ែត្រចងក្រង; ថាតើមាន njs, Lua, OpenResty និងម៉ូឌុលថាមវន្តភាគីទីបី។ - ដំណើរការពិត master/worker PID, Service Unit/Container/Pod, Replica និង Worker Node។ - ការកំណត់រចនាសម្ព័ន្ធ `http`/`stream`, `server`, `location`, `include` ដែលមានប្រសិទ្ធភាពពិតប្រាកដ។ - ថាតើត្រូវបើក HTTP/3, mTLS, SSI/AIO, ផ្លូវកំណត់ហេតុថាមវន្ត, ស្មុគស្មាញ `map` និងការចាប់យក regex ដែរឬទេ។ កុំគ្រាន់តែពិនិត្យមើលលំនាំដើម `/etc/nginx/nginx.conf` ។ បរិយាកាសផលិតកម្មជាញឹកញាប់ផ្ទុកគេហទំព័រជាច្រើន TLS និងការកំណត់រចនាសម្ព័ន្ធម៉ូឌុលតាមរយៈ `include` ។ វាក៏អាចមានផ្លូវដំឡើង NGINX ច្រើន ឬស្រទាប់ប្រូកស៊ីច្រើន។ ### 4.2 ពិនិត្យកំណែ និងព័ត៌មានចងក្រង ```bash # NGINX 版本及构建选项 nginx -v nginx -V 2>&1 # Linux：查看实际运行的 NGINX 进程 ps -eo pid,ppid,user,comm,args | grep '[n]ginx' # Debian / Ubuntu：查看完整已安装包版本、来源 apt-cache policy nginx # 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包 dpkg-query -W 'nginx*' 2>/dev/null # RPM 系：以实际安装包及仓库公告为准 rpm -qa | grep '^nginx' ``` `nginx -V` រាយការណ៍ពីការកសាងប្រព័ន្ធគោលពីរដែលបានរកឃើញនៅលើផ្លូវបន្ទាត់ពាក្យបញ្ជា; វាមិនបង្ហាញថា worker ដែលកំពុងដំណើរការបានផ្ទុកវាទេ។ `nginx -v` អាចលុបចោលបច្ច័យកញ្ចប់ពេញលេញនៃការចែកចាយ ដូច្នេះសូមពិនិត្យមើលកម្មវិធីគ្រប់គ្រងកញ្ចប់ ឬកំណត់ត្រាខ្សែសង្វាក់ផ្គត់ផ្គង់ផងដែរ។ ### 4.3 នាំចេញការកំណត់រចនាសម្ព័ន្ធប្រកបដោយប្រសិទ្ធភាព និងអនុវត្តជុំទីមួយនៃការត្រួតពិនិត្យឋិតិវន្ត `nginx -T` នឹង​សាកល្បង​ការ​កំណត់​រចនាសម្ព័ន្ធ ហើយ​បោះបង់​ការ​កំណត់​រចនាសម្ព័ន្ធ​ដែល​បាន​បញ្ចូល​គ្នា។ លទ្ធផលអាចមានព័ត៌មានរសើប ដូចជាព័ត៌មានបញ្ជាក់ការផ្ទៀងផ្ទាត់ ផ្លូវគន្លឹះ ឈ្មោះម៉ាស៊ីនខាងក្នុង។ល។ វាត្រូវបានណែនាំអោយរក្សាទុកស្ថានីយដែលបានគ្រប់គ្រងជាមួយ root ការអនុញ្ញាត និងការអនុញ្ញាតឯកសារឯកជន ហើយកុំបង្ហោះឯកសារដើមទៅក្នុងការបញ្ជាទិញការងារសាធារណៈ៖ ```bash sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log' sudo grep -nE \ 'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \ /root/nginx-effective.conf ``` នេះគ្រាន់តែជាឧបករណ៍កំណត់ផ្លូវរបស់បេក្ខជនប៉ុណ្ណោះ មិនមែនជាឧបករណ៍កំណត់ដោយស្វ័យប្រវត្តិ CVE ដែលអាចទុកចិត្តបាន៖ 1. `grep` មិនអាចកំណត់ថាតើអថេរស្ថិតនៅក្នុង `location` ដូចគ្នា ឬខ្សែសង្វាក់វាយតម្លៃសំណើដូចគ្នា ហើយក៏មិនអាចកាត់ផ្តាច់ទំនាក់ទំនងមរតកនៃការកំណត់រចនាសម្ព័ន្ធដែរ។ 2. `proxy_request_buffering on` ការកំណត់រចនាសម្ព័ន្ធឃ្លាំងសម្ងាត់ និងសំបុត្រមួយចំនួនមានតម្លៃលំនាំដើម ហើយការមិនសរសេរការណែនាំដែលត្រូវគ្នានោះមិនមានន័យថាហានិភ័យនឹងបាត់ទៅវិញទេ។ 3. ការកំណត់រចនាសម្ព័ន្ធដែលបង្កើតដោយប្រូកស៊ីបញ្ច្រាស CDN កុងតឺន័រ sidecars ឬឧបករណ៍បញ្ជាអាចខុសពីឯកសារដែលបានត្រួតពិនិត្យដោយដៃ។ 4. លក្ខណៈរបស់ `NGINX Plus` និងម៉ូឌុលថាមវន្តអាចនឹងត្រូវបញ្ជាក់ដោយប្រើឧបករណ៍គ្រប់គ្រងផ្លូវការរៀងៗខ្លួន។ ### 4.4 ដាក់ពង្រាយការជួសជុលតាមរយៈបណ្តាញដែលជឿទុកចិត្ត Debian/Ubuntu (ឃ្លាំងចែកចាយផ្លូវការ)៖ ```bash sudo apt-get update apt-cache policy nginx # 升级发行版仓库中已经安装的 NGINX 及相关包； # 先确认 Candidate 属于修复版本，再执行升级。 sudo apt-get install --only-upgrade nginx # 对实际安装的 nginx-core / nginx-full / nginx-extras 等包 # 确认它们的版本和依赖一同达到厂商修复要求。 dpkg-query -W 'nginx*' 2>/dev/null ``` សំណុំនៃពាក្យបញ្ជានេះមិនអាចបង្កើតការជួសជុលសុវត្ថិភាពចេញពីខ្យល់ស្តើងដែលមិនទាន់មាននៅឡើយទេ។ ជាពិសេសសម្រាប់ Debian 12 ប្រសិនបើកញ្ចប់ដែលបានដំឡើងកំណែនៅតែត្រូវបានចាត់ទុកថាងាយរងគ្រោះដោយប្រព័ន្ធតាមដានសុវត្ថិភាព ការជួសជុលបន្ថែម ការដាក់ឱ្យនៅដាច់ដោយឡែក ឬវិធានការធ្វើចំណាកស្រុកត្រូវបានទាមទារ។ [S13](https://keendigit.com/km/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/km/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/km/insights/nginx-remediation-guide#source-15) កញ្ចប់ផ្លូវការ nginx.org៖ ```bash # 先确认仓库来自 nginx.org、目标分支和候选版本 apt-cache policy nginx # 经变更审批后再执行对应仓库的升级命令 sudo apt-get install --only-upgrade nginx ``` ប្រសិនបើប្រើការចងក្រងដោយខ្លួនឯង OpenResty, Tengine ឬ NGINX Plus ប្រើកំណែជួសជុលដែលគាំទ្រដោយអ្នកថែទាំដែលត្រូវគ្នា ហើយកុំលាយ nginx.org ការចែកចាយ និងកញ្ចប់ផ្ទុកភាគីទីបី។ គោលពីរ/រូបភាពដើម ការកំណត់រចនាសម្ព័ន្ធ ហត្ថលេខា និងការបង្ហាញការដាក់ឱ្យដំណើរការឡើងវិញគួរតែត្រូវបានរក្សាទុក។ កុងតឺន័រ/Kubernetes៖ ធ្វើបច្ចុប្បន្នភាពរូបភាពដែលមិនអាចកែប្រែបាន កត់ត្រាការសង្ខេបរបស់វា និងជំនួសការចម្លងចាស់ទាំងអស់ជាមួយនឹងការដាក់ចេញជាដំណាក់កាល។ `kubectl rollout status` គ្រាន់តែបញ្ជាក់ថាឧបករណ៍បញ្ជាដាក់ពង្រាយបានបញ្ចប់។ ក៏ផ្ទៀងផ្ទាត់ការសង្ខេបរូបភាព ការកំណត់ផ្លូវចូល និងការចម្លងដែលមិនល្អផងដែរ។ ### 4.5 ផ្ទៀងផ្ទាត់ការកំណត់រចនាសម្ព័ន្ធ និងជំនួស Worker ចាស់ ```bash sudo nginx -t # 按服务实际名称、主机高可用和变更窗口执行重启 sudo systemctl restart nginx sudo systemctl status nginx --no-pager # 核查真正存在的 master / worker ps -eo pid,ppid,user,comm,args | grep '[n]ginx' ``` កុំចាត់ទុក `nginx -s reload` ជាភ័ស្តុតាងថាប្រព័ន្ធគោលពីរថ្មីកំពុងដំណើរការ៖ ការកំណត់រចនាសម្ព័ន្ធធម្មតាផ្ទុកឡើងវិញអនុញ្ញាតឱ្យ master ចាស់ចាប់ផ្តើមកម្មករថ្មីដោយមិនចាំបាច់ជំនួសកន្លែងប្រតិបត្តិរបស់វា។ NGINX គាំទ្រនីតិវិធីធ្វើឱ្យប្រសើរឡើងប្រព័ន្ធគោលពីរតាមអ៊ីនធឺណិត ប៉ុន្តែវាទាមទារជំហានបន្ថែម និងការផ្ទៀងផ្ទាត់។ ប្រសិនបើគ្មាននីតិវិធីដែលបានបង្កើតឡើងទេ សូមប្រើកុងតាក់ចរាចរណ៍ដែលមានភាពអាចរកបានខ្ពស់ អមដោយការចាប់ផ្ដើមសេវាកម្មឡើងវិញ ឬបើកធុងជំនួស។ [S22](https://keendigit.com/km/insights/nginx-remediation-guide#source-22) ប្រសិនបើអ្នកគ្រប់គ្រង NGINX តាមរយៈរន្ធ `systemd` ស្គ្រីបបញ្ចូលកុងតឺន័រ ឬការដំឡើងច្រើន អ្នកគួរតែពិនិត្យមើលគោលដៅចាប់ផ្តើម និងផ្លូវដំណើរការពិតប្រាកដ ជំនួសឱ្យការសន្មតដោយផ្ទាល់ថា `systemctl restart nginx` គ្របដណ្តប់គ្រប់ករណីទាំងអស់។ ### 4.6 ទទួលយក និងធ្វើអាជីវកម្មតំរែតំរង់ពីច្រកចូលខាងក្រៅពិតប្រាកដ វាត្រូវបានណែនាំឱ្យអនុវត្តយ៉ាងហោចណាស់៖ - តើ HTTPS ធម្មតា ផ្លូវដែលសរសេរឡើងវិញ ធនធានឋិតិវន្ត និងទំព័រផែនទី `alias` ត្រឹមត្រូវ។ - តើការចែកចាយ `map` ធម្មតា, ផ្លូវ root អថេរ, ផ្លូវចូលដំណើរការ, SNI/ការបញ្ជាក់ផ្លូវ និងប្រូកស៊ី Stream ត្រឹមត្រូវ។ - តើការអាប់ឡូតធម្មតា ការអាប់ឡូតជាកំណាត់ សំណើ API និងកម្រិតសំឡេងឡើងលើសម្រាប់ HTTP/3 (នៅពេលបើកដំណើរការ) នៅតែដូចការរំពឹងទុក។ - mTLS៖ សំណើវិញ្ញាបនបត្រស្របច្បាប់គួរតែជោគជ័យ។ បាត់ ផុតកំណត់ ឬវិញ្ញាបនបត្រដែលមិនមានការអនុញ្ញាតគួរតែនៅតែត្រូវបានបដិសេធ ហើយការបន្ត/ភ្ជាប់ឡើងវិញ TLS មិនគួរផ្លាស់ប្តូរការអនុញ្ញាតដោយចៃដន្យទេ។ - ថាតើទំព័រ SSI និងការចូលប្រើឯកសារអសមកាលគឺធម្មតាទេ កំណត់​ហេតុ​កំហុស​បង្ហាញ​ថា​មិន​មាន​សំណើ​មិន​ប្រក្រតី​សម្រាប់​ការ​យោង​អង្គ​ចងចាំ​ឬ Worker គាំង​ម្តង​ហើយ​ម្តង​ទៀត​។ - បន្ទាប់ពីការផ្លាស់ប្តូរចរាចរណ៍ ដំណើរការកំណែចាស់ និងការចម្លងរូបភាពចាស់គួរតែចេញ។ ការធ្វើតេស្តត្រូវតែធ្វើឡើងក្នុងបរិយាកាសផ្ទាល់ខ្លួន ឬអនុញ្ញាត។ ការធ្វើតេស្តផ្សែងតាមសំណើធម្មតាមិនអាចបញ្ជាក់តែម្នាក់ឯងថាភាពងាយរងគ្រោះនៃការចងចាំត្រូវបានជួសជុលនោះទេ។ ទីបំផុត កំណែថេររបស់អ្នកផ្គត់ផ្គង់ បំណះកូដប្រភព និងការធ្វើតេស្តពេលដំណើរការត្រូវតែត្រូវបានទទួលយករួមគ្នាសម្រាប់ការទទួលយក។ ## 5. វិធានការកាត់បន្ថយនៅពេលដែលការធ្វើឱ្យប្រសើរឡើងជាបន្ទាន់គឺមិនអាចធ្វើទៅបាន ផ្នែកនេះគឺជាជម្រើសកាត់បន្ថយហានិភ័យ មិនមែនជាការជំនួសបំណះទេ។ ការផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធបណ្តោះអាសន្នទាំងអស់គួរតែត្រូវបានបម្រុងទុក ប្រតិបត្តិ `nginx -t` ចេញជាបាច់ ហើយត្រលប់មកវិញយ៉ាងឆាប់រហ័សប្រសិនបើចាំបាច់។ [S3](https://keendigit.com/km/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/km/insights/nginx-remediation-guide#source-4) ### 5.1 គ្រប់គ្រងអាទិភាពចរាចរណ៍ដោយផ្អែកលើការប៉ះពាល់ខាងក្រៅ ផ្តល់អាទិភាពដល់ការកាត់បន្ថយផ្ទៃវាយប្រហារនៃសេវាកម្មដែលមិនអាចត្រូវបានអាប់ដេតទាន់ពេល៖ នៅលើផ្ទៃគ្រប់គ្រង និងខាងក្នុង API បន្ថែមការគ្រប់គ្រងការចូលប្រើប្រភពដែលអាចទុកចិត្តបាន ការផ្តាច់បណ្តាញខាងលើ ឬក្រៅបណ្តាញរយៈពេលខ្លី។ បន្ថែមការតភ្ជាប់ ស្នើសុំកម្រិតរាងកាយ និងអត្រាទៅច្រកចូលដែលមានហានិភ័យខ្ពស់; ធានាថាការផ្ទៀងផ្ទាត់ប្រភពកើតឡើងនៅ NGINX ដែលទាក់ទងនឹងការបញ្ចូល មុនពេលខ្សែសង្វាក់ដំណើរការសំណើ។ វាគួរតែត្រូវបានកត់សម្គាល់ថាភាពងាយរងគ្រោះភាគច្រើនរបស់ពួកគេមានទីតាំងនៅ NGINX នៅខាងក្នុងយន្តហោះទិន្នន័យ ច្បាប់ WAF ប្រពៃណីប្រហែលជាមិនកំណត់បានត្រឹមត្រូវនូវលក្ខខណ្ឌនៃការកំណត់រចនាសម្ព័ន្ធផ្ទាល់ខ្លួន។ ### 5.2 `alias` / `rewrite`៖ ជៀសវាងការវាយតម្លៃ `$request_filename` បន្ទាប់ពីសរសេរឡើងវិញ វាត្រូវបានណែនាំឱ្យពិនិត្យ និងកែតម្រូវ៖ - ព្យាយាមមិនអនុវត្ត `rewrite` ដែលនឹងផ្លាស់ប្តូរ URI ក្នុងពេលតែមួយជាមួយ `location` ដោយប្រើ `alias` ។ - ជៀសវាងការប្រើ `$request_filename` នៅពេលដែល URI ត្រូវបានសរសេរឡើងវិញ ប៉ុន្តែការផ្គូផ្គងទីតាំងត្រឹមត្រូវមិនទាន់ត្រូវបានបញ្ចប់នៅឡើយ។ - ពិនិត្យរកមើលសេចក្តីយោងអថេរដោយប្រយោលនៅក្នុង `return`, `set`, `if`, `add_header` ទម្រង់ចូលដំណើរការ និងរួមបញ្ចូលឯកសារ។ - ប្រើ `root`/`try_files`/ឯករាជ្យ `location` នៅពេលអនុញ្ញាតអាជីវកម្ម ប៉ុន្តែគ្រាន់តែប្តូរ `alias` ទៅ `root` ប៉ុណ្ណោះ។ វាក៏អាចផ្លាស់ប្តូរ semantics ផ្លូវឯកសារ ដែលត្រូវតែផ្ទៀងផ្ទាត់ម្តងមួយៗ។ កុំចម្លងដោយផ្ទាល់នូវ "គំរូសរសេរឡើងវិញដោយសុវត្ថិភាព" ធម្មតានៅលើអ៊ីនធឺណិត ដើម្បីសរសេរជាន់លើការកំណត់ដែលមានស្រាប់។ បុព្វបទ `location` ផ្សេងគ្នា និងការសរសេរគោលដៅឡើងវិញ បណ្តាលឱ្យមានការបំបែកផ្លូវដែលមានអត្ថន័យខុសគ្នាទាំងស្រុង។ [S5](https://keendigit.com/km/insights/nginx-remediation-guide#source-5) ### 5.3 `map`/Regex៖ កាត់បន្ថយការចាប់យកការលាយស្ថានភាពអថេរ វាត្រូវបានផ្ដល់អនុសាសន៍ឱ្យកំណត់អាទិភាពការចាប់យកដែលមានឈ្មោះ និងកំណត់វិសាលភាពផ្សព្វផ្សាយរបស់ពួកគេ ជាជាងអនុញ្ញាតឱ្យការចាប់យកអនាមិកដូចជា `$1` ត្រូវបានប្រើឡើងវិញឆ្លងកាត់ផ្លូវវាយតម្លៃ regex ផ្សេងៗគ្នាតាមពេលវេលា។ ឧទាហរណ៍៖ ```nginx # 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整 map $host $tenant_root { default /srv/www/default; ~^(?[a-z0-9-]+)\.example\.net$ /srv/www/$tenant; } ``` អត្ថបទខ្លីៗនេះបង្ហាញតែរចនាសម្ព័ន្ធសវនកម្មដែលងាយស្រួលជាងនៃភាពជាម្ចាស់អថេរ។ មិនមានន័យថាវាត្រូវបានបញ្ជាក់ដោយឯករាជ្យដើម្បីលុបបំបាត់ CVE-2026-93479 ផ្លូវកេះទាំងអស់ទៅ។ ជាពិសេស ពិនិត្យមើលថាតើអថេរចាប់យកត្រូវបានយោងមុនពេលវេលាដោយ `root` ឬ `log_format` ផ្សេងទៀតដែរឬទេ ហើយថាតើមាន `volatile` ផ្លូវថាមវន្ត និងខ្សែសង្វាក់វាយតម្លៃអាស្រ័យគ្នាទៅវិញទៅមក។ F5/CERT ផ្តល់អនុសាសន៍ឱ្យប្រើការចាប់យកដែលមានឈ្មោះ និងការកំណត់វិសាលភាពនៃការប្រើប្រាស់ទៅនឹងការកំណត់រចនាសម្ព័ន្ធដែលត្រូវគ្នាជាទៀងទាត់ដែលជាការសង្គ្រោះរយៈពេលខ្លី។ [S3](https://keendigit.com/km/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/km/insights/nginx-remediation-guide#source-6) ### 5.4 AIO + SSI៖ បិទបន្សំមុខងារដែលមិនចាំបាច់ សម្រាប់ម៉ាស៊ីនមេ/ផ្លូវដែលមិនត្រូវការ SSI ឬឯកសារអសមកាល I/O សូមប្រើ៖ ```nginx # 在适当的 http/server/location 上下文中配置 ssi off; aio off; ``` តាមទស្សនៈនៃលក្ខខណ្ឌដែលបង្កឱ្យមានភាពងាយរងគ្រោះ ការបិទមួយក្នុងចំណោមពីរគឺជាធម្មតាគ្រប់គ្រាន់ដើម្បីដកចេញខ្សែសង្វាក់ជាក់លាក់ដែលបានពិពណ៌នា។ ការបិទក្នុងពេលតែមួយគឺអាចអនុវត្តបានតែចំពោះសេណារីយ៉ូដែលអាជីវកម្មមិនពឹងផ្អែកលើសមត្ថភាពនេះ។ ពិនិត្យ `include virtual`, សំណើរង, ឃ្លាំងសម្ងាត់, និងឥរិយាបថក្រុមខ្សែស្រឡាយ; នៅពេលដែលការផ្ទុកប្រូកស៊ីបញ្ច្រាសគឺខ្ពស់ ការបិទ AIO អាចផ្លាស់ប្តូរភាពយឺតយ៉ាវ និងដំណើរការ I/O ។ [S7](https://keendigit.com/km/insights/nginx-remediation-guide#source-7) ### 5.5 HTTP/3 ស្នើសុំការចាក់លើរាងកាយ៖ បិទច្រកចូលជាបណ្តោះអាសន្នប្រសិនបើចាំបាច់ បិទដំណើរការ `quic` អ្នកស្តាប់ដែលពាក់ព័ន្ធ HTTP/3 លុបចោល `Alt-Svc` ក្បាលឆ្លើយតបដែលប្រកាស HTTP/3 ហើយពិនិត្យមើលថាតើស្រទាប់គែម/ឧបករណ៍ផ្ទុកតុល្យភាពនៅតែផ្ញើ QUIC ស្នើសុំដោយផ្ទាល់ទៅអ្នកមិនទាន់ជួសជុល NGINX : ```nginx # 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen server { listen 443 ssl; # 保留 HTTPS/TCP 入口 # 对支持新版语法的构建，可在此使用 http2 on; # 删除原有的 listen 443 quic reuseport; # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项） # 其余证书、server_name、location 等配置保持不变 } ``` ខាងលើគ្រាន់តែជាការពិពណ៌នាអំពីភាពខុសគ្នានៃការផ្លាស់ប្តូរប៉ុណ្ណោះ មិនមែនជាការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេពេញលេញដែលអាចបើកដំណើរការជាលក្ខណៈបុគ្គលនោះទេ។ វាក្យសម្ព័ន្ធការកំណត់នៃ HTTP/2 គឺទាក់ទងទៅនឹងកំណែ NGINX ។ ប្រសិនបើអ្នកត្រូវការរក្សា HTTP/2 អ្នកគួរតែប្រើ `http2 on;` ឬវាក្យសម្ព័ន្ធត្រឹមត្រូវដែលមានស្រាប់យោងទៅតាមកំណែដែលត្រូវគ្នា ហើយពិនិត្យមើលជាមួយ `nginx -t` ។ ត្រូវតែបញ្ចូលជាមួយការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេដែលមានស្រាប់ មុនពេលដាក់ឱ្យប្រើប្រាស់ ជំនួសឱ្យការជំនួសផ្នែកទាំងមូលជាមួយនឹងផ្នែកនេះ។ ក៏ពិនិត្យមើលជញ្ជាំងភ្លើង UDP 443 ទីតាំងបញ្ចប់ HTTP/3 និងផ្លូវត្រឡប់របស់អតិថិជននៃ CDN/ប្រូកស៊ីខាងមុខ។ ប្រភេទនៃការបន្ធូរបន្ថយរយៈពេលខ្លីមួយផ្សេងទៀតគឺត្រូវប្រើ `proxy_request_buffering off;` នៅលើផ្លូវប្រូកស៊ីដែលរងផលប៉ះពាល់ ប៉ុន្តែវានឹងផ្លាស់ប្តូរឥរិយាបថនៃការស្ទ្រីមរាងកាយសំណើឡើងលើ ការព្យាយាមបរាជ័យ និងដំណើរការការងារផ្ទុកឡើងមួយចំនួន។ ត្រូវ​បាន​ប្រើ​តែ​បន្ទាប់​ពី​ការ​ធ្វើ​តេ​ស្ត​គ្រប់គ្រាន់ និង​ការ​បញ្ជាក់​ថា​ការ​ណែនាំ​មិន​បាន​ប៉ះ​ពាល់​ផ្លូវ​ប្រូកស៊ី HTTP/3 ដែល​រង​ផល​ប៉ះពាល់។ [S8](https://keendigit.com/km/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/km/insights/nginx-remediation-guide#source-18) ### សំបុត្រវគ្គ 5.6 TLS៖ ការការពារអាទិភាព mTLS ព្រំដែនការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ ប្រសិនបើ​ការអាប់ដេត​មិន​អាច​ធ្វើ​ទៅ​បាន ហើយ​ឧទាហរណ៍​ពឹងផ្អែកលើ​ឃ្លាំងសម្ងាត់​សម័យ​ដែល​បាន​ចែករំលែក + ការបង្វិល​គ្រាប់ចុច​សំបុត្រ​ដោយស្វ័យប្រវត្តិ សូម​វាយតម្លៃ៖ ```nginx # 在 nginx http/server 适当作用域进行配置 ssl_session_tickets off; ``` នេះអាចបិទយន្តការសំបុត្រវគ្គ TLS ដោយហេតុនេះការដកផ្លូវក្លែងក្លាយដែលបានពិពណ៌នានៅក្នុងភាពងាយរងគ្រោះនេះចេញ។ ទោះយ៉ាងណាក៏ដោយ វាអាចប៉ះពាល់ដល់ដំណើរការដំណើរការបន្តវេន។ អ្នកមិនអាចបិទការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រអតិថិជន mTLS ដើម្បី "ជៀសវាងភាពងាយរងគ្រោះ" ព្រោះវានឹងលុបព្រំដែនការផ្ទៀងផ្ទាត់ដើមដោយផ្ទាល់។ [S9](https://keendigit.com/km/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/km/insights/nginx-remediation-guide#source-12) ឯកសារ `ssl_session_ticket_key` ច្បាស់លាស់ និងការបង្វិលសុវត្ថិភាពក៏អាចត្រូវបានប្រើដោយដំណើរការគ្រប់គ្រង TLS ដែលមានជំនាញវិជ្ជាជីវៈ ដើម្បីគេចចេញពីលក្ខខណ្ឌដែលបង្កើតដោយស្វ័យប្រវត្តិ ប៉ុន្តែការឃុំឃាំងកូនសោ ការចែកចាយថ្នាំងពេញលេញ ការបង្វិល និងវដ្តជីវិតសំបុត្រចាស់ទាំងអស់ ចាំបាច់ត្រូវធ្វើសវនកម្មយ៉ាងប្រុងប្រយ័ត្ន។ វាមិនត្រូវបានណែនាំអោយធ្វើកូដរឹងនូវសោដែលអាចប្រើឡើងវិញបានយូរអង្វែងក្នុងការកំណត់រចនាសម្ព័ន្ធគេហទំព័រធម្មតា ឬស្គ្រីបសម្រាប់គ្រាអាសន្នបណ្តោះអាសន្នទេ។ សេវាកម្មសំខាន់ៗដែលប្រើ mTLS គួរតែត្រូវបានត្រួតពិនិត្យបន្ថែមសម្រាប់ឥរិយាបថបន្តវេន TLS និងការបដិសេធសំណើដោយគ្មានវិញ្ញាបនបត្រអតិថិជនត្រឹមត្រូវ។ [S12](https://keendigit.com/km/insights/nginx-remediation-guide#source-12) ### 5.7 តួនាទីនៃប្រព័ន្ធប្រតិបត្តិការ និងការការពារព្រំដែន ```bash # Linux：常见值 2 表示进程地址空间随机化处于完整启用状态 sysctl kernel.randomize_va_space ``` ASLR កម្មករដែលមិនមែនជា root ប្រព័ន្ធឯកសារកុងតឺន័របានតែអាន ការអនុញ្ញាតឯកសារតិចតួច និងការផ្តាច់បណ្តាញអាចកាត់បន្ថយផលប៉ះពាល់នៃសក្តានុពល RCE ។ ASLR មិនជួសជុល heap overflows ឬ UAF ហើយមិនអាចធានាថាកម្មករនឹងមិនគាំង។ WAF ដែនកំណត់អត្រា និងដែនកំណត់ទំហំរាងកាយសំណើមិនជួសជុល TLS ការធ្វើសមកាលកម្មគន្លឹះសំបុត្រ។ [S4](https://keendigit.com/km/insights/nginx-remediation-guide#source-4) ### 5.8 ការយល់ច្រឡំជាទូទៅ៖ ប្រតិបត្តិការទាំងនេះមិនគ្រប់គ្រាន់ដើម្បីបញ្ចប់ការជួសជុល | ប្រតិបត្តិការទូទៅ | ហេតុអ្វីបានជាវាមិនគ្រប់គ្រាន់? | | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | "nginx -v មើលទៅថ្មី" | សាខាដែលវាជាកម្មសិទ្ធិ កំណែកញ្ចប់ backported ពេញលេញនៃកំណែចេញផ្សាយ និងដំណើរការអនឡាញមិនត្រូវបានធីកទេ។ | | "មានតែអ៊ីនធឺណេតមួយប៉ុណ្ណោះដែលត្រូវបានធ្វើឱ្យប្រសើរឡើង" | គំរូដើម Worker/ធុងចាស់/ CDN ចាស់នៅតែទទួលបានសំណើ | | "គេហទំព័រមិនប្រើស្លាក PHP/dynamic" | ពិការភាពកើតឡើងនៅក្នុងផ្លូវស្នូល NGINX ឬការញែកពិធីការ ហើយមិនពឹងផ្អែកលើការប្រតិបត្តិ PHP ទេ។ | | "ការបើក WAF/Cloudflare គឺគ្រប់គ្រាន់ហើយ" | WAF មិនអាចត្រូវបានបញ្ជាក់ដើម្បីទប់ស្កាត់កំហុសនៃអង្គចងចាំអាស្រ័យលើការកំណត់រចនាសម្ព័ន្ធ NGINX ទាំងអស់ ឬកំហុសនៃការបន្ត TLS | | "បានបើករួចហើយ ASLR" | គ្រាន់តែទាញយកប្រយោជន៍ពីការកាត់បន្ថយការលំបាក; DoS ជាមួយនឹងការស្នើសុំការចាក់គឺនៅតែអាចធ្វើទៅបាន | | "HTTP/3 មិន​ត្រូវ​បាន​លាតត្រដាង​ជាមួយ​បណ្តាញ​សាធារណៈ​ទេ ដូច្នេះ​មិន​ចាំបាច់​ដំឡើង​កំណែ​អ្វី​ទាំងអស់" | CVEs បួនផ្សេងទៀតនៅតែទាមទារការវាយតម្លៃឯករាជ្យ។ ហើយអាចមានទំនាក់ទំនងផ្ទាល់ទៅនឹងប្រភពដើមដែលលាក់កំបាំង | | "ភាពងាយរងគ្រោះ `map` ខែកក្កដាត្រូវបានជួសជុល" | ខែតុលា CVE-2026-93479 ពាក់ព័ន្ធនឹងបញ្ហាតំរែតំរង់ការវាយតម្លៃស្គ្រីបជាបន្តបន្ទាប់ | | "បិទឃ្លាំងសម្ងាត់ដោះស្រាយបញ្ហាទាំងអស់" | ប៉ះពាល់តែឃ្លាំងសម្ងាត់ TLS មួយចំនួន ឬ AIO សេណារីយ៉ូ និងមិនគ្របដណ្តប់ឈ្មោះក្លែងក្លាយ ស្គ្រីប HTTP/3 | ## 6. គំនិតនៃការអនុវត្តបំណះផ្លូវការ និងចំណុចពិនិត្យឡើងវិញ ផ្នែកនេះធ្វើតាមការកែតម្រូវ NGINX នៃខែតុលា ឆ្នាំ 2026 ។ អត្ថបទខ្លីៗបង្ហាញពីការផ្លាស់ប្តូរតំណាងសម្រាប់ការពិនិត្យបំណះ។ វាមិនពេញលេញទេ ការជួសជុលដែលអាចចងក្រងដោយឯករាជ្យ។ សម្រាប់ការបង្កើតផ្ទាល់ខ្លួន សូមពិនិត្យមើលការប្តេជ្ញាចិត្តពេញលេញ កូដជុំវិញ និងការសាកល្បង ហើយចូលចិត្តការចេញផ្សាយដែលគាំទ្រពេញលេញ។ [S5](https://keendigit.com/km/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/km/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/km/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/km/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/km/insights/nginx-remediation-guide#source-9) ### 6.1 CVE-2026-15176៖ URI ត្រូវបានសរសេរឡើងវិញដើម្បីរួមបញ្ចូលលក្ខខណ្ឌបដិសេធការគូសផែនទីផ្លូវ `alias` ការប្តេជ្ញាចិត្តខាងលើដែលបានកែប្រែ `ngx_http_map_uri_to_path()` នៅក្នុង `src/http/ngx_http_core_module.c`៖ ```diff - if (alias && !r->valid_location) { + if (alias && (!r->valid_location || r->uri_changed)) { ``` ការផ្តោតអារម្មណ៍ពិនិត្យឡើងវិញ៖ ផ្លូវប្រព័ន្ធឯកសារមិនអាចបន្តត្រូវបានគណនានៅពេលដែល URI បានផ្លាស់ប្តូរ ប៉ុន្តែអត្ថន័យទីតាំងដែលត្រូវគ្នានៃ `alias` លែងអាចទុកចិត្តបាន។ នេះ​គឺ​ជា​ការ​ពង្រឹង​ដល់​ការ​រឹតត្បិត​មុន​រដ្ឋ។ វាមិនមែនជាការត្រួតពិនិត្យសាមញ្ញទេថាតើសំណើ URI មានតួអក្សរខុសច្បាប់ដែរឬទេ។ [S5](https://keendigit.com/km/insights/nginx-remediation-guide#source-5) ### 6.2 CVE-2026-93479៖ បែងចែកយ៉ាងត្រឹមត្រូវរវាងប្រវែងទិន្នន័យលទ្ធផល និងប្រវែងបម្រុង ការប្តេជ្ញាចិត្តខាងលើធ្វើបច្ចុប្បន្នភាព `src/http/ngx_http_script.c` និង `src/stream/ngx_stream_script.c` ក្នុងពេលតែមួយ។ គោលបំណងស្នូលអាចត្រូវបានសង្ខេបដូចជា: ```diff - n = len; + n = 0; /* ...计算实际脚本输出长度... */ - value->len = n; - value->data = ngx_pnalloc(pool, n); + value->len = n + len; + value->data = ngx_pnalloc(pool, n + len); ``` នៅទីនេះ `pool` គឺជាឈ្មោះប៉ារ៉ាម៉ែត្រដែលបង្ហាញ៖ កន្សោមការបែងចែក HTTP និង Stream ខុសគ្នា។ ការផ្លាស់ប្តូរគណនាប្រវែងលទ្ធផលស្គ្រីបជាមុនសិន បន្ទាប់មកបន្ថែមប្រវែងដែលបានបម្រុងទុកទៅការបែងចែកចុងក្រោយ ដូច្នេះលទ្ធផលមិនសរសេរជាន់លើទំហំដែលបានបម្រុងទុកទេ។ [S6](https://keendigit.com/km/insights/nginx-remediation-guide#source-6) នៅពេលធ្វើសវនកម្ម និង backporting អ្នកវាយតម្លៃដែលត្រូវគ្នានៃ HTTP/Stream ក៏ត្រូវតែគ្របដណ្តប់ផងដែរ។ មានតែការពិនិត្យមើលឯកសារវាក្យសម្ព័ន្ធនៃការកំណត់រចនាសម្ព័ន្ធ `map` មិនអាចបង្ហាញថាពិការភាពត្រូវបានជួសជុលទេ។ ### 6.3 CVE-2026-97205៖ កំណត់កម្រិតសុវត្ថិភាពសម្រាប់ចំនួនប្រតិបត្តិការអសមកាល 8 ប៊ីត ខាងលើបានបន្ថែមនៅ `src/http/ngx_http_request.h`៖ ```c #define NGX_HTTP_MAX_BLOCKED 250 ``` ហើយបន្ថែមធាតុស្រដៀងគ្នាទៅនឹងការអានឯកសារអសមកាល ការរង់ចាំឃ្លាំងសម្ងាត់ ការច្រោះលទ្ធផល និងប្រតិបត្តិការខ្សែស្រឡាយ៖ ```c if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) { /* 使用同步路径，或者拒绝新的异步操作 */ } ``` ការផ្តោតអារម្មណ៍ពិនិត្យឡើងវិញ៖ ផ្លូវកូដពិតប្រាកដទាំងអស់ដែលនឹងបន្ថែម `r->main->blocked` ត្រូវតែគ្របដណ្តប់។ អ្នកមិនអាចសរសេរកម្រិតថេរនៅក្នុងឯកសារបឋមកថាបានទេ។ Backport ក៏ត្រូវពិនិត្យមើលការសម្របសម្រួលពេញលេញនៃការធ្លាក់ចុះសមកាលកម្ម ការហៅត្រឡប់មកវិញអសមកាល និងការត្រលប់មកវិញនូវកំហុស ដើម្បីធានាថាការជាប់គាំងឬការលេចធ្លាយឯកសារយោងនឹងមិនបណ្តាលមកពីការបដិសេធដោយផ្ទាល់នូវកិច្ចការនោះទេ។ [S7](https://keendigit.com/km/insights/nginx-remediation-guide#source-7) ### 6.4 CVE-2026-95101៖ រក្សាស្ថានភាព `skip` ដាច់ដោយឡែកសម្រាប់ស៊ុមមិនស្គាល់ ចរន្តខាងលើបន្ថែមវាល `skip` នៅក្នុងរចនាសម្ព័ន្ធស្ថានភាពញែក HTTP/3 និងអនុវត្តការបំបែកស្ថានភាព៖ ```c if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) { st->skip = st->length; st->length = 0; st->state = sw_skip; } /* ... */ rc = ngx_http_v3_parse_skip(b, &st->skip); ``` គន្លឹះគឺមិនមែនដើម្បី "បិទស៊ុម HTTP/3 ដែលមិនស្គាល់" ប៉ុន្តែដើម្បីធានាថាឆ្លងកាត់ការអានច្រើនដង ការរាប់បៃដែលបានរំលង និងប្រវែងបន្ទុក DATA តែងតែត្រូវបានគ្រប់គ្រងដោយរដ្ឋឯករាជ្យ។ ការវាយតម្លៃគួរតែផ្តោតលើការបំបែកសតិបណ្ដោះអាសន្ននៃស៊ុមមិនស្គាល់ និងភាពស៊ីសង្វាក់គ្នាជាយថាហេតុនៃ `client_max_body_size` ។ [S8](https://keendigit.com/km/insights/nginx-remediation-guide#source-8) ### 6.5 CVE-2026-97629៖ ធ្វើសមកាលកម្មអារេរន្ធគ្រាប់ចុច TLS ពេញលេញ ការផ្លាស់ប្តូរចរន្តទឹកមានទីតាំងនៅ `src/event/ngx_event_openssl.c`៖ ```diff ngx_memcpy(keys->elts, cache->ticket_keys, - 2 * sizeof(ngx_ssl_ticket_key_t)); + keys->nelts * sizeof(ngx_ssl_ticket_key_t)); ``` រូបភាពដើមមានរន្ធដោតបី ប៉ុន្តែមានតែពីរដំបូងប៉ុណ្ណោះដែលត្រូវបានចម្លង។ ជំនួសមកវិញ ធ្វើសមកាលកម្មដោយផ្អែកលើចំនួនពិតនៃធាតុអារេ ដើម្បីធានាថាសំណុំគន្លឹះបោះឆ្នោតរបស់ Worker គឺស្របជាមួយនឹងអង្គចងចាំដែលបានចែករំលែក។ នៅពេលពិនិត្យមើល សូមបញ្ជាក់ផងដែរថា ការបែងចែកអារេ ការចាប់ផ្តើម ការចាក់សោរួមគ្នា និងតក្កវិជ្ជាបង្វិលគឺស្រប ជាជាងគ្រាន់តែពិនិត្យមើលការកែប្រែប្រវែង `memcpy` ម្តង។ [S9](https://keendigit.com/km/insights/nginx-remediation-guide#source-9) ### 6.6 ហេតុអ្វីបានជាវាមិនត្រូវបានណែនាំអោយអនុវត្តតែបំណែកបំណះដែលខ្ចាត់ខ្ចាយ? ការកែប្រែទាំងប្រាំនេះលាតសន្ធឹង `src/http`, `src/stream`, `src/http/v3` និង `src/event` រៀងៗខ្លួន ហើយកំណែចាស់អាចមានផ្នែកបន្ថែមសុវត្ថិភាព និងផ្នែកបន្ថែមក្រៅផ្លូវការ។ Backporting គួរបង្កើតម៉ាទ្រីសពិនិត្យខាងក្រោម៖ | ពិនិត្យវត្ថុ | អ្វីដែលត្រូវតែបញ្ជាក់ | | ---------------- | ---------------------------------------------------------------------------------------------------- | | ប្រភពបំណះ | ការដាក់ស្នើជាផ្លូវការ កំណែគោលដៅដែលត្រូវគ្នា បំណះពេញលេញ និងការផ្ទៀងផ្ទាត់ហត្ថលេខា | | សំណុំបំណះដើម | មិន​មាន​ជម្លោះ​ជាមួយ​នឹង​ការ​កែប្រែ​ប្រវត្តិសាស្ត្រ​ដូច​ជា CVE-2026-42533 ការ​ចែកចាយ backport ជាដើម។ | | ផ្លូវកូដ | ស្គ្រីប HTTP + Stream, AIO/thread, HTTP/3, OpenSSL សំបុត្រត្រូវបានគ្របដណ្តប់ទាំងអស់ | | ចងក្រងត្រូវគ្នា។ | OpenSSL, PCRE, ម៉ូឌុល ABI, ម៉ូឌុលថាមវន្ត និងតំណភ្ជាប់ភាពអាស្រ័យគឺស្រប | | តំរែតំរង់មុខងារ | `alias` សរសេរឡើងវិញ កំណត់ហេតុថាមវន្ត SSI/AIO ការផ្ទុកឡើង HTTP/3 ការបន្តសម័យ mTLS | | ពេលដំណើរការ | Worker/Pods ទាំងអស់ដំណើរការការស្ថាបនាដែលបានផ្ទៀងផ្ទាត់ថ្មី គ្មានរូបភាពកេរ្តិ៍ដំណែលនៅសល់ទេ។ | សម្រាប់ក្រុមដែលរក្សាការចេញផ្សាយផ្ទាល់ខ្លួន វាត្រូវបានផ្ដល់អនុសាសន៍ឱ្យរក្សាលេខសម្គាល់បំណះដែលអាចធ្វើសវនកម្មបាន កំណែកញ្ចប់ កំណត់ហេតុសាងសង់ និងរបាយការណ៍តំរែតំរង់សម្រាប់ CVE នីមួយៗ។ សម្រាប់ប្រតិបត្តិការ និងការថែទាំធម្មតា ដំណោះស្រាយដែលមានសុវត្ថិភាពបំផុតគឺត្រូវដំឡើងបច្ចុប្បន្នភាពសុវត្ថិភាពពេញលេញរបស់អ្នកលក់។ ## 7. ការតាមដានភាពងាយរងគ្រោះជាប្រវត្តិសាស្ត្រ សាខាចាស់ និងផលិតផលផ្សេងទៀត។ ### ភាពងាយរងគ្រោះស្នូល 7.1 NGINX ដែលសក្តិសមសម្រាប់ការបញ្ជាក់ក្នុងពេលដំណាលគ្នាចាប់ពីខែឧសភាដល់ខែកញ្ញា ឆ្នាំ 2026 ករណី NGINX ជាច្រើនដែលមិនត្រូវបានអាប់ដេតក្នុងរយៈពេលយូរ មិនត្រឹមតែរងផលប៉ះពាល់ដោយបញ្ហាថ្មីនៅក្នុងខែតុលាប៉ុណ្ណោះទេ។ ខាងក្រោមនេះគឺជាថ្នាំងជួសជុលតំណាងក្នុងពេលអនាគតដ៏ខ្លី៖ [S1](https://keendigit.com/km/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/km/insights/nginx-remediation-guide#source-2) | CVE | ការចេញផ្សាយជួសជុលដំបូង | ហានិភ័យ និងលក្ខខណ្ឌសំខាន់ៗដែលតម្រូវឱ្យមានសវនកម្ម | | -------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | CVE-2026-42945 | Stable 1.30.1 / Mainline 1.31.0 ថ្ងៃទី 13 ឧសភា | `rewrite` ការចាប់យក regex អនាមិក និងការជំនួសតក្កវិជ្ជាធ្វើឱ្យហប់ហៀរ, សក្តានុពល RCE; មានរបាយការណ៍ជាសាធារណៈអំពីការប៉ុនប៉ងវាយប្រហារក្នុងព្រៃ | | CVE-2026-9256 | Stable 1.30.2 / Mainline 1.31.1 ថ្ងៃទី 22 ឧសភា | ការចាប់យក regex ត្រួតស៊ីគ្នា និងការប៉ាន់ប្រមាណប្រវែងនៅក្នុង `rewrite` នាំឱ្យលើស | | CVE-2026-42055 | Stable 1.30.3 / Mainline 1.31.2 ថ្ងៃទី 17 ខែមិថុនា | HTTP/2 ការកំណត់រចនាសម្ព័ន្ធជាក់លាក់ទៅចរន្តទឹក ឬ gRPC លក្ខខណ្ឌបឋមកថាសំណើធំបង្កឱ្យមានការហៀរសំបោរ | | CVE-2026-42530 | Mainline 1.31.2 ថ្ងៃទី 17 ខែមិថុនា | ការប្រើប្រាស់ HTTP/3 បន្ទាប់ពីឥតគិតថ្លៃ; សញ្ញាសម្គាល់ផ្លូវការដែលរងផលប៉ះពាល់ជួរ `1.31.0–1.31.1` | | CVE-2026-42533 | Stable 1.30.4 / Mainline 1.31.3 ថ្ងៃទី 15 ខែកក្កដា | `map` + ការវាយតម្លៃអថេរចាប់យក regex បណ្តាលឱ្យហៀរសំបោរ ហើយបំណះជាបន្តបន្ទាប់មានទំនាក់ទំនងតំរែតំរង់ជាមួយ CVE-2026-93479 ក្នុងខែតុលា | | CVE-2026-60005 | Stable 1.30.4 / Mainline 1.31.3 ថ្ងៃទី 15 ខែកក្កដា | `ngx_http_slice_module` មាតិកាអង្គចងចាំលេចធ្លាយក្រោមលក្ខខណ្ឌអាប់ដេតអថេរជាក់លាក់ និងឃ្លាំងសម្ងាត់ | | CVE-2026-56434 | Stable 1.30.4 / Mainline 1.31.3 ថ្ងៃទី 15 ខែកក្កដា | SSI គឺទាក់ទងទៅនឹង UAF; មិនមែនជាមូលហេតុ root ដូចគ្នាទេ ដែលជាភាពងាយរងគ្រោះរាប់ AIO របស់ខែតុលា | | CVE-2026-90439 | Stable 1.30.5 / Mainline 1.31.6 ថ្ងៃទី 15 ខែកញ្ញា | លើសចំណុះមានកំណត់នៃ HTTP/3 + ជាក់លាក់ OpenSSL រួមផ្សំកំណែដែលបង្ហាញជាចម្បងថាការគាំង/ខូចអង្គចងចាំមានកំណត់ | ភាពងាយរងគ្រោះផ្សេងទៀតដូចជា NGINX Core, HTTP/2, សំណុំតួអក្សរ និង SMTP ដែលបានប្រកាសនៅឆ្នាំ 2026 ក៏គួរតែត្រូវបានស៊ើបអង្កេតផងដែរ យោងទៅតាមព្រឹត្តិបត្រសុវត្ថិភាពផ្លូវការ។ តារាងនេះផ្តោតដោយចេតនាលើព្រឹត្តិការណ៍ធម្មតាដែលពាក់ព័ន្ធបំផុតទៅនឹងការដាក់ឱ្យប្រើប្រាស់ប្រូកស៊ីបញ្ច្រាសដែលប្រឈមមុខនឹងសាធារណៈបច្ចុប្បន្ន NGINX ហើយមានសុវតិ្ថភាពនៃអង្គចងចាំ ឬស្នើសុំការពាក់ព័ន្ធអំពីភាពត្រឹមត្រូវ។ មិនមែន CVEs ទាំងអស់ក្នុងឆ្នាំ 2026។ បញ្ជី។ [S1](https://keendigit.com/km/insights/nginx-remediation-guide#source-1) #### ហេតុអ្វីត្រូវយកចិត្តទុកដាក់ជាពិសេសចំពោះ CVE-2026-42945 មានព្រឹត្តិបត្រសុវត្ថិភាពពីភ្នាក់ងាររដ្ឋាភិបាលដែលកត់ត្រាសកម្មភាពកេងប្រវ័ញ្ចក្នុងព្រៃ និងព័ត៌មានកូដកេងប្រវ័ញ្ចសាធារណៈសម្រាប់ភាពងាយរងគ្រោះ `rewrite` នេះក្នុងខែឧសភា។ ដូច្នេះ សម្រាប់ករណីដែលមិនត្រូវបានជួសជុលរយៈពេលយូរចាប់ពីខែឧសភាដល់បច្ចុប្បន្ន ហើយបានបើកកន្សោមធម្មតាដែលស្មុគស្មាញ សរសេរឡើងវិញនៅលើបណ្តាញសាធារណៈ បន្ថែមពីលើការបញ្ចប់ការជួសជុល ការគាំង Worker មិនធម្មតា កំណត់ហេតុចូលដំណើរការ និងការផ្លាស់ប្តូរគួរឱ្យសង្ស័យនៅពេលនោះ គួរតែត្រូវបានពិនិត្យបន្ថែម។ [S23](https://keendigit.com/km/insights/nginx-remediation-guide#source-23) "ការប៉ុនប៉ងវាយប្រហារបានកើតឡើង" មិនបង្ហាញដោយស្វ័យប្រវត្តិថាអ្នកវាយប្រហារបានប្រតិបត្តិពាក្យបញ្ជាដែលអាចទុកចិត្តបានលើគ្រប់គោលដៅនោះទេ។ នៅពេលដែលការឆ្លើយតបឧប្បត្តិហេតុត្រូវបានពាក់ព័ន្ធ សូចនាករសម្របសម្រួល និងការគាំងដំណើរការគួរតែត្រូវបានស៊ើបអង្កេតដាច់ដោយឡែកពីភស្តុតាងពិតនៃការកើនឡើង ឬការបន្ត។ ### ការជួសជុល 7.2 សម្រាប់កំណែចាស់ និងការចែកចាយ backports NGINX សាខាផ្សេងៗគ្នាមានវដ្តនៃការគាំទ្រផ្ទាល់ខ្លួន និងពេលវេលាណែនាំភាពងាយរងគ្រោះខុសៗគ្នា។ បំណះថ្មីទាំង 5 មិនអាចត្រូវបានដាក់ឱ្យប្រើប្រាស់សម្រាប់ដើមប្រភពដំបូងទាំងអស់ដោយគ្មានការពិនិត្យនោះទេ។ | កន្លែងកើតហេតុ | យុទ្ធសាស្ត្រដែលបានណែនាំ | | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | កំណែចេញផ្សាយបានប្រកាសបំណះសុវត្ថិភាពពេញលេញ | ប្រើកញ្ចប់អ្នកលក់ និងឯកសារកំណែកញ្ចប់ពេញលេញ។ ជៀសវាងការជំនួសដោយប្រព័ន្ធគោលពីរទទេខាងលើដែលមិនឆបគ្នា។ | | Debian 12 និងការចេញផ្សាយដែលរងផលប៉ះពាល់ផ្សេងទៀតដែលមិនទាន់គ្របដណ្តប់ដោយ CVEs ទាំងអស់នៅក្នុងបាច់នេះ | ដាក់ស្នើការបញ្ជាទិញការងារហានិភ័យ កំណត់ការប៉ះពាល់ខាងក្រៅ និងពិនិត្យមើលស្ថានភាពអ្នកផ្គត់ផ្គង់/ELTS; ផ្លាស់ប្តូរ ឬប្រើខ្សែសង្វាក់ការចេញផ្សាយការថែទាំដែលអាចផ្ទៀងផ្ទាត់បាននៅពេលចាំបាច់ | | សាខាប្រវត្តិសាស្ត្រដែលបានបញ្ចប់ការគាំទ្រ | ផ្តល់អាទិភាពដល់ការធ្វើចំណាកស្រុកទៅកំណែដែលគាំទ្រ។ ប្រសិនបើការត្រលប់ក្រោយរយៈពេលខ្លីគឺចាំបាច់ អ្នកថែទាំនឹងវាយតម្លៃភាពអាស្រ័យ និងភាពឆបគ្នានៃបំណះ ហើយសរសេរការធ្វើតេស្តពេញលេញ។ | | ភ្ជាប់មកជាមួយសម NGINX (OpenResty, Tengine, ច្រកចេញចូលតាមតម្រូវការ) | ដំបូងកំណត់ថាតើផ្លូវកូដដែលត្រូវគ្នាត្រូវបានរួមបញ្ចូល ហើយបន្ទាប់មកប្រើសេចក្តីថ្លែងការណ៍សុវត្ថិភាពរបស់អ្នកថែទាំសម។ វា​មិន​អាច​ស្មើ​ផ្ទាល់​នឹង​កំណែ​ខាង​លើ​ទេ។ | | បំណះសុវត្ថិភាពនាំឱ្យមានការផ្លាស់ប្តូរមុខងារអាជីវកម្ម | ទទួលយកការចេញផ្សាយជាដំណាក់កាល ការផ្លាស់ប្តូរចរាចរណ៍រវាងកំណែ និងការសម្របតាមការកំណត់។ វាមិនសមស្របទេក្នុងការស្តារកំណែដែលមិនបានជួសជុលនៃបណ្តាញសាធារណៈដោយគ្មានភាពឯកោ។ | ### 7.3 ដំណោះស្រាយដាច់ដោយឡែកសម្រាប់ njs, Ingress និង NGINX Core - njs៖ បន្ថែមពីលើកម្មវិធីសំខាន់ NGINX អ្នកក៏ត្រូវពិនិត្យមើលកំណែរបស់ម៉ូឌុល JavaScript NGINX ខ្លួនឯងផងដែរ។ `njs 1.0.2` ជួសជុលការអស់អង្គចងចាំក្នុងការវិភាគ XML ខែតុលា ឆ្នាំ 2026 និងបញ្ហាភាពមិនស៊ីសង្វាក់នៃសុពលភាព XML ជាមួយនឹងគុណលក្ខណៈយោងអង្គភាព។ សម្រាប់ការដាក់ពង្រាយដែលភ្ជាប់ជាមួយនឹងការផ្ទៀងផ្ទាត់ហត្ថលេខា XML ដោយប្រើ `nginx-saml` អ្នកគួរតែអានការណែនាំផ្លូវការ njs បន្ថែមទៀតសម្រាប់សេណារីយ៉ូកម្មវិធីជំនួយ។ [S20](https://keendigit.com/km/insights/nginx-remediation-guide#source-20) - F5 NGINX Plus / NGINX Ingress Controller៖ លើសពីនេះ ឧបករណ៍បញ្ជា និង Gateway Fabric នីមួយៗអាចមានព្រឹត្តិបត្រសុវត្ថិភាពបន្ថែម កំណែវេចខ្ចប់ផ្សេងៗគ្នា និងភាពងាយរងគ្រោះគោលការណ៍តែមួយគត់។ ការអាប់ដេតស្រទាប់មួយមិនមានន័យថាធ្វើបច្ចុប្បន្នភាពស្រទាប់មួយផ្សេងទៀតដោយស្វ័យប្រវត្តិនោះទេ។ [S19](https://keendigit.com/km/insights/nginx-remediation-guide#source-19) - Kubernetes សហគមន៍ ingress-nginx៖ មន្ត្រី Kubernetes បានប្រកាសរួចហើយថាឧបករណ៍បញ្ជាបានឈប់ថែទាំនៅខែមីនា ឆ្នាំ 2026 ហើយឃ្លាំងរបស់វាមិនអាចច្រឡំជាមួយឧបករណ៍បញ្ជា F5 បានទេ។ អាជីវកម្មដែលរងផលប៉ះពាល់គួររៀបចំផែនការធ្វើចំណាកស្រុកដោយរលូន និងផ្ទៀងផ្ទាត់ចំណារពន្យល់ Ingress និងភាពខុសគ្នាតាមន័យ Gateway API ជំនួសឱ្យការរង់ចាំកំណែសុវត្ថិភាពថ្មី។ [S21](https://keendigit.com/km/insights/nginx-remediation-guide#source-21) ## 8. លក្ខណៈវិនិច្ឆ័យនៃការទទួលយក និងការត្រួតពិនិត្យតាមដាន វាត្រូវបានណែនាំថាបញ្ជីខាងក្រោមត្រូវបានប្រើជាលក្ខខណ្ឌទទួលយកសម្រាប់ការផ្លាស់ប្តូរការបញ្ជាទិញការងារ៖ | គម្រោង | ស្តង់ដារគុណវុឌ្ឍិ | ភស្តុតាងដែលអាចរក្សាទុកបាន។ | | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | ទ្រព្យសម្បត្តិ និងវិបផតថលគ្របដណ្តប់ | រាល់វត្ថុដែលភ្ជាប់មកខាងក្រៅ និងដោយផ្ទាល់ដែលអាចឆ្លងកាត់ CDN ត្រូវបានស្តុកទុក។ | ឈ្មោះដែន, LB, IP, Pod/បញ្ជីកុងតឺន័រ | | ប្រភពកញ្ចប់ និងវិសាលភាពជួសជុល | ប្រើកំណែដែលបានបញ្ជាក់ដើម្បីគ្របដណ្តប់ CVEs ដែលអាចអនុវត្តទាំងអស់។ | ការណែនាំអំពីសុវត្ថិភាពខាងលើ, USN/DSA, កំណែកញ្ចប់, រូបភាពសង្ខេប | | ដំណើរការចាស់ចេញ | master/worker/កុងតឺន័រចាស់ទាំងអស់ត្រូវបានជំនួស | PID/ពេលវេលាចាប់ផ្តើម ស្ថានភាពដាក់ពង្រាយរំកិល រូបភាពដែលកំពុងដំណើរការ | | សវនកម្មការកំណត់រចនាសម្ព័ន្ធ | បន្សំដែលមានហានិភ័យខ្ពស់ត្រូវបានលុបចោល ឬគ្របដណ្តប់ដោយបំណះ ហើយទំនាក់ទំនងមរតកត្រូវបានផ្ទៀងផ្ទាត់ | កែប្រែឡើងវិញនូវសេចក្តីសង្ខេប និងកំណត់ត្រាសវនកម្មនៃ `nginx -T` | | TLS/mTLS | វិញ្ញាបនបត្រដែលអាចទុកចិត្តបានឆ្លងកាត់; វិញ្ញាបនបត្រមិនត្រឹមត្រូវ ឬបាត់ត្រូវបានបដិសេធ។ ការបន្តវគ្គបន្តមិនឆ្លងកាត់ការផ្ទៀងផ្ទាត់ទេ។ | ការធ្វើតេស្តការអនុញ្ញាតអវិជ្ជមាន/វិជ្ជមាន លទ្ធផលតេស្ត TLS ដែលបានគ្រប់គ្រង | | តួសំណើ HTTP/3 | បើកផ្លូវដែលបានជួសជុល; ការស្នើសុំខាងលើរាងកាយ និងការបិទបើកដំណើរការត្រឹមត្រូវ។ | HTTP/3 ការបង្ហោះប្រូកស៊ី ការធ្វើតេស្តតំរែតំរង់កម្រិតសំឡេង | | SSI/AIO | មុខងារបំពេញតាមតម្រូវការ Worker មិនមានការរំលូតកូនមិនធម្មតាទេ។ | ការតំរែតំរង់អាជីវកម្ម ការត្រួតពិនិត្យអត្រាគាំង និងកំហុស | | ការត្រួតពិនិត្យប្រតិបត្តិការ និងថែទាំ | គ្មានករណីលើកលែងជាក់ស្តែង 5xx, SIGSEGV ដំណើរការចេញម្តងហើយម្តងទៀត | សូចនាករសេវាកម្ម និងកំណត់ហេតុមុន និងក្រោយការផ្លាស់ប្តូរ | | យុទ្ធសាស្ត្រវិលត្រឡប់មកវិញ | ប្រសិនបើការត្រលប់មកវិញគឺចាំបាច់ ទីមួយកំណត់ការប៉ះពាល់ជាមុន និងរក្សាព្រំដែនសុវត្ថិភាព | ផ្លាស់ប្តូរការបញ្ជាទិញ លំហូរបន្ទាន់ និងផែនការដាក់ឱ្យនៅដាច់ពីគេ | | វដ្តជីវិតជាបន្តបន្ទាប់ | កំណត់ការជាវព្រឹត្តិបត្រសុវត្ថិភាព ប្រេកង់ធ្វើបច្ចុប្បន្នភាពកុងតឺន័រ និងផែនការផ្ទេរសាខា | ធ្វើបច្ចុប្បន្នភាពបញ្ជីឈ្មោះ អ្នកទទួលខុសត្រូវ និងកាលបរិច្ឆេទសវនកម្មបន្ទាប់ | ### 8.1 តើអ្នកគួរផ្តោតលើអ្វីនៅក្នុងកំណត់ហេតុ និងស្ថានភាពដែលកំពុងដំណើរការ? ដោះស្រាយបញ្ហាមិនប្រក្រតីនៅលើម៉ាស៊ីនមេដែលត្រូវបានលាតត្រដាងអស់រយៈពេលជាយូរ `worker process exited on signal` 、 `SIGSEGV` ស្នើសុំការបរាជ័យកើនឡើង ការប្រមូលផ្តុំការចូលប្រើប្រភពមិនប្រក្រតី ការមិនរំពឹងទុក TLS វគ្គបន្ត/ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ ដំណើរការត្រឡប់មកវិញ និងសំណើរាងកាយមិនប្រក្រតី។ សូចនាករទាំងនេះអាចត្រូវបានប្រើជាតម្រុយស៊ើបអង្កេតតែប៉ុណ្ណោះ ហើយមិនមែនជាភស្តុតាងគ្រប់គ្រាន់ដើម្បីបញ្ជាក់ដោយផ្ទាល់ថា CVE ជាក់លាក់មួយត្រូវបានកេងប្រវ័ញ្ចនោះទេ។ កង្វះ​កំណត់​ហេតុ​ពាក់ព័ន្ធ​មិន​បង្ហាញ​ថា​មិន​មាន​ការ​វាយ​ប្រហារ​ទេ។ ### 8.2 បានណែនាំពាក្យសន្និដ្ឋានហានិភ័យចុងក្រោយ របាយការណ៍ទទួលយកសម្រាប់បរិយាកាសផលិតកម្មគួរតែប្រើកន្សោមច្បាស់លាស់ដូចខាងក្រោមៈ > NGINX ច្រកចូលសេវាកម្មខាងក្រៅ និងប្រភពកញ្ចប់កម្មវិធីត្រូវបានកំណត់អត្តសញ្ញាណ។ ករណីដែលអាចអនុវត្តបានទាំងអស់ត្រូវបានដំឡើងកំណែទៅជាកំណែសុវត្ថិភាពផ្លូវការខាងលើ ឬ backport ដែលបានបញ្ជាក់ដោយអ្នកលក់ត្រូវបានបញ្ចប់។ Worker និងធុងចាស់ត្រូវបានជំនួស។ ឈ្មោះហៅក្រៅ/សរសេរឡើងវិញ/ផែនទី, AIO/SSI, HTTP/3 តួសំណើ និង TLS Session Ticket/mTLS ការកំណត់រចនាសម្ព័ន្ធពាក់ព័ន្ធត្រូវបានសវនកម្ម និងឆ្លងកាត់ការសាកល្បង និងដំណើរការមុខងារឡើងវិញ។ សម្រាប់ករណីដែលមិនទាន់បានបញ្ចប់ការអាប់ដេត បន្ថែមលើការចុះឈ្មោះតំបន់ប៉ះពាល់ វិធានការសំណង អ្នកទទួលខុសត្រូវ និងកាលបរិច្ឆេទបញ្ចប់។ ប្រសិនបើបំណះសម្រាប់ Debian 12 ឬការចេញផ្សាយផ្សេងទៀតនៅតែមិនពេញលេញ វាមិនសមស្របទេក្នុងការវិនិច្ឆ័យទម្រង់ទទួលយកទាំងមូលថា "បានបញ្ចប់"។ CVE ដែលមិនបានដោះស្រាយ ថាតើមានការកំណត់រចនាសម្ព័ន្ធកេះដែលត្រូវគ្នា ស្ថានភាពឯកោ និងផ្លូវធ្វើឱ្យប្រសើរឡើងចុងក្រោយគួរតែត្រូវបានកត់ត្រាយ៉ាងច្បាស់។ *** ## ឧបសម្ព័ន្ធ៖ ដកស្រង់ប្រភព និងតំណ ការពិពណ៌នា៖ លេខ `[Sx]` ក្នុងអត្ថបទត្រូវគ្នានឹងផ្នែកនេះ។ ខាងក្រោមនេះផ្តល់អាទិភាពដល់ការប្រកាសអំពីសុវត្ថិភាពគម្រោងកម្រិតខ្ពស់ ការប្តេជ្ញាចិត្តកូដ ការប្រកាសចេញផ្សាយរបស់អ្នកផ្គត់ផ្គង់ និងព័ត៌មានទីភ្នាក់ងារសន្តិសុខជាតិ។ ភាពធ្ងន់ធ្ងរនៃភាពងាយរងគ្រោះដែលបានដកស្រង់ត្រូវបានពិពណ៌នាដោយយោងទៅតាមលក្ខណៈវិនិច្ឆ័យនៃការវាយតម្លៃរបស់ស្ថាប័នចេញនីមួយៗ។ កាលបរិច្ឆេទផ្ទៀងផ្ទាត់ទិន្នន័យគឺថ្ងៃទី 27 ខែតុលា ឆ្នាំ 2026។ ### S1 — NGINX Open Source ព្រឹត្តិបត្រសុវត្ថិភាពផ្លូវការ - មានកំណែដែលរងផលប៉ះពាល់ខាងលើ ជួសជុលសាខា និងកម្រិតភាពធ្ងន់ធ្ងរជាផ្លូវការនៃ CVEs ខែតុលាចំនួន 5 ហើយថែមទាំងគ្របដណ្តប់ភាពងាយរងគ្រោះជាប្រវត្តិសាស្ត្ររហូតដល់ឆ្នាំ 2026។ ### S2 — NGINX កំណែផ្លូវការ កំណត់ត្រាចេញផ្សាយ - - បញ្ជាក់ 1.30.6 / 1.31.7 នៃ 2026-10-14, 1.31.8 នៃ 2026-10-21 និងព្រឹត្តិការណ៍សំខាន់ៗនៃការចេញផ្សាយសុវត្ថិភាពពីខែឧសភាដល់ខែកញ្ញា។ ### S3 - ទីភ្នាក់ងារសន្តិសុខតាមអ៊ីនធឺណិតនៃប្រទេសសិង្ហបុរី៖ F5 NGINX ភាពងាយរងគ្រោះសំខាន់បី - ការពិពណ៌នាអំពីពិន្ទុ CVSS v4.0 9.2 លក្ខខណ្ឌនៃការកំណត់រចនាសម្ព័ន្ធដែលត្រូវការ និងការណែនាំអំពីការបន្ធូរបន្ថយបណ្តោះអាសន្នសម្រាប់ CVE-2026-15176, CVE-2026-93479 និង CVE-2026-97205 ។ ### S4 - NHS ប្រទេសអង់គ្លេស៖ F5 NGINX ការប្រឹក្សាហានិភ័យខ្ពស់ - ពិពណ៌នាអំពីផលប៉ះពាល់ DoS / សក្តានុពល RCE នៃបញ្ហាសុវត្ថិភាពនៃការចងចាំ ហើយឧបសគ្គដូចជា ASLR ត្រូវបានបិទ ឬរំលង។ ### S5 — ប្រភពផ្លូវការប្តេជ្ញា៖ CVE-2026-15176 - ឆ្លើយតបទៅនឹងការត្រួតពិនិត្យស្ថានភាពរបស់ `alias` និង `r->uri_changed` នៅក្នុង `ngx_http_map_uri_to_path()` ។ ### S6 — ប្រភពផ្លូវការប្តេជ្ញា៖ CVE-2026-93479 - ដែលត្រូវគ្នាទៅនឹងប្រវែងស្គ្រីប HTTP/Stream និងតក្កវិជ្ជានៃការបែងចែកសតិបណ្ដោះអាសន្នដែលបានបម្រុងទុក។ ### S7 - ប្រភពផ្លូវការប្តេជ្ញា៖ CVE-2026-97205 - ត្រូវគ្នាទៅនឹងកម្រិតចាប់ផ្ដើមរាប់ `r->main->blocked` `NGX_HTTP_MAX_BLOCKED 250` និងការធ្លាក់ចុះផ្លូវអសមកាល។ ### S8 — ប្រភពផ្លូវការប្តេជ្ញា៖ CVE-2026-95101 - ការបំបែកស្ថានភាពដែលត្រូវគ្នានឹងប្រវែងស៊ុមមិនស្គាល់ HTTP/3 និង DATA ស្នើសុំប្រវែងតួ។ ### S9 — ប្រភពផ្លូវការប្តេជ្ញា៖ CVE-2026-97629 - ត្រូវគ្នាទៅនឹងរន្ធគ្រាប់ចុចទាំងអស់កំឡុងពេលធ្វើសមកាលកម្ម TLS Session Ticket បង្វិល។ ### S10 — F5៖ សេចក្តីប្រកាសរបស់អ្នកលក់ CVE-2026-15176 - រាយបញ្ជីកត្តាបង្កហេតុដូចជា `alias`, `rewrite`, `$request_filename` និងកំណត់ហេតុចូលប្រើប្រាស់។ ### S11 — F5: CVE-2026-93479 សេចក្តីប្រកាសអ្នកលក់ - រាយបញ្ជីការចាប់យកផែនទី regex ផ្លូវ root និងកំណត់លក្ខខណ្ឌវាយតម្លៃអថេរ។ ### S12 — NGINX ផ្លូវការ TLS/SSL ឯកសារម៉ូឌុល - ការពិពណ៌នា `ssl_session_cache`, `ssl_session_tickets`, `ssl_session_ticket_key` និងការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រអតិថិជន និងការណែនាំផ្សេងទៀត។ ### S13 — ប្រឹក្សាសន្តិសុខ: Ubuntu USN-8955-1 (2026-10-26) - ផ្តល់កញ្ចប់កម្មវិធីពេញលេញនូវកំណែថេរ និងវិសាលភាពចែកចាយនៃ Ubuntu 22.04 / 24.04 / 26.04 / 26.10. ### S14 — ប្រឹក្សាសន្តិសុខ: Debian DSA-6575-1 (2026-10-21) - បញ្ជាក់កញ្ចប់ជួសជុលសុវត្ថិភាព `1.26.3-3+deb13u10` សម្រាប់ Debian 13 / trixie ហើយកត់ត្រាទំនាក់ទំនង backport សម្រាប់ CVE-2026-93479 ។ ### S15 — ការតាមដានភាពងាយរងគ្រោះ: Debian Security Tracker: CVE-2026-15176 - ប្រើដើម្បីផ្ទៀងផ្ទាត់ស្ថានភាពជួសជុលការចែកចាយ Debian 12 / bookworm និង Debian 13 / trixie ។ ស្ថានភាពនេះអាចផ្លាស់ប្តូរជាមួយនឹងការធ្វើបច្ចុប្បន្នភាពសុវត្ថិភាពនាពេលអនាគត។ ### S16 — ការតាមដានភាពងាយរងគ្រោះ: Debian Security Tracker: CVE-2026-95101 - ការបញ្ជាក់បន្ថែមអំពីស្ថានភាពសុវត្ថិភាពនៃភាពងាយរងគ្រោះ HTTP/3 នៅលើសាខា Debian ផ្សេងៗគ្នា។ ### S17 — ប្រឹក្សាសន្តិសុខ: Red Hat: CVE-2026-93479 - ការយល់ដឹងបន្ថែមអំពីទំនាក់ទំនងរវាងភាពងាយរងគ្រោះនៃការតំរែតំរង់ខែតុលា និងការជួសជុលសម្រាប់ខែកក្កដា CVE-2026-42533 ។ ### S18 — NGINX ឯកសារម៉ូឌុលប្រូកស៊ីបញ្ច្រាសជាផ្លូវការ - - សួរ​តម្លៃ​អត្ថន័យ​និង​លំនាំដើម​នៃ​ការកំណត់​ដូចជា `proxy_request_buffering`, `client_max_body_size`, `alias`, `aio` ជាដើម។ ### S19 — NGINX Plus កំណត់សម្គាល់ការចេញផ្សាយផ្លូវការ - រាយបញ្ជីសាខា CR/LTS បូក កំណែ បំណះ និងធ្វើឱ្យប្រសើរឡើងការរំលឹកភាពត្រូវគ្នា។ ### S20 — NGINX JavaScript / njs ព្រឹត្តិបត្រសុវត្ថិភាពផ្លូវការ - - មានខែតុលា 2026 njs 1.0.2 និងការបញ្ជាក់ XML ដែលពាក់ព័ន្ធ បញ្ហាអស់អង្គចងចាំ។ ### S21 — Kubernetes៖ សហគមន៍ ingress-nginx ការណែនាំអំពីការចូលនិវត្តន៍ជាផ្លូវការ - - ចំណាំថាគម្រោងនេះបានបញ្ឈប់ការចេញផ្សាយថ្មី និងការជួសជុលសុវត្ថិភាពនៅក្នុងខែមីនា ឆ្នាំ 2026 ហើយវាត្រូវបានផ្ដល់អនុសាសន៍ឱ្យផ្លាស់ប្តូរឧបករណ៍បញ្ជាដែលបានថែទាំ ឬ Gateway API ។ ### S22 — NGINX ការគ្រប់គ្រងសេវាកម្មផ្លូវការ និងការណែនាំអំពីការធ្វើឱ្យប្រសើរប្រព័ន្ធគោលពីរតាមអ៊ីនធឺណិត - ញែកការកំណត់រចនាសម្ព័ន្ធផ្ទុកឡើងវិញ ចាប់ផ្តើមឡើងវិញ និងវិធីសាស្ត្រធ្វើឱ្យប្រសើរឡើងឯកសារដែលអាចប្រតិបត្តិបានតាមអ៊ីនធឺណិតសម្រាប់ការទទួលយកការផ្លាស់ប្តូរដំណើរការ។ ### S23 - ការជូនដំណឹងអំពីសុវត្ថិភាពរបស់រដ្ឋាភិបាល៖ ខែឧសភា ឆ្នាំ 2026 NGINX ភាពងាយរងគ្រោះក្នុងការសរសេរឡើងវិញ - - ផ្តល់ការណែនាំអំពីប្រវត្តិហានិភ័យ និងបច្ចុប្បន្នភាពសុវត្ថិភាពសម្រាប់ CVE-2026-42945; ការវិនិច្ឆ័យទាក់ទងនឹងការកេងប្រវ័ញ្ចក្នុងព្រៃគួរតែផ្អែកលើសេចក្តីប្រកាសរបស់ទីភ្នាក់ងារនៅពេលនោះ និងភស្តុតាងឧប្បត្តិហេតុបន្ថែមទៀត។ ### S24 — F5៖ CVE-2026-95101 និង CVE-2026-97629 សេចក្តីប្រកាសអំពីអ្នកលក់ - - គ្របដណ្តប់ហានិភ័យនៃ HTTP/3 ស្នើសុំការចាក់លើរាងកាយ និងការបង្វិលគ្រាប់ចុចសំបុត្រ TLS ដោយស្វ័យប្រវត្តិរៀងៗខ្លួន។ ### S25 — F5៖ សេចក្តីប្រកាសរបស់អ្នកលក់ CVE-2026-97205 - ការពិពណ៌នា SSI/AIO បង្កឱ្យមានលក្ខខណ្ឌ និងហានិភ័យនៃការខូចខាតការចងចាំដែលអាចកើតមាន។ [ការអាប់ដេតសុវត្ថិភាព NGINX៖ ការត្រួតពិនិត្យការកំណត់រចនាសម្ព័ន្ធ ការធ្វើឱ្យប្រសើរ និងការផ្ទៀងផ្ទាត់](https://keendigit.com/km/news/nginx-security-update) ## ការប្រឹក្សាថែទាំសុវត្ថិភាព មិនប្រាកដថាការផ្លាស់ប្តូរការជឿទុកចិត្តលើវិញ្ញាបនបត្រប៉ះពាល់ដល់ប្រព័ន្ធរបស់អ្នកយ៉ាងដូចម្តេច? យើងអាចជួយវាយតម្លៃអតិថិជនដែលរងផលប៉ះពាល់ និងរៀបចំផែនការធ្វើបច្ចុប្បន្នភាពសុវត្ថិភាព។ [ពិភាក្សាអំពីបច្ចុប្បន្នភាពសុវត្ថិភាព]() [ទំព័រដើម]() · [សន្ទស្សន៍មាតិកា]() KeenDigit LLC · លេខសម្គាល់ឯកសារ Wyoming: 2026-002106155 [ផ្ទៀងផ្ទាត់ជាមួយរដ្ឋលេខាធិការ Wyoming]() © 2026 KeenDigit LLC · Sheridan, Wyoming, សហរដ្ឋអាមេរិក · រក្សាសិទ្ធិគ្រប់យ៉ាង។