ភាពងាយរងគ្រោះ NGINX៖ មូលហេតុ ការជួសជុល និងការផ្ទៀងផ្ទាត់ផលិតកម្ម

កាលបរិច្ឆេទអត្ថបទប្រវត្តិសាស្ត្រ៖ 2026-10-14 (កាលបរិច្ឆេទចេញផ្សាយ និងសុវត្ថិភាព)។ ប្រភពបានពិនិត្យ និងបន្ថែមព័ត៌មានតាមរយៈ 2026-10-27 ។

អត្ថបទនេះត្រូវបានទុកក្នុងប័ណ្ណសារតាមកាលបរិច្ឆេទព្រឹត្តិការណ៍។ កំណែ និងការចេញផ្សាយបច្ចុប្បន្នភាពដែលបានចេញផ្សាយក្រោយថ្ងៃទី 14 ខែតុលា ត្រូវបានរួមបញ្ចូលដូចខាងក្រោម។ ទស្សនិកជន៖ គេហទំព័រ NGINX Open Source / NGINX Plus និងប្រតិបត្តិការប្រូកស៊ីបញ្ច្រាស និងបុគ្គលិកថែទាំ បុគ្គលិកឆ្លើយតបសុវត្ថិភាព អ្នកថែទាំចែកចាយ ក៏ដូចជាវិស្វករដែលចងក្រងដោយខ្លួនឯង NGINX និងរក្សាម៉ូឌុលភាគីទីបី។

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

TL;DR៖ សកម្មភាពអាទិភាព

1. ផ្តល់អាទិភាពដល់ការដំឡើងសុវត្ថិភាព។ សម្រាប់ nginx.org កញ្ចប់ប្រភពបើកចំហ ធ្វើបច្ចុប្បន្នភាព Stable 1.30 សាខាយ៉ាងហោចណាស់ 1.30.6 និង Mainline 1.31 សាខាយ៉ាងហោចណាស់ 1.31.7. នៅកាលបរិច្ឆេទផ្ទៀងផ្ទាត់ 1.31.8 គឺជាចុងក្រោយបំផុត។ Mainline ដោះលែង។ ទាំងនេះគឺជាមូលដ្ឋានសាខាដាច់ដោយឡែក; កុំប្រៀបធៀបលេខរបស់ពួកគេនៅទូទាំងសាខា។ S1 S2
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 ត្រូវបានជួសជុលទេ។ S13S14S15
3. សវនកម្មការបញ្ចូលគ្នានៃការកំណត់រចនាសម្ព័ន្ធចំនួនប្រាំ៖ alias + rewrite + $request_filename , map + regex + ការវាយតម្លៃអថេរ, aio + ssi + include virtual , HTTP/3 ជាមួយ proxy_request_buffering on , និង ssl_session_cache shared:... ជាមួយនឹងស្វ័យប្រវត្តិ TLS ការបង្វិលគ្រាប់ចុចសំបុត្រវគ្គ។ វត្តមាននៃការណែនាំតែម្នាក់ឯងមិនបង្កើតភាពអាចធ្វើអាជីវកម្មបានទេ។ វាយតម្លៃផ្លូវស្នើសុំ និងវិសាលភាពកំណត់រចនាសម្ព័ន្ធ។ S1 S3 S4
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 S4 S8 S12

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

NGINX បានចេញផ្សាយ 1.30.6 (Stable) និង 1.31.7 (Mainline) នៅថ្ងៃទី 14 ខែតុលា ឆ្នាំ 2026 ដោយដោះស្រាយបញ្ហាសុវត្ថិភាពចំនួនប្រាំ។ បីពាក់ព័ន្ធនឹងការហៀរសំបោរ ឬការប្រើប្រាស់បន្ទាប់ពីឥតគិតថ្លៃ និងទទួលបានពិន្ទុ F5 CVSS v4.0 នៃ 9.2 / Critical ។ ពីរផ្សេងទៀតប៉ះពាល់ដល់ភាពត្រឹមត្រូវនៃសំណើ HTTP/3 និងការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រអតិថិជន TLS ។ S1S2S3

បែងចែកប្រព័ន្ធវាយតម្លៃ៖ nginx.org រាយបញ្ជីបញ្ហាទាំងប្រាំជា medium ខណៈពេលដែល F5 CVSS v4.0 និងភ្នាក់ងារសន្តិសុខជាតិមួយចំនួនចាត់ថ្នាក់បញ្ហាអង្គចងចាំទាំងបីជាការសំខាន់។ នេះមិនមែនមានន័យថា ទាំងប្រាំអនុញ្ញាតឱ្យដំណើរការកូដពីចម្ងាយដោយគ្មានលក្ខខណ្ឌនោះទេ។ ការកំណត់រចនាសម្ព័ន្ធ លទ្ធភាពទទួលបានចរាចរណ៍ និងលក្ខខណ្ឌនៅខាងក្រៅបញ្ហាគ្រប់គ្រងរបស់អ្នកវាយប្រហារ។ អំពើពុករលួយនៃការចងចាំ និង RCE ដែលអាចទុកចិត្តបាន គឺជាកម្រិតផ្សេងគ្នានៃភស្តុតាង។ S1S3S4

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 ថ្នាក់ផ្ទាល់ខ្លួន និងចំណាត់ថ្នាក់នៃភាពធ្ងន់ធ្ងរនៃការចែកចាយ។ S1S3S4

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

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

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

2.1 ស្វែងយល់ពីព្រំដែនដែលងាយនឹងមានកំហុសទាំងបីនៅក្នុង NGINX

NGINX worker គឺ​ជា​ដំណើរ​ការ​ដែល​ត្រូវ​បាន​ជំរុញ​ដោយ​ព្រឹត្តិការណ៍​ដែល​មាន​រយៈពេល​យូរ​ដែល​រក្សា​ស្ថានភាព​សំណើ​ ប្រតិបត្តិការ​អសមកាល​ និង​កម្មវិធី​ញែក​ពិធីការ។ ភាពងាយរងគ្រោះនេះបង្កប់នូវឧបសគ្គនៅកម្រិតវិស្វកម្មចំនួនបី៖

1. ការវាយតម្លៃអថេរ និងទំហំអង្គចងចាំត្រូវតែស្របគ្នា៖ rewrite បន្ទាប់ពីផ្លាស់ប្តូរសំណើ URI ការគូសផែនទីផ្លូវត្រូវតែស្របជាមួយ location ដែលមានប្រសិទ្ធភាពនាពេលបច្ចុប្បន្ន។ នៅពេលអ្នកបកប្រែស្គ្រីបគណនាប្រវែងអថេរ ចន្លោះសរសេរត្រូវតែគ្របដណ្ដប់លើលទ្ធផលជាក់ស្តែង និងផ្ទៃដែលបានបម្រុងទុក។
2. ប្រតិបត្តិការអសមកាលត្រូវតែពង្រីកវដ្តជីវិតនៃអង្គចងចាំដែលបានស្នើសុំ៖ នៅពេលដែលមានការអាន និងការសរសេរឯកសារមិនទាន់បញ្ចប់ ការរង់ចាំឃ្លាំងសម្ងាត់ ឬកិច្ចការខ្សែស្រឡាយ នោះក្រុមអង្គចងចាំសំណើដែលពាក់ព័ន្ធមិនអាចត្រូវបានបញ្ចេញជាមុនទេ។
3. ស្ថានភាពពិធីការ និងស្ថានភាពសុវត្ថិភាពមិនអាចលាយបញ្ចូលគ្នា ឬលុបចោលបានទេ៖ HTTP/3 រយៈពេលនៃការរំលងស៊ុមមិនស្គាល់មិនអាចចាត់ទុកថាជាប្រវែងរាងកាយសំណើ DATA បានទេ។ TLS រន្ធគ្រាប់ចុចទាំងអស់ដែលចូលរួមក្នុងការផ្ទៀងផ្ទាត់ហត្ថលេខាត្រូវតែត្រូវបានចាប់ផ្តើម និងធ្វើសមកាលកម្មយ៉ាងត្រឹមត្រូវក្នុងអំឡុងពេលបង្វិលសំបុត្រវគ្គ។

ខ្លឹមសារខាងក្រោមគឺផ្អែកលើ NGINX ការប្តេជ្ញាចិត្តជួសជុល និងប្រកាសពីអ្នកលក់ ដើម្បីពន្យល់ពីយន្តការបរាជ័យដែលអាចកើតឡើង។ បំណែកឧទាហរណ៍គឺសម្រាប់ការវិភាគ មិនមែនជាកូដពេញលេញដែលអាចត្រូវបានប្រើដោយផ្ទាល់ដើម្បីជួសជុលបរិយាកាសផលិតកម្មនោះទេ។ S5S6S7S8S9

2.2 CVE-2026-15176៖ ការគូសផែនទីផ្លូវរវាង alias និង URI ដែលសរសេរឡើងវិញគឺមិនត្រឹមត្រូវទេ។

នៅក្នុង NGINX location ដែលផ្គូផ្គង និង alias របស់វាកំណត់ផ្លូវឯកសារ។ rewrite អាចផ្លាស់ប្តូរសំណើបច្ចុប្បន្ន URI ។ បន្ទាប់ពីការសរសេរឡើងវិញ ការសន្មត់ដែលប្រើដោយការគូសផែនទី location ដើមប្រហែលជាលែងមានទៀតហើយ។

ផ្លូវដំណើរការដែលរងផលប៉ះពាល់មិនបានត្រួតពិនិត្យឱ្យបានគ្រប់គ្រាន់ថាតើសំណើត្រូវបានសរសេរឡើងវិញទេ នៅពេលពិនិត្យមើលស្ថានភាព alias នៅក្នុង ngx_http_map_uri_to_path() ។ នៅពេលដែលការកំណត់រចនាសម្ព័ន្ធបន្តវាយតម្លៃ $request_filename បន្ទាប់ពីសរសេរឡើងវិញ ផ្លូវអាចត្រូវបានសាងសង់ជាមួយនឹងការសន្មត់ដែលមិនអនុលោមតាមស្ថានភាព URI បច្ចុប្បន្ន ដែលនៅទីបំផុតបង្កឱ្យមានការសរសេរក្រៅព្រំដែនទៅកាន់អង្គចងចាំ។ S5

ការរួមបញ្ចូលគ្នាធម្មតា (ប្រើជាឧទាហរណ៍សម្រាប់តែសវនកម្មការកំណត់រចនាសម្ព័ន្ធ ការដាក់ពង្រាយមិនត្រូវបានណែនាំទេ)៖

# 仅用于识别风险模式：不是修复配置
location /foo/ {
    alias /srv/alias-root/;
    rewrite ^/foo/.*$ /new-path;
    return 200 $request_filename;
}

គ្រោះថ្នាក់មិនត្រូវបានកំណត់ចំពោះ return ទេ៖ set, if, add_header, log_format ជាដើម ក៏ចាំបាច់ត្រូវធ្វើសវនកម្មផងដែរ ប្រសិនបើការវាយតម្លៃ $request_filename ត្រូវបានបង្កឡើងក្នុងដំណើរការដូចគ្នា។ return ក្នុងឧទាហរណ៍គ្រាន់តែធ្វើឱ្យផ្លូវរដ្ឋនេះងាយស្រួលមើលប៉ុណ្ណោះ វាមិនអាចត្រូវបានប្រើដើម្បីសន្និដ្ឋានថាការកំណត់រចនាសម្ព័ន្ធផលិតកម្មទាំងអស់នឹងបង្កើតលំហូរលើស។ S5S10

ផលវិបាកនៃការវាយប្រហារ៖ ការសាងសង់សំណើអាចបណ្តាលឱ្យ Worker ចាប់ផ្តើមឡើងវិញ ឬការរំខានសេវាកម្ម។ នៅក្រោមលក្ខខណ្ឌដូចជា ASLR ត្រូវបានបិទ ឬអាចត្រូវបានឆ្លងកាត់ វាមានសក្តានុពល RCE ។ ស្នូលនៃបំណះខាងលើគឺដើម្បីបដិសេធមិនបញ្ចប់ការគូសផែនទីផ្លូវ URI ដែលសរសេរឡើងវិញនៅក្នុងបរិបទ alias ដែលលែងមានសុពលភាព ជាជាងការពង្រីកបណ្តុំបណ្តោះអាសន្នជាក់លាក់មួយ។ S5S10

2.3 CVE-2026-93479៖ ភាពមិនស៊ីគ្នារវាង “ចន្លោះដែលបានបម្រុងទុក” និងប្រវែងអថេរពិតប្រាកដក្នុងការវាយតម្លៃស្គ្រីប

ម៉ូឌុល HTTP និង Stream នៃ NGINX មានកម្មវិធីវាយតម្លៃស្គ្រីបដែលភ្ជាប់ខ្សែអក្សរ និងតម្លៃអថេរទៅក្នុងខ្សែអក្សរលទ្ធផល។ ឧទាហរណ៍នៃកម្មវិធីរួមមាន ឯកសារ HTTP ផ្លូវ root ផ្លូវចូលដំណើរការ និងកន្សោមអថេរក្នុង Stream ។

ការកំណត់រចនាសម្ព័ន្ធជាក់លាក់នៃ map + កន្សោមធម្មតាអនុញ្ញាតឱ្យតម្លៃចាប់យកត្រូវបានអានដោយកន្សោមផ្សេងទៀត មុនពេលអថេរលទ្ធផល map ត្រូវបានវាយតម្លៃ។ រួមផ្សំជាមួយវិធីសាស្ត្រប្រតិបត្តិស្គ្រីបជាមួយនឹងប្រវែងដែលបានបម្រុងទុក ការអនុវត្តចាស់នឹងរាប់ទំហំដែលបានបម្រុងទុក len ទៅក្នុងឧបករណ៍ប្រមូលប្រវែងដែលបានវាយតម្លៃជាមុន ដូច្នេះការគណនាទ្រនិចសរសេរជាបន្តបន្ទាប់លែងស្របនឹងព្រំដែនសតិបណ្ដោះអាសន្នទៀតហើយ។ នៅក្នុងលំដាប់វាយតម្លៃអថេរជាក់លាក់ ការសរសេរខ្សែអក្សរបន្តបន្ទាប់អាចសរសេរជាន់លើផ្ទៃដែលបានបម្រុងទុក ដែលបណ្តាលឱ្យមានលើសចំណុះ។ S6

ធាតុចូលរួម	ហេតុអ្វីបានជាវាគួរអោយយកចិត្តទុកដាក់
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 របស់ខែតុលាត្រូវបានគ្របដណ្តប់នោះទេ។ ខ្សែសង្វាក់ជួសជុលសុវត្ថិភាពពេញលេញគួរតែត្រូវបានពិនិត្យ។ S6S14S17

ហានិភ័យ RCE ដែលអាចកើតមាននៅទីនេះគឺទាក់ទងទៅនឹងបរិស្ថានការពារអង្គចងចាំ ហើយវាមិនគួរត្រូវបានអះអាងថា map regex តែម្នាក់ឯងនឹងអាចត្រូវបានគេកេងប្រវ័ញ្ចដោយអ្នកវាយប្រហារអនាមិកនោះទេ។ S11

2.4 CVE-2026-97205៖ AIO ការរាប់ចំនួនប្រតិបត្តិការដែលមិនទាន់បានបញ្ចប់ មូលហេតុនៃការប្រើប្រាស់បន្ទាប់ពីឥតគិតថ្លៃ

ភាពងាយរងគ្រោះនេះមិនមែនគ្រាន់តែ “បើក SSI ហើយអ្នកនឹងទទួលបាន UAF” នោះទេ។ គន្លឹះស្ថិតនៅក្នុងចំនួនសេចក្តីយោងប្រតិបត្តិការអសមកាលដែលធ្វើឡើងដោយសំណើចម្បង។

NGINX ប្រើ r->main->blocked ដើម្បីតាមដានដំណើរការអសមកាលដែលមិនទាន់បានបញ្ចប់ នៅក្នុងការអនុវត្តចាស់ វាត្រូវបានរាប់ចំនួន 8 ប៊ីត។ ផ្លូវមួយចំនួនមិនបានត្រួតពិនិត្យដែនកំណត់ខាងលើ មុនពេលបង្កើនចំនួន។ នៅពេលដែលសំណើមេដូចគ្នាប្រមូលផ្តុំប្រតិបត្តិការដែលមិនទាន់សម្រេចចំនួន 256 ការរាប់អាចរុំជុំវិញពី 255 ដល់ 0។ ដំណើរការជាបន្តបន្ទាប់នឹងយល់ច្រឡំថាមិនមានប្រតិបត្តិការអសមកាលដែលរារាំងសំណើមិនឱ្យចេញទេ ដោយហេតុនេះបញ្ចេញអង្គចងចាំសំណើដែលនៅតែយោងដោយកិច្ចការ។ S7

ដំណើរការបរាជ័យអាចត្រូវបានបែងចែកជាៈ

1. ជាមួយនឹងផ្លូវ I/O/thread អសមកាលដែលពាក់ព័ន្ធត្រូវបានបើក ទំព័រ SSI ណែនាំសំណើរងជាច្រើន ឬអានប្រតិបត្តិការតាមរយៈ include virtual ។
2. ប្រតិបត្តិការលេចធ្លោនៃសំណើសំខាន់ជាក់លាក់មួយត្រូវបានប្រមូលរហូតដល់ដែនកំណត់ខាងលើដែលតំណាងដោយវាលរាប់។
3. ការរាប់ចំនួន 8 ប៊ីតត្រូវបានរុំព័ទ្ធ ដោយបង្ហាញមិនត្រឹមត្រូវថា “គ្មានប្រតិបត្តិការដែលមិនទាន់សម្រេច”។
4. បណ្តុំអង្គចងចាំសំណើត្រូវបានចេញផ្សាយ ខណៈពេលដែលឯកសារអាន ឃ្លាំងសម្ងាត់រង់ចាំ ឬការហៅត្រឡប់នៃកិច្ចការខ្សែស្រឡាយនៅតែរក្សាឯកសារយោងទៅវា។
5. ការហៅត្រលប់ក្រោយការបញ្ចប់អសមកាលជាបន្តបន្ទាប់ចូលប្រើអង្គចងចាំដែលបានចេញផ្សាយ ដែលបណ្តាលឱ្យ UAF, Worker គាំង ឬការខូចខាតអង្គចងចាំដែលអាចកើតមាន។

ការជួសជុលជាផ្លូវការបន្ថែម NGX_HTTP_MAX_BLOCKED 250 ទៅឯកសារបឋមកថាសំណើ ហើយបន្ថែមការរឹតបន្តឹងទៅតម្រងលទ្ធផល ការអានឃ្លាំងសម្ងាត់ និងផ្លូវខ្សែស្ទ្រីម។ នៅពេលឈានដល់កម្រិត ប្រតិបត្តិការជាមួយផ្លូវធ្វើសមកាលកម្មត្រូវបានបញ្ចប់ដោយសមកាលកម្ម ហើយប្រសិនបើពួកគេមិនអាចដំណើរការដោយសុវត្ថិភាពទេ ការបន្ថែមកិច្ចការដែលមិនទាន់សម្រេចនឹងត្រូវបានបដិសេធ។ S7

ការវិនិច្ឆ័យនៃការអនុវត្ត៖ វាត្រូវតែត្រូវបានវាយតម្លៃថាតើ SSI, AIO ការរួមបញ្ចូលនិម្មិត សំណើរង និងប្រតិបត្តិការអសមកាលដែលពាក់ព័ន្ធអាចកើតឡើងនៅក្នុងការរួមបញ្ចូលគ្នានៅក្នុងខ្សែសង្វាក់សំណើដូចគ្នា។ ជាធម្មតាទាំងនេះមិនមែនជាការកំណត់រចនាសម្ព័ន្ធប្រូកស៊ីឋិតិវន្តធម្មតាទេ។ aio off; ឬ ssi off; អាចលុបធាតុគន្លឹះជាក់លាក់ ប៉ុន្តែភាពអាស្រ័យមុខងារអាជីវកម្មគួរតែត្រូវបានបញ្ជាក់ជាមុនសិន។ S4S7S25

2.5 CVE-2026-95101៖ HTTP/3 ស៊ុមមិនស្គាល់ត្រូវបានច្រលំជាមួយនឹងស្ថានភាពនៃតួសំណើ DATA

ឧបករណ៍ញែកស៊ុម HTTP/3 ត្រូវតែបែងចែករវាងស៊ុម DATA (ដែលត្រូវបញ្ជូនទៅដំណើរការផ្នែកសំណើ HTTP) និងស៊ុមមិនស្គាល់ដែលគួររំលង។ ប្រវែងនៃស៊ុមដែលមិនស្គាល់ក៏ត្រូវតែរក្សាបានយ៉ាងត្រឹមត្រូវផងដែរ នៅពេលបែងចែកតាមបណ្តុំបណ្តាញ។

ការអនុវត្តចាស់របស់ ngx_http_v3_parse_data() បានប្រើវាល st->length ដើម្បីរក្សាទុក “ចំនួនបៃដែលនៅសល់ដែលត្រូវរំលង” នៅពេលរំលងស៊ុមមិនស្គាល់ ខណៈពេលដែលតម្រងតួសំណើបានបកប្រែវាលដូចគ្នានឹង “ប្រវែងបន្ទុក DATA ដែលនៅសល់” ។ ប្រសិនបើស៊ុមមិនស្គាល់កើតឡើងដើម្បីពង្រីកការហៅញែកច្រើន បាច់បន្ទាប់នៃបៃបន្ទាប់ពីការញែកត្រូវបានរំខានអាចនឹងត្រូវច្រឡំថាជាផ្នែកនៃផ្នែកសំណើ។ S8

ហានិភ័យពីរប្រភេទកើតឡើង៖

• ស្នើសុំការចាក់បញ្ចូលរាងកាយ៖ បន្ទុកស៊ុមដែលមិនមែនជា 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; មិនត្រូវបានសរសេរយ៉ាងច្បាស់លាស់។ S8S18

ផលវិបាកដោយផ្ទាល់នៃភាពងាយរងគ្រោះនេះជាកម្មសិទ្ធិរបស់សំណើ backend សុចរិតភាព និងការផ្លាស់ប្តូរព្រំដែនសុវត្ថិភាព ដែលមិនមែនជាការបញ្ចេញមតិសមមូលនៃ RCE ដែលបានបញ្ចប់ដោយផ្ទាល់នៅក្នុងស្នូល NGINX ។ ផលប៉ះពាល់អាជីវកម្មចុងក្រោយគឺអាស្រ័យទៅលើរបៀបដែលបៃទាំងនេះត្រូវបានញែក និងជឿជាក់លើចរន្ត។ S24

2.6 CVE-2026-97629: TLS ការបង្វិលសំបុត្រខកខានរន្ធដោតគ្រាប់ចុចទីបី

នៅក្នុងការកំណត់រចនាសម្ព័ន្ធដែលរងផលប៉ះពាល់ NGINX អាចបង្កើត និងបង្វិលគ្រាប់ចុចសំបុត្រវគ្គ TLS ដោយស្វ័យប្រវត្តិ តាមរយៈឃ្លាំងផ្ទុកអង្គចងចាំដែលបានចែករំលែក ដែលអនុញ្ញាតឱ្យ Worker ជាច្រើនដំណើរការសំបុត្រតែមួយ។

តក្កវិជ្ជាធ្វើសមកាលកម្មដែលពាក់ព័ន្ធបែងចែករន្ធដោតសំខាន់ៗចំនួន 3 សម្រាប់ Worker នីមួយៗ ហើយការហៅត្រឡប់ពីការឌិគ្រីបនឹងឆ្លងកាត់រន្ធទាំងនេះផងដែរ។ ប៉ុន្តែការអនុវត្តចាស់ចម្លងតែ 2 key slots ពីអង្គចងចាំដែលបានចែករំលែករាល់ពេល ដែលបណ្តាលឱ្យមានឈ្មោះ key, HMAC key និង AES នៃរន្ធដោតទីបី។ សោអាចនៅតែមិនទាន់បានកំណត់។ ប្រសិនបើការកំណត់អត្តសញ្ញាណគន្លឹះនៃសំបុត្រត្រូវបានផ្គូផ្គងដោយស្ថានភាពនេះ សម្ភារៈសោដែលមិនទាន់ចាប់ផ្តើមអាចនឹងត្រូវបានប្រើប្រាស់សម្រាប់ការផ្ទៀងផ្ទាត់ហត្ថលេខា និងការឌិគ្រីប ដូច្នេះបង្កើតជាផ្លូវសម្រាប់បង្កើតវគ្គ TLS ។ S9

ការរួមបញ្ចូលគ្នានៃការដាក់ពង្រាយដែលមានហានិភ័យខ្ពស់គឺជាធម្មតា៖

# 仅为排查触发条件所示：共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制

ផលវិបាកអាជីវកម្មដ៏ធ្ងន់ធ្ងរបំផុតនៃភាពងាយរងគ្រោះនេះគឺថានៅលើសេវាកម្មដែលប្រើការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រអតិថិជន (mTLS) នៅក្នុង ssl_verify_client on; និងវិធីផ្សេងទៀត វគ្គស្ដារឡើងវិញដែលបានក្លែងបន្លំអាចរំលងការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រអតិថិជន។ ជោគជ័យនៃការវាយប្រហារក៏ជាកម្មវត្ថុនៃលក្ខខណ្ឌដែលមិនអាចគ្រប់គ្រងបាន; គេហទំព័រដែលប្រើតែវិញ្ញាបនបត្រ HTTPS ខាងម៉ាស៊ីនមេធម្មតា ហើយគ្មានការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រអតិថិជនមិនគួរត្រូវបានកំណត់លក្ខណៈខុសទេ ព្រោះថា “អ្នកវាយប្រហារអាចរំលងការចូលគេហទំព័រទាំងមូល។” S9S12

នេះគឺជាបញ្ហាស្ថានភាពផ្ទៀងផ្ទាត់សម័យ TLS ហើយមិនមានអ្វីដែលត្រូវធ្វើជាមួយថាតើសោឯកជន TLS របស់ម៉ាស៊ីនមេត្រូវបានបំបែក ឬថាតើវិញ្ញាបនបត្រ CA root សាធារណៈត្រូវបានប៉ះពាល់ដែរឬទេ។ S24

2.7 របៀបយល់ DoS, RCE ការឆ្លងកាត់ការផ្ទៀងផ្ទាត់ និងការកេងប្រវ័ញ្ចដែលគេស្គាល់

• DoS៖ កំហុសអង្គចងចាំបណ្តាលឱ្យ Worker គាំង ឬចាប់ផ្ដើមឡើងវិញយ៉ាងខ្លាំង។ ថាតើវាបណ្តាលឱ្យមានភាពមិនអាចប្រើបានជារួមទាក់ទងនឹងសម្ពាធចរាចរណ៍ សមត្ថភាពចាប់ផ្តើមដំណើរការឡើងវិញ ពេលវេលាថែទាំការតភ្ជាប់ និងស្ថាបត្យកម្មដែលអាចរកបានខ្ពស់។
• សក្តានុពល RCE៖ សេចក្តីប្រកាសមួយចំនួនបង្ហាញថាមានលទ្ធភាពនៃការប្រតិបត្តិកូដនៅពេលដែល ASLR ត្រូវបានបិទ ឬរំលង។ នេះមិនមានន័យថាខ្សែសង្វាក់វាយប្រហារសាធារណៈដែលអាចប្រតិបត្តិពាក្យបញ្ជាប្រកបដោយស្ថេរភាព និងជាសកលត្រូវបានបង្ហាញនោះទេ។ S4
• ស្នើសុំការឆ្លងកាត់ការបញ្ចូល/ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ៖ វាអាចផ្លាស់ប្តូរដោយផ្ទាល់នូវស្ថានភាពអាជីវកម្មដែលត្រូវបានការពារ ឬស្នើសុំខ្លឹមសារ ហើយមិនអាចមិនអើពើបានទេ ដោយសារវាមិនទទួលបានសែលដោយផ្ទាល់។
• បានរកឃើញការប៉ុនប៉ងវាយប្រហារ៖ CVE-2026-42945 នៅខែឧសភា ឆ្នាំ 2026 មានរបាយការណ៍អំពីសកម្មភាពកេងប្រវ័ញ្ចក្នុងព្រៃ។ មិនគួរសន្និដ្ឋានដោយផ្ទាល់នូវការពិតជាប្រវត្តិសាស្រ្តនេះដើម្បីមានន័យថា CVEs ទាំងប្រាំនៅក្នុងខែតុលាត្រូវបានទាញយកដោយជោគជ័យក្នុងទ្រង់ទ្រាយធំនោះទេ។ S23

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 ក៏ដោយ ក៏វានៅតែទាបជាងបន្ទាត់បំណះនៃបណ្តាញមេ។ S1S2

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

3.3 Ubuntu៖ ការចែកចាយ backports (USN-8955-1)

Canonical USN-8955-1 ថ្ងៃទី 26 ខែតុលា ឆ្នាំ 2026 ផ្តល់នូវការអាប់ដេតសុវត្ថិភាពសម្រាប់ការបង្កើត Ubuntu ចំនួនបួន៖ S13

កំណែ 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

3.4 Debian៖ ភាពខុសគ្នារវាងកំណែត្រូវតែពិនិត្យដោយឡែកពីគ្នា។

ការណែនាំ Debian DSA-6575-1 (2026-10-21) គ្របដណ្តប់ CVEs ទាំងប្រាំនេះហើយកំណត់អត្តសញ្ញាណកញ្ចប់ nginx ថេរសម្រាប់ Debian 13 / trixie ដូចជា៖

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 ។ S14S15S16

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
njs / ngx_http_js_module	2026-10-14 ចេញផ្សាយ njs 1.0.2 និងជួសជុល CVE-2026-101019 និង CVE-2026-101025; ប្រសិនបើអ្នកកំពុងប្រើ njs អ្នកក៏ត្រូវពិនិត្យមើលភាពឆបគ្នានៃម៉ូឌុលជាមួយ NGINX ផងដែរ។ S20
F5 NGINX Ingress Controller / Gateway Fabric	ស្នូល NGINX គឺជាខ្សែសង្វាក់ចែកចាយកម្មវិធីដែលពាក់ព័ន្ធ ប៉ុន្តែឯករាជ្យ។ ជួសជុលភាពងាយរងគ្រោះដែលពាក់ព័ន្ធជាមួយនឹងឧបករណ៍បញ្ជារៀងៗខ្លួន រូបភាព និងកំណត់ចំណាំចេញផ្សាយ។ អ្នកមិនអាចគ្រាន់តែជំនួសប្រព័ន្ធគោលពីរ NGINX នៅក្នុង Pod បានទេ។
សហគមន៍ Kubernetes kubernetes/ingress-nginx	គម្រោងនេះត្រូវបានបញ្ឈប់នៅខែមីនា ឆ្នាំ 2026 ហើយនឹងលែងផ្តល់ការថែទាំសុវត្ថិភាពថ្មីទៀតហើយ។ អ្នកគួរមានគម្រោងផ្លាស់ប្តូរទៅឧបករណ៍បញ្ជាដែលបានថែទាំ ឬ Gateway API ជាជាងការច្រឡំលេខចេញផ្សាយរបស់វាសម្រាប់ F5 NGINX Ingress Controller ។ S21

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 ពិនិត្យកំណែ និងព័ត៌មានចងក្រង

# 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 ការអនុញ្ញាត និងការអនុញ្ញាតឯកសារឯកជន ហើយកុំបង្ហោះឯកសារដើមទៅក្នុងការបញ្ជាទិញការងារសាធារណៈ៖

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 (ឃ្លាំងចែកចាយផ្លូវការ)៖

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 ប្រសិនបើកញ្ចប់ដែលបានដំឡើងកំណែនៅតែត្រូវបានចាត់ទុកថាងាយរងគ្រោះដោយប្រព័ន្ធតាមដានសុវត្ថិភាព ការជួសជុលបន្ថែម ការដាក់ឱ្យនៅដាច់ដោយឡែក ឬវិធានការធ្វើចំណាកស្រុកត្រូវបានទាមទារ។ S13S14S15

កញ្ចប់ផ្លូវការ nginx.org៖

# 先确认仓库来自 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 ចាស់

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

ប្រសិនបើអ្នកគ្រប់គ្រង NGINX តាមរយៈរន្ធ systemd ស្គ្រីបបញ្ចូលកុងតឺន័រ ឬការដំឡើងច្រើន អ្នកគួរតែពិនិត្យមើលគោលដៅចាប់ផ្តើម និងផ្លូវដំណើរការពិតប្រាកដ ជំនួសឱ្យការសន្មតដោយផ្ទាល់ថា systemctl restart nginx គ្របដណ្តប់គ្រប់ករណីទាំងអស់។

4.6 ទទួលយក និងធ្វើអាជីវកម្មតំរែតំរង់ពីច្រកចូលខាងក្រៅពិតប្រាកដ

វាត្រូវបានណែនាំឱ្យអនុវត្តយ៉ាងហោចណាស់៖

• តើ HTTPS ធម្មតា ផ្លូវដែលសរសេរឡើងវិញ ធនធានឋិតិវន្ត និងទំព័រផែនទី alias ត្រឹមត្រូវ។
• តើការចែកចាយ map ធម្មតា, ផ្លូវ root អថេរ, ផ្លូវចូលដំណើរការ, SNI/ការបញ្ជាក់ផ្លូវ និងប្រូកស៊ី Stream ត្រឹមត្រូវ។
• តើការអាប់ឡូតធម្មតា ការអាប់ឡូតជាកំណាត់ សំណើ API និងកម្រិតសំឡេងឡើងលើសម្រាប់ HTTP/3 (នៅពេលបើកដំណើរការ) នៅតែដូចការរំពឹងទុក។
• mTLS៖ សំណើវិញ្ញាបនបត្រស្របច្បាប់គួរតែជោគជ័យ។ បាត់ ផុតកំណត់ ឬវិញ្ញាបនបត្រដែលមិនមានការអនុញ្ញាតគួរតែនៅតែត្រូវបានបដិសេធ ហើយការបន្ត/ភ្ជាប់ឡើងវិញ TLS មិនគួរផ្លាស់ប្តូរការអនុញ្ញាតដោយចៃដន្យទេ។
• ថាតើទំព័រ SSI និងការចូលប្រើឯកសារអសមកាលគឺធម្មតាទេ កំណត់​ហេតុ​កំហុស​បង្ហាញ​ថា​មិន​មាន​សំណើ​មិន​ប្រក្រតី​សម្រាប់​ការ​យោង​អង្គ​ចងចាំ​ឬ Worker គាំង​ម្តង​ហើយ​ម្តង​ទៀត​។
• បន្ទាប់ពីការផ្លាស់ប្តូរចរាចរណ៍ ដំណើរការកំណែចាស់ និងការចម្លងរូបភាពចាស់គួរតែចេញ។

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

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

ផ្នែកនេះគឺជាជម្រើសកាត់បន្ថយហានិភ័យ មិនមែនជាការជំនួសបំណះទេ។ ការផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធបណ្តោះអាសន្នទាំងអស់គួរតែត្រូវបានបម្រុងទុក ប្រតិបត្តិ nginx -t ចេញជាបាច់ ហើយត្រលប់មកវិញយ៉ាងឆាប់រហ័សប្រសិនបើចាំបាច់។ S3S4

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

5.3 map/Regex៖ កាត់បន្ថយការចាប់យកការលាយស្ថានភាពអថេរ

វាត្រូវបានផ្ដល់អនុសាសន៍ឱ្យកំណត់អាទិភាពការចាប់យកដែលមានឈ្មោះ និងកំណត់វិសាលភាពផ្សព្វផ្សាយរបស់ពួកគេ ជាជាងអនុញ្ញាតឱ្យការចាប់យកអនាមិកដូចជា $1 ត្រូវបានប្រើឡើងវិញឆ្លងកាត់ផ្លូវវាយតម្លៃ regex ផ្សេងៗគ្នាតាមពេលវេលា។ ឧទាហរណ៍៖

# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
    default /srv/www/default;
    ~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}

អត្ថបទខ្លីៗនេះបង្ហាញតែរចនាសម្ព័ន្ធសវនកម្មដែលងាយស្រួលជាងនៃភាពជាម្ចាស់អថេរ។ មិនមានន័យថាវាត្រូវបានបញ្ជាក់ដោយឯករាជ្យដើម្បីលុបបំបាត់ CVE-2026-93479 ផ្លូវកេះទាំងអស់ទៅ។ ជាពិសេស ពិនិត្យមើលថាតើអថេរចាប់យកត្រូវបានយោងមុនពេលវេលាដោយ root ឬ log_format ផ្សេងទៀតដែរឬទេ ហើយថាតើមាន volatile ផ្លូវថាមវន្ត និងខ្សែសង្វាក់វាយតម្លៃអាស្រ័យគ្នាទៅវិញទៅមក។ F5/CERT ផ្តល់អនុសាសន៍ឱ្យប្រើការចាប់យកដែលមានឈ្មោះ និងការកំណត់វិសាលភាពនៃការប្រើប្រាស់ទៅនឹងការកំណត់រចនាសម្ព័ន្ធដែលត្រូវគ្នាជាទៀងទាត់ដែលជាការសង្គ្រោះរយៈពេលខ្លី។ S3S6

5.4 AIO + SSI៖ បិទបន្សំមុខងារដែលមិនចាំបាច់

សម្រាប់ម៉ាស៊ីនមេ/ផ្លូវដែលមិនត្រូវការ SSI ឬឯកសារអសមកាល I/O សូមប្រើ៖

# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;

តាមទស្សនៈនៃលក្ខខណ្ឌដែលបង្កឱ្យមានភាពងាយរងគ្រោះ ការបិទមួយក្នុងចំណោមពីរគឺជាធម្មតាគ្រប់គ្រាន់ដើម្បីដកចេញខ្សែសង្វាក់ជាក់លាក់ដែលបានពិពណ៌នា។ ការបិទក្នុងពេលតែមួយគឺអាចអនុវត្តបានតែចំពោះសេណារីយ៉ូដែលអាជីវកម្មមិនពឹងផ្អែកលើសមត្ថភាពនេះ។ ពិនិត្យ include virtual, សំណើរង, ឃ្លាំងសម្ងាត់, និងឥរិយាបថក្រុមខ្សែស្រឡាយ; នៅពេលដែលការផ្ទុកប្រូកស៊ីបញ្ច្រាសគឺខ្ពស់ ការបិទ AIO អាចផ្លាស់ប្តូរភាពយឺតយ៉ាវ និងដំណើរការ I/O ។ S7

5.5 HTTP/3 ស្នើសុំការចាក់លើរាងកាយ៖ បិទច្រកចូលជាបណ្តោះអាសន្នប្រសិនបើចាំបាច់

បិទដំណើរការ quic អ្នកស្តាប់ដែលពាក់ព័ន្ធ HTTP/3 លុបចោល Alt-Svc ក្បាលឆ្លើយតបដែលប្រកាស HTTP/3 ហើយពិនិត្យមើលថាតើស្រទាប់គែម/ឧបករណ៍ផ្ទុកតុល្យភាពនៅតែផ្ញើ QUIC ស្នើសុំដោយផ្ទាល់ទៅអ្នកមិនទាន់ជួសជុល 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 ដែល​រង​ផល​ប៉ះពាល់។ S8S18

សំបុត្រវគ្គ 5.6 TLS៖ ការការពារអាទិភាព mTLS ព្រំដែនការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ

ប្រសិនបើ​ការអាប់ដេត​មិន​អាច​ធ្វើ​ទៅ​បាន ហើយ​ឧទាហរណ៍​ពឹងផ្អែកលើ​ឃ្លាំងសម្ងាត់​សម័យ​ដែល​បាន​ចែករំលែក + ការបង្វិល​គ្រាប់ចុច​សំបុត្រ​ដោយស្វ័យប្រវត្តិ សូម​វាយតម្លៃ៖

# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;

នេះអាចបិទយន្តការសំបុត្រវគ្គ TLS ដោយហេតុនេះការដកផ្លូវក្លែងក្លាយដែលបានពិពណ៌នានៅក្នុងភាពងាយរងគ្រោះនេះចេញ។ ទោះយ៉ាងណាក៏ដោយ វាអាចប៉ះពាល់ដល់ដំណើរការដំណើរការបន្តវេន។ អ្នកមិនអាចបិទការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រអតិថិជន mTLS ដើម្បី “ជៀសវាងភាពងាយរងគ្រោះ” ព្រោះវានឹងលុបព្រំដែនការផ្ទៀងផ្ទាត់ដើមដោយផ្ទាល់។ S9S12

ឯកសារ ssl_session_ticket_key ច្បាស់លាស់ និងការបង្វិលសុវត្ថិភាពក៏អាចត្រូវបានប្រើដោយដំណើរការគ្រប់គ្រង TLS ដែលមានជំនាញវិជ្ជាជីវៈ ដើម្បីគេចចេញពីលក្ខខណ្ឌដែលបង្កើតដោយស្វ័យប្រវត្តិ ប៉ុន្តែការឃុំឃាំងកូនសោ ការចែកចាយថ្នាំងពេញលេញ ការបង្វិល និងវដ្តជីវិតសំបុត្រចាស់ទាំងអស់ ចាំបាច់ត្រូវធ្វើសវនកម្មយ៉ាងប្រុងប្រយ័ត្ន។ វាមិនត្រូវបានណែនាំអោយធ្វើកូដរឹងនូវសោដែលអាចប្រើឡើងវិញបានយូរអង្វែងក្នុងការកំណត់រចនាសម្ព័ន្ធគេហទំព័រធម្មតា ឬស្គ្រីបសម្រាប់គ្រាអាសន្នបណ្តោះអាសន្នទេ។ សេវាកម្មសំខាន់ៗដែលប្រើ mTLS គួរតែត្រូវបានត្រួតពិនិត្យបន្ថែមសម្រាប់ឥរិយាបថបន្តវេន TLS និងការបដិសេធសំណើដោយគ្មានវិញ្ញាបនបត្រអតិថិជនត្រឹមត្រូវ។ S12

5.7 តួនាទីនៃប្រព័ន្ធប្រតិបត្តិការ និងការការពារព្រំដែន

# Linux：常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_space

ASLR កម្មករដែលមិនមែនជា root ប្រព័ន្ធឯកសារកុងតឺន័របានតែអាន ការអនុញ្ញាតឯកសារតិចតួច និងការផ្តាច់បណ្តាញអាចកាត់បន្ថយផលប៉ះពាល់នៃសក្តានុពល RCE ។ ASLR មិនជួសជុល heap overflows ឬ UAF ហើយមិនអាចធានាថាកម្មករនឹងមិនគាំង។ WAF ដែនកំណត់អត្រា និងដែនកំណត់ទំហំរាងកាយសំណើមិនជួសជុល TLS ការធ្វើសមកាលកម្មគន្លឹះសំបុត្រ។ S4

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 ។ អត្ថបទខ្លីៗបង្ហាញពីការផ្លាស់ប្តូរតំណាងសម្រាប់ការពិនិត្យបំណះ។ វាមិនពេញលេញទេ ការជួសជុលដែលអាចចងក្រងដោយឯករាជ្យ។ សម្រាប់ការបង្កើតផ្ទាល់ខ្លួន សូមពិនិត្យមើលការប្តេជ្ញាចិត្តពេញលេញ កូដជុំវិញ និងការសាកល្បង ហើយចូលចិត្តការចេញផ្សាយដែលគាំទ្រពេញលេញ។ S5S6S7S8S9

6.1 CVE-2026-15176៖ URI ត្រូវបានសរសេរឡើងវិញដើម្បីរួមបញ្ចូលលក្ខខណ្ឌបដិសេធការគូសផែនទីផ្លូវ alias

ការប្តេជ្ញាចិត្តខាងលើដែលបានកែប្រែ ngx_http_map_uri_to_path() នៅក្នុង src/http/ngx_http_core_module.c៖

- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {

ការផ្តោតអារម្មណ៍ពិនិត្យឡើងវិញ៖ ផ្លូវប្រព័ន្ធឯកសារមិនអាចបន្តត្រូវបានគណនានៅពេលដែល URI បានផ្លាស់ប្តូរ ប៉ុន្តែអត្ថន័យទីតាំងដែលត្រូវគ្នានៃ alias លែងអាចទុកចិត្តបាន។ នេះ​គឺ​ជា​ការ​ពង្រឹង​ដល់​ការ​រឹតត្បិត​មុន​រដ្ឋ។ វាមិនមែនជាការត្រួតពិនិត្យសាមញ្ញទេថាតើសំណើ URI មានតួអក្សរខុសច្បាប់ដែរឬទេ។ S5

6.2 CVE-2026-93479៖ បែងចែកយ៉ាងត្រឹមត្រូវរវាងប្រវែងទិន្នន័យលទ្ធផល និងប្រវែងបម្រុង

ការប្តេជ្ញាចិត្តខាងលើធ្វើបច្ចុប្បន្នភាព src/http/ngx_http_script.c និង src/stream/ngx_stream_script.c ក្នុងពេលតែមួយ។ គោលបំណងស្នូលអាចត្រូវបានសង្ខេបដូចជា:

- 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

នៅពេលធ្វើសវនកម្ម និង backporting អ្នកវាយតម្លៃដែលត្រូវគ្នានៃ HTTP/Stream ក៏ត្រូវតែគ្របដណ្តប់ផងដែរ។ មានតែការពិនិត្យមើលឯកសារវាក្យសម្ព័ន្ធនៃការកំណត់រចនាសម្ព័ន្ធ map មិនអាចបង្ហាញថាពិការភាពត្រូវបានជួសជុលទេ។

6.3 CVE-2026-97205៖ កំណត់កម្រិតសុវត្ថិភាពសម្រាប់ចំនួនប្រតិបត្តិការអសមកាល 8 ប៊ីត

ខាងលើបានបន្ថែមនៅ src/http/ngx_http_request.h៖

#define NGX_HTTP_MAX_BLOCKED 250

ហើយបន្ថែមធាតុស្រដៀងគ្នាទៅនឹងការអានឯកសារអសមកាល ការរង់ចាំឃ្លាំងសម្ងាត់ ការច្រោះលទ្ធផល និងប្រតិបត្តិការខ្សែស្រឡាយ៖

if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
    /* 使用同步路径，或者拒绝新的异步操作 */
}

ការផ្តោតអារម្មណ៍ពិនិត្យឡើងវិញ៖ ផ្លូវកូដពិតប្រាកដទាំងអស់ដែលនឹងបន្ថែម r->main->blocked ត្រូវតែគ្របដណ្តប់។ អ្នកមិនអាចសរសេរកម្រិតថេរនៅក្នុងឯកសារបឋមកថាបានទេ។ Backport ក៏ត្រូវពិនិត្យមើលការសម្របសម្រួលពេញលេញនៃការធ្លាក់ចុះសមកាលកម្ម ការហៅត្រឡប់មកវិញអសមកាល និងការត្រលប់មកវិញនូវកំហុស ដើម្បីធានាថាការជាប់គាំងឬការលេចធ្លាយឯកសារយោងនឹងមិនបណ្តាលមកពីការបដិសេធដោយផ្ទាល់នូវកិច្ចការនោះទេ។ S7

6.4 CVE-2026-95101៖ រក្សាស្ថានភាព skip ដាច់ដោយឡែកសម្រាប់ស៊ុមមិនស្គាល់

ចរន្តខាងលើបន្ថែមវាល skip នៅក្នុងរចនាសម្ព័ន្ធស្ថានភាពញែក HTTP/3 និងអនុវត្តការបំបែកស្ថានភាព៖

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

6.5 CVE-2026-97629៖ ធ្វើសមកាលកម្មអារេរន្ធគ្រាប់ចុច TLS ពេញលេញ

ការផ្លាស់ប្តូរចរន្តទឹកមានទីតាំងនៅ src/event/ngx_event_openssl.c៖

  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

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 ជាច្រើនដែលមិនត្រូវបានអាប់ដេតក្នុងរយៈពេលយូរ មិនត្រឹមតែរងផលប៉ះពាល់ដោយបញ្ហាថ្មីនៅក្នុងខែតុលាប៉ុណ្ណោះទេ។ ខាងក្រោមនេះគឺជាថ្នាំងជួសជុលតំណាងក្នុងពេលអនាគតដ៏ខ្លី៖ S1S2

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

ហេតុអ្វីត្រូវយកចិត្តទុកដាក់ជាពិសេសចំពោះ CVE-2026-42945

មានព្រឹត្តិបត្រសុវត្ថិភាពពីភ្នាក់ងាររដ្ឋាភិបាលដែលកត់ត្រាសកម្មភាពកេងប្រវ័ញ្ចក្នុងព្រៃ និងព័ត៌មានកូដកេងប្រវ័ញ្ចសាធារណៈសម្រាប់ភាពងាយរងគ្រោះ rewrite នេះក្នុងខែឧសភា។ ដូច្នេះ សម្រាប់ករណីដែលមិនត្រូវបានជួសជុលរយៈពេលយូរចាប់ពីខែឧសភាដល់បច្ចុប្បន្ន ហើយបានបើកកន្សោមធម្មតាដែលស្មុគស្មាញ សរសេរឡើងវិញនៅលើបណ្តាញសាធារណៈ បន្ថែមពីលើការបញ្ចប់ការជួសជុល ការគាំង Worker មិនធម្មតា កំណត់ហេតុចូលដំណើរការ និងការផ្លាស់ប្តូរគួរឱ្យសង្ស័យនៅពេលនោះ គួរតែត្រូវបានពិនិត្យបន្ថែម។ S23

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

ការជួសជុល 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
• F5 NGINX Plus / NGINX Ingress Controller៖ លើសពីនេះ ឧបករណ៍បញ្ជា និង Gateway Fabric នីមួយៗអាចមានព្រឹត្តិបត្រសុវត្ថិភាពបន្ថែម កំណែវេចខ្ចប់ផ្សេងៗគ្នា និងភាពងាយរងគ្រោះគោលការណ៍តែមួយគត់។ ការអាប់ដេតស្រទាប់មួយមិនមានន័យថាធ្វើបច្ចុប្បន្នភាពស្រទាប់មួយផ្សេងទៀតដោយស្វ័យប្រវត្តិនោះទេ។ S19
• Kubernetes សហគមន៍ ingress-nginx៖ មន្ត្រី Kubernetes បានប្រកាសរួចហើយថាឧបករណ៍បញ្ជាបានឈប់ថែទាំនៅខែមីនា ឆ្នាំ 2026 ហើយឃ្លាំងរបស់វាមិនអាចច្រឡំជាមួយឧបករណ៍បញ្ជា F5 បានទេ។ អាជីវកម្មដែលរងផលប៉ះពាល់គួររៀបចំផែនការធ្វើចំណាកស្រុកដោយរលូន និងផ្ទៀងផ្ទាត់ចំណារពន្យល់ Ingress និងភាពខុសគ្នាតាមន័យ Gateway API ជំនួសឱ្យការរង់ចាំកំណែសុវត្ថិភាពថ្មី។ S21

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 ព្រឹត្តិបត្រសុវត្ថិភាពផ្លូវការ

• https://nginx.org/en/security_advisories.html

មានកំណែដែលរងផលប៉ះពាល់ខាងលើ ជួសជុលសាខា និងកម្រិតភាពធ្ងន់ធ្ងរជាផ្លូវការនៃ CVEs ខែតុលាចំនួន 5 ហើយថែមទាំងគ្របដណ្តប់ភាពងាយរងគ្រោះជាប្រវត្តិសាស្ត្ររហូតដល់ឆ្នាំ 2026។

S2 — NGINX កំណែផ្លូវការ កំណត់ត្រាចេញផ្សាយ

• https://nginx.org/news.html
• https://nginx.org/en/CHANGES-1.30

បញ្ជាក់ 1.30.6 / 1.31.7 នៃ 2026-10-14, 1.31.8 នៃ 2026-10-21 និងព្រឹត្តិការណ៍សំខាន់ៗនៃការចេញផ្សាយសុវត្ថិភាពពីខែឧសភាដល់ខែកញ្ញា។

S3 - ទីភ្នាក់ងារសន្តិសុខតាមអ៊ីនធឺណិតនៃប្រទេសសិង្ហបុរី៖ F5 NGINX ភាពងាយរងគ្រោះសំខាន់បី

• https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-150/

ការពិពណ៌នាអំពីពិន្ទុ CVSS v4.0 9.2 លក្ខខណ្ឌនៃការកំណត់រចនាសម្ព័ន្ធដែលត្រូវការ និងការណែនាំអំពីការបន្ធូរបន្ថយបណ្តោះអាសន្នសម្រាប់ CVE-2026-15176, CVE-2026-93479 និង CVE-2026-97205 ។

S4 - NHS ប្រទេសអង់គ្លេស៖ F5 NGINX ការប្រឹក្សាហានិភ័យខ្ពស់

• https://digital.nhs.uk/cyber-alerts/2026/cc-4872

ពិពណ៌នាអំពីផលប៉ះពាល់ DoS / សក្តានុពល RCE នៃបញ្ហាសុវត្ថិភាពនៃការចងចាំ ហើយឧបសគ្គដូចជា ASLR ត្រូវបានបិទ ឬរំលង។

S5 — ប្រភពផ្លូវការប្តេជ្ញា៖ CVE-2026-15176

• https://github.com/nginx/nginx/commit/f8a23425bd6840c4c36b4264edf576ba3646156f

ឆ្លើយតបទៅនឹងការត្រួតពិនិត្យស្ថានភាពរបស់ alias និង r->uri_changed នៅក្នុង ngx_http_map_uri_to_path() ។

S6 — ប្រភពផ្លូវការប្តេជ្ញា៖ CVE-2026-93479

• https://github.com/nginx/nginx/commit/6aa4b3fdd4fdc156153f2981eb4070690624447c

ដែលត្រូវគ្នាទៅនឹងប្រវែងស្គ្រីប HTTP/Stream និងតក្កវិជ្ជានៃការបែងចែកសតិបណ្ដោះអាសន្នដែលបានបម្រុងទុក។

S7 - ប្រភពផ្លូវការប្តេជ្ញា៖ CVE-2026-97205

• https://github.com/nginx/nginx/commit/6adfc05ece48f92446383ec1f145446848694698

ត្រូវគ្នាទៅនឹងកម្រិតចាប់ផ្ដើមរាប់ r->main->blocked NGX_HTTP_MAX_BLOCKED 250 និងការធ្លាក់ចុះផ្លូវអសមកាល។

S8 — ប្រភពផ្លូវការប្តេជ្ញា៖ CVE-2026-95101

• https://github.com/nginx/nginx/commit/1c173a2d8767730e678c27446138d7ae5dd6fd64

ការបំបែកស្ថានភាពដែលត្រូវគ្នានឹងប្រវែងស៊ុមមិនស្គាល់ HTTP/3 និង DATA ស្នើសុំប្រវែងតួ។

S9 — ប្រភពផ្លូវការប្តេជ្ញា៖ CVE-2026-97629

• https://github.com/nginx/nginx/commit/1916f26e6ca49296568633d309777e36527e5bb2

ត្រូវគ្នាទៅនឹងរន្ធគ្រាប់ចុចទាំងអស់កំឡុងពេលធ្វើសមកាលកម្ម TLS Session Ticket បង្វិល។

S10 — F5៖ សេចក្តីប្រកាសរបស់អ្នកលក់ CVE-2026-15176

• https://my.f5.com/manage/s/article/K000162416

រាយបញ្ជីកត្តាបង្កហេតុដូចជា alias, rewrite, $request_filename និងកំណត់ហេតុចូលប្រើប្រាស់។

S11 — F5: CVE-2026-93479 សេចក្តីប្រកាសអ្នកលក់

• https://my.f5.com/manage/s/article/K000162607

រាយបញ្ជីការចាប់យកផែនទី regex ផ្លូវ root និងកំណត់លក្ខខណ្ឌវាយតម្លៃអថេរ។

S12 — NGINX ផ្លូវការ TLS/SSL ឯកសារម៉ូឌុល

• https://nginx.org/en/docs/http/ngx_http_ssl_module.html

ការពិពណ៌នា ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key និងការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រអតិថិជន និងការណែនាំផ្សេងទៀត។

S13 — ប្រឹក្សាសន្តិសុខ: Ubuntu USN-8955-1 (2026-10-26)

• https://ubuntu.com/security/notices/USN-8955-1

ផ្តល់កញ្ចប់កម្មវិធីពេញលេញនូវកំណែថេរ និងវិសាលភាពចែកចាយនៃ Ubuntu 22.04 / 24.04 / 26.04 / 26.10.

S14 — ប្រឹក្សាសន្តិសុខ: Debian DSA-6575-1 (2026-10-21)

• https://lists.debian.org/debian-security-announce/2026/msg00490.html

បញ្ជាក់កញ្ចប់ជួសជុលសុវត្ថិភាព 1.26.3-3+deb13u10 សម្រាប់ Debian 13 / trixie ហើយកត់ត្រាទំនាក់ទំនង backport សម្រាប់ CVE-2026-93479 ។

S15 — ការតាមដានភាពងាយរងគ្រោះ: Debian Security Tracker: CVE-2026-15176

• https://security-tracker.debian.org/tracker/CVE-2026-15176

ប្រើដើម្បីផ្ទៀងផ្ទាត់ស្ថានភាពជួសជុលការចែកចាយ Debian 12 / bookworm និង Debian 13 / trixie ។ ស្ថានភាពនេះអាចផ្លាស់ប្តូរជាមួយនឹងការធ្វើបច្ចុប្បន្នភាពសុវត្ថិភាពនាពេលអនាគត។

S16 — ការតាមដានភាពងាយរងគ្រោះ: Debian Security Tracker: CVE-2026-95101

• https://security-tracker.debian.org/tracker/CVE-2026-95101

ការបញ្ជាក់បន្ថែមអំពីស្ថានភាពសុវត្ថិភាពនៃភាពងាយរងគ្រោះ HTTP/3 នៅលើសាខា Debian ផ្សេងៗគ្នា។

S17 — ប្រឹក្សាសន្តិសុខ: Red Hat: CVE-2026-93479

• https://access.redhat.com/security/cve/cve-2026-93479

ការយល់ដឹងបន្ថែមអំពីទំនាក់ទំនងរវាងភាពងាយរងគ្រោះនៃការតំរែតំរង់ខែតុលា និងការជួសជុលសម្រាប់ខែកក្កដា CVE-2026-42533 ។

S18 — NGINX ឯកសារម៉ូឌុលប្រូកស៊ីបញ្ច្រាសជាផ្លូវការ

• https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• https://nginx.org/en/docs/http/ngx_http_core_module.html

សួរ​តម្លៃ​អត្ថន័យ​និង​លំនាំដើម​នៃ​ការកំណត់​ដូចជា proxy_request_buffering, client_max_body_size, alias, aio ជាដើម។

S19 — NGINX Plus កំណត់សម្គាល់ការចេញផ្សាយផ្លូវការ

• https://docs.nginx.com/nginx/releases/

រាយបញ្ជីសាខា CR/LTS បូក កំណែ បំណះ និងធ្វើឱ្យប្រសើរឡើងការរំលឹកភាពត្រូវគ្នា។

S20 — NGINX JavaScript / njs ព្រឹត្តិបត្រសុវត្ថិភាពផ្លូវការ

• https://nginx.org/en/docs/njs/security.html
• https://nginx.org/en/docs/njs/changes.html

មានខែតុលា 2026 njs 1.0.2 និងការបញ្ជាក់ XML ដែលពាក់ព័ន្ធ បញ្ហាអស់អង្គចងចាំ។

S21 — Kubernetes៖ សហគមន៍ ingress-nginx ការណែនាំអំពីការចូលនិវត្តន៍ជាផ្លូវការ

• https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
• https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

ចំណាំថាគម្រោងនេះបានបញ្ឈប់ការចេញផ្សាយថ្មី និងការជួសជុលសុវត្ថិភាពនៅក្នុងខែមីនា ឆ្នាំ 2026 ហើយវាត្រូវបានផ្ដល់អនុសាសន៍ឱ្យផ្លាស់ប្តូរឧបករណ៍បញ្ជាដែលបានថែទាំ ឬ Gateway API ។

S22 — NGINX ការគ្រប់គ្រងសេវាកម្មផ្លូវការ និងការណែនាំអំពីការធ្វើឱ្យប្រសើរប្រព័ន្ធគោលពីរតាមអ៊ីនធឺណិត

• https://nginx.org/en/docs/control.html

ញែកការកំណត់រចនាសម្ព័ន្ធផ្ទុកឡើងវិញ ចាប់ផ្តើមឡើងវិញ និងវិធីសាស្ត្រធ្វើឱ្យប្រសើរឡើងឯកសារដែលអាចប្រតិបត្តិបានតាមអ៊ីនធឺណិតសម្រាប់ការទទួលយកការផ្លាស់ប្តូរដំណើរការ។

S23 - ការជូនដំណឹងអំពីសុវត្ថិភាពរបស់រដ្ឋាភិបាល៖ ខែឧសភា ឆ្នាំ 2026 NGINX ភាពងាយរងគ្រោះក្នុងការសរសេរឡើងវិញ

• https://its.ny.gov/2026-051
• https://www.govcert.gov.hk/en/alerts_detail.php?id=1881

ផ្តល់ការណែនាំអំពីប្រវត្តិហានិភ័យ និងបច្ចុប្បន្នភាពសុវត្ថិភាពសម្រាប់ CVE-2026-42945; ការវិនិច្ឆ័យទាក់ទងនឹងការកេងប្រវ័ញ្ចក្នុងព្រៃគួរតែផ្អែកលើសេចក្តីប្រកាសរបស់ទីភ្នាក់ងារនៅពេលនោះ និងភស្តុតាងឧប្បត្តិហេតុបន្ថែមទៀត។

S24 — F5៖ CVE-2026-95101 និង CVE-2026-97629 សេចក្តីប្រកាសអំពីអ្នកលក់

• https://my.f5.com/manage/s/article/K000162613
• https://my.f5.com/manage/s/article/K000162606

គ្របដណ្តប់ហានិភ័យនៃ HTTP/3 ស្នើសុំការចាក់លើរាងកាយ និងការបង្វិលគ្រាប់ចុចសំបុត្រ TLS ដោយស្វ័យប្រវត្តិរៀងៗខ្លួន។

S25 — F5៖ សេចក្តីប្រកាសរបស់អ្នកលក់ CVE-2026-97205

• https://my.f5.com/manage/s/article/K000162608

ការពិពណ៌នា SSI/AIO បង្កឱ្យមានលក្ខខណ្ឌ និងហានិភ័យនៃការខូចខាតការចងចាំដែលអាចកើតមាន។

ការអាប់ដេតសុវត្ថិភាព NGINX៖ ការត្រួតពិនិត្យការកំណត់រចនាសម្ព័ន្ធ ការធ្វើឱ្យប្រសើរ និងការផ្ទៀងផ្ទាត់